FreeBSD image hangs during boot
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.iso
Cheers,
Aurelien
Signature · 9 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Aurélien,
did you try kvm-45 ?
Laurent
Quoted 15 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoCheers,
Aurelien
Signature · 2 lines
------------- Laurent.Vivier-6ktuUTfB/[email protected] -------------- "Software is hard" - Donald Knuth
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
A message that is not in the archive (sent off-list or not yet received): 47023130.6000805-6ktuUTfB/[email protected]
Quoted 4 lines · Laurent Vivier
Hi Aurélien,
did you try kvm-45 ?
Yes the test is done with kvm-45.
Signature · 9 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 5 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
Quoted 8 lines
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.iso
It complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
Igor? Any hint?
Signature · 7 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): 470234DF.6030802-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 10 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 8 lines
Quoted 4 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoIt complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
The RSDT checksum problem is not new, but it was harmless on previous versions (like kvm-37).
Using -no-acpi, I am able to boot the machine with -no-kvm, but the guest still hang with -no-acpi and with -no-kvm-irqchip or lapic enabled. At least on AMD64, I haven't tested yet on an Intel machine.
Signature · 9 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 23 lines · Aurelien Jarno
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 9 lines
Quoted 5 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoIt complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
Quoted 8 lines
The RSDT checksum problem is not new, but it was harmless on previous versions (like kvm-37).
Using -no-acpi, I am able to boot the machine with -no-kvm, but the guest still hang with -no-acpi and with -no-kvm-irqchip or lapic enabled. At least on AMD64, I haven't tested yet on an Intel machine.
Hangs on AMD here as well; works on intel (with -no-acpi).
Signature · 7 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): 47023BBB.3020806-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 27 lines · Avi Kivity
Quoted 26 lines · Aurelien Jarno
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 9 lines
Quoted 5 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoIt complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
The RSDT checksum problem is not new, but it was harmless on previous versions (like kvm-37).
Quoted 7 lines
Quoted 5 lines
Using -no-acpi, I am able to boot the machine with -no-kvm, but the guest still hang with -no-acpi and with -no-kvm-irqchip or lapic enabled. At least on AMD64, I haven't tested yet on an Intel machine.
Hangs on AMD here as well; works on intel (with -no-acpi).
I have finally found time to bisect the problem. The commit that has broken FreeBSD on AMD is already a bit old:
commit aa38840d3d2e0a804e628077df8d8879b496d741
Author: Rusty Russell <rusty-8n+1lVoiYb80n/[email protected]> Date: Sun Sep 9 14:12:54 2007 +0300
KVM: Clean up unloved invlpg emulation
invlpg shouldn't fetch the "src" address, since it may not be valid, however SVM's "solution" which neuters emulation of all group 7 instruction is horrible and breaks kvm-lite. The simplest fix is to put a special check in for invlpg.
Signature · 10 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Quoted 23 lines · Aurelien Jarno
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 9 lines
Quoted 5 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoIt complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
Quoted 8 lines
The RSDT checksum problem is not new, but it was harmless on previous versions (like kvm-37).
Using -no-acpi, I am able to boot the machine with -no-kvm, but the guest still hang with -no-acpi and with -no-kvm-irqchip or lapic enabled. At least on AMD64, I haven't tested yet on an Intel machine.
Looks like there is a compiler problem that's interfering here. A bios compiled on one machine will boot fine on Intel, but on other machines (unfortunately my work machines) will not.
There is a separate issue with -no-acpi on AMD. Is there some version where -no-acpi worked on AMD?
Signature · 7 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): 47027161.50004-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 32 lines · Avi Kivity
Quoted 22 lines · Aurelien Jarno
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 9 lines
Quoted 5 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoIt complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
Quoted 8 lines
The RSDT checksum problem is not new, but it was harmless on previous versions (like kvm-37).
Using -no-acpi, I am able to boot the machine with -no-kvm, but the guest still hang with -no-acpi and with -no-kvm-irqchip or lapic enabled. At least on AMD64, I haven't tested yet on an Intel machine.
Quoted 6 lines
Looks like there is a compiler problem that's interfering here. A bios compiled on one machine will boot fine on Intel, but on other machines (unfortunately my work machines) will not.
There is a separate issue with -no-acpi on AMD. Is there some version where -no-acpi worked on AMD?
It was working correctly before, up to kvm version 37.
I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel.
Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: "No kernel found". And the next time, I get from the *BIOS*: "Boot from Hard Disk failed: not a bootable disk".
Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk.
If I pass either -no-kvm or -no-kvm-irqchip, the problem disappear.
Signature · 9 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 44 lines · Aurelien Jarno
Quoted 31 lines · Avi Kivity
Quoted 22 lines · Aurelien Jarno
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 9 lines
Quoted 5 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoIt complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
Quoted 8 lines
The RSDT checksum problem is not new, but it was harmless on previous versions (like kvm-37).
Using -no-acpi, I am able to boot the machine with -no-kvm, but the guest still hang with -no-acpi and with -no-kvm-irqchip or lapic enabled. At least on AMD64, I haven't tested yet on an Intel machine.
Quoted 6 lines
Looks like there is a compiler problem that's interfering here. A bios compiled on one machine will boot fine on Intel, but on other machines (unfortunately my work machines) will not.
There is a separate issue with -no-acpi on AMD. Is there some version where -no-acpi worked on AMD?
It was working correctly before, up to kvm version 37.
I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel.
Quoted 8 lines
Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: "No kernel found". And the next time, I get from the *BIOS*: "Boot from Hard Disk failed: not a bootable disk".
Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk.
If I pass either -no-kvm or -no-kvm-irqchip, the problem disappear.
I have just got the problem with -no-kvm-irqchip, though it seems to happen less often.
Signature · 9 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 48 lines · Aurelien Jarno
Quoted 47 lines · Aurelien Jarno
Quoted 31 lines · Avi Kivity
Quoted 22 lines · Aurelien Jarno
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 9 lines
Quoted 5 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoIt complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
Quoted 8 lines
The RSDT checksum problem is not new, but it was harmless on previous versions (like kvm-37).
Using -no-acpi, I am able to boot the machine with -no-kvm, but the guest still hang with -no-acpi and with -no-kvm-irqchip or lapic enabled. At least on AMD64, I haven't tested yet on an Intel machine.
Quoted 6 lines
Looks like there is a compiler problem that's interfering here. A bios compiled on one machine will boot fine on Intel, but on other machines (unfortunately my work machines) will not.
There is a separate issue with -no-acpi on AMD. Is there some version where -no-acpi worked on AMD?
It was working correctly before, up to kvm version 37.
I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel.
Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: "No kernel found". And the next time, I get from the *BIOS*: "Boot from Hard Disk failed: not a bootable disk".
Quoted 7 lines
Quoted 4 lines
Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk.
If I pass either -no-kvm or -no-kvm-irqchip, the problem disappear.
I have just got the problem with -no-kvm-irqchip, though it seems to happen less often.
The data corruption seems to come from the userspace part, as I am not able to reproduce it with the kvm-45 module, and the kvm-44 userspace.
Signature · 9 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 10 lines · Aurelien Jarno
Quoted 10 lines
Quoted 10 lines
I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel.
Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: "No kernel found". And the next time, I get from the *BIOS*: "Boot from Hard Disk failed: not a bootable disk".
Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk.
Quoted 10 lines
Quoted 5 lines
Quoted 2 lines
If I pass either -no-kvm or -no-kvm-irqchip, the problem disappear.
I have just got the problem with -no-kvm-irqchip, though it seems to happen less often.
The data corruption seems to come from the userspace part, as I am not able to reproduce it with the kvm-45 module, and the kvm-44 userspace.
Does it occur with -no-kvm?
Signature · 8 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
A message that is not in the archive (sent off-list or not yet received): 470CB4DE.20707-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 16 lines · Avi Kivity
Quoted 15 lines · Aurelien Jarno
Quoted 15 lines
Quoted 12 lines
I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel.
Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: "No kernel found". And the next time, I get from the *BIOS*: "Boot from Hard Disk failed: not a bootable disk".
Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk.
If I pass either -no-kvm or -no-kvm-irqchip, the problem disappear.
I have just got the problem with -no-kvm-irqchip, though it seems to happen less often.
Quoted 7 lines
Quoted 4 lines
The data corruption seems to come from the userspace part, as I am not able to reproduce it with the kvm-45 module, and the kvm-44 userspace.
Does it occur with -no-kvm?
With kvm 45 it does not occurs with -no-kvm.
With kvm 46 the problem is still there, but I haven't tried with -no-kvm yet. I am currently building a small test image, otherwise I spend all my time copying a 15GB image.
Signature · 10 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 30 lines · Aurelien Jarno
Quoted 19 lines · Avi Kivity
Quoted 17 lines · Aurelien Jarno
Quoted 17 lines
Quoted 13 lines
I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel.
Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: "No kernel found". And the next time, I get from the *BIOS*: "Boot from Hard Disk failed: not a bootable disk".
Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk.
If I pass either -no-kvm or -no-kvm-irqchip, the problem disappear.
I have just got the problem with -no-kvm-irqchip, though it seems to happen less often.
Quoted 8 lines
Quoted 5 lines
The data corruption seems to come from the userspace part, as I am not able to reproduce it with the kvm-45 module, and the kvm-44 userspace.
Does it occur with -no-kvm?
Quoted 7 lines
With kvm 45 it does not occurs with -no-kvm.
With kvm 46 the problem is still there, but I haven't tried with -no-kvm yet. I am currently building a small test image, otherwise I spend all my time copying a 15GB image.
Maybe snapshots can help here...
Signature · 8 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Quoted 16 lines · Avi Kivity
Quoted 15 lines · Aurelien Jarno
Quoted 15 lines
Quoted 12 lines
I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel.
Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: "No kernel found". And the next time, I get from the *BIOS*: "Boot from Hard Disk failed: not a bootable disk".
Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk.
If I pass either -no-kvm or -no-kvm-irqchip, the problem disappear.
I have just got the problem with -no-kvm-irqchip, though it seems to happen less often.
Quoted 7 lines
Quoted 4 lines
The data corruption seems to come from the userspace part, as I am not able to reproduce it with the kvm-45 module, and the kvm-44 userspace.
Does it occur with -no-kvm?
After a few more tests, I have been able to reproduce it with the current CVS version of QEMU. I conclude this is a QEMU or a BIOS problem, and not a KVM one.
Sorry for the noise.
Signature · 10 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 30 lines · Aurelien Jarno
Quoted 19 lines · Avi Kivity
Quoted 17 lines · Aurelien Jarno
Quoted 17 lines
Quoted 13 lines
I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel.
Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: "No kernel found". And the next time, I get from the *BIOS*: "Boot from Hard Disk failed: not a bootable disk".
Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk.
If I pass either -no-kvm or -no-kvm-irqchip, the problem disappear.
I have just got the problem with -no-kvm-irqchip, though it seems to happen less often.
Quoted 8 lines
Quoted 5 lines
The data corruption seems to come from the userspace part, as I am not able to reproduce it with the kvm-45 module, and the kvm-44 userspace.
Does it occur with -no-kvm?
Quoted 6 lines
After a few more tests, I have been able to reproduce it with the current CVS version of QEMU. I conclude this is a QEMU or a BIOS problem, and not a KVM one.
Sorry for the noise.
Well, it still needs to be fixed. I think there's a git import of qemu available somewhere, that can be used for bisecting.
Signature · 8 lines
error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
A message that is not in the archive (sent off-list or not yet received): 470CD22C.5050003-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 15 lines · Avi Kivity
Quoted 14 lines · Aurelien Jarno
Quoted 12 lines · Avi Kivity
Quoted 10 lines · Aurelien Jarno
Quoted 10 lines
Quoted 10 lines
I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel.
Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: "No kernel found". And the next time, I get from the *BIOS*: "Boot from Hard Disk failed: not a bootable disk".
Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk.
[snip]
Quoted 10 lines
Quoted 6 lines
After a few more tests, I have been able to reproduce it with the current CVS version of QEMU. I conclude this is a QEMU or a BIOS problem, and not a KVM one.
Sorry for the noise.
Well, it still needs to be fixed. I think there's a git import of qemu available somewhere, that can be used for bisecting.
Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem:
Last AIO patch, by Vladimir N. Oleynik.
http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65
Signature · 10 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 8 lines · Aurelien Jarno
Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem:
Last AIO patch, by Vladimir N. Oleynik.
http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65
Have we learned something about this issue? Should I revert the patch from kvm? Should qemu?
Signature · 8 lines
Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Quoted 4 lines · Avi Kivity
Quoted 3 lines · Aurelien Jarno
Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem:
Quoted 8 lines
Quoted 5 lines
Last AIO patch, by Vladimir N. Oleynik.
http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65
Have we learned something about this issue? Should I revert the patch from kvm? Should qemu?
Sure. The conversion from sync to async mode done in this patch is incomplete to say the least.
Fabrice.
Quoted 12 lines · Fabrice Bellard
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem:
Last AIO patch, by Vladimir N. Oleynik.
http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65
Quoted 5 lines
Quoted 2 lines
Have we learned something about this issue? Should I revert the patch from kvm? Should qemu?
Sure. The conversion from sync to async mode done in this patch is incomplete to say the least.
Is reverting the patch safe, or will it cause new problems?
(I'm not sure what "Sure" above refers to)
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 13 lines · Avi Kivity
Quoted 12 lines · Fabrice Bellard
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem:
Last AIO patch, by Vladimir N. Oleynik.
http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Have we learned something about this issue? Should I revert the patch from kvm? Should qemu?
Sure. The conversion from sync to async mode done in this patch is incomplete to say the least.
Is reverting the patch safe, or will it cause new problems?
The patch must be reverted because it implements incorrectly the AIO write case (e.g. nsector is modified before the IO actually takes place). The previous code was at least correct if win2k_install_hack was not enabled and if one considered than the PIO I/Os were instantaneous.
Regards,
Fabrice.
A message that is not in the archive (sent off-list or not yet received): 4732AF9B.9010201-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 10 lines · Avi Kivity
Quoted 8 lines · Aurelien Jarno
Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem:
Last AIO patch, by Vladimir N. Oleynik.
http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65
Quoted 5 lines
Have we learned something about this issue? Should I revert the patch from kvm? Should qemu?
From my side, I haven't found time to debug the problem. Instead I am
reverting this patch locally each time I install qemu or kvm.
Signature · 10 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Quoted 32 lines · Avi Kivity
Quoted 22 lines · Aurelien Jarno
Quoted 11 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 9 lines
Quoted 5 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoIt complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
Quoted 8 lines
The RSDT checksum problem is not new, but it was harmless on previous versions (like kvm-37).
Using -no-acpi, I am able to boot the machine with -no-kvm, but the guest still hang with -no-acpi and with -no-kvm-irqchip or lapic enabled. At least on AMD64, I haven't tested yet on an Intel machine.
Quoted 7 lines
Looks like there is a compiler problem that's interfering here. A bios compiled on one machine will boot fine on Intel, but on other machines (unfortunately my work machines) will not.
There is a separate issue with -no-acpi on AMD. Is there some version where -no-acpi worked on AMD?
I've found the first bios that is not working on my machine (intel) is at:
commit 41675d73b654bd926670d69551a0903b8a9f7fd5
Author: Avi Kivity <avi-atKUWr5tajBWk0Htik3J/[email protected]> Date: Thu Sep 20 18:45:24 2007 +0200
kvm: bios: advertise pci irqs as active high
now that kvm emulates the ioapic polarity correctly, we must describe the polarity correctly in the acpi tables. otherwise pci interrupts won't be delivered correctly.
Reverting this commit from master allows to boot again freebsd.
It works fine with and without "-no-kvm-irqchip".
But it doesn't allow to make working debian-31r0a-amd64 install CD.
Laurent
Signature · 2 lines
------------- Laurent.Vivier-6ktuUTfB/[email protected] -------------- "Software is hard" - Donald Knuth
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Quoted 10 lines · Avi Kivity
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 8 lines
Quoted 4 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoIt complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
I should have the same kind of problem with debian-31r0a-amd64-netinst.iso which hangs on: " Loading module 'ide-disk' for 'Linux ATA DISK'..."
and "-no-acpi" resolves this too.
Laurent
Signature · 2 lines
------------- Laurent.Vivier-6ktuUTfB/[email protected] -------------- "Software is hard" - Donald Knuth
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
A message that is not in the archive (sent off-list or not yet received): 4702390F.9070809-6ktuUTfB/[email protected]
Quoted 15 lines · Laurent Vivier
Quoted 14 lines · Avi Kivity
Quoted 13 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.iso
Quoted 9 lines
Quoted 3 lines
It complains about the RSDT checksum. Running with -no-acpi works around the problem (it gets to some country selection screen). So it looks like the ACPI tables are messed up.
I should have the same kind of problem with debian-31r0a-amd64-netinst.iso which hangs on: " Loading module 'ide-disk' for 'Linux ATA DISK'..."
and "-no-acpi" resolves this too.
This is most probably the same problem on FreeBSD, as it has destroyed my disk image. I don't know yet if I can repair it or not.
Signature · 9 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Quoted 9 lines · Aurelien Jarno
Hi all,
That's not something new, but I never seen the problem mentioned here. FreeBSD does not work on KVM, approximately since the lapic merge.
However, that does not seem related to lapic, as using -no-kvm-irqchip does not help. With -no-kvm I get a page fault in kernel mode, while the normal QEMU (0.9.0 or CVS) does not have this problem.
Quoted 6 lines
This can be easily reproduced with the latest installation CD:
ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/6.2/6.2-RELEASE-i386-bootonly.isoCheers,
Aurelien
Digging in the FreeBSD sources I found the origin of the problem:
I added some ACPI traces:
rsirq-0234 [13] RsIrqResource : Invalid interrupt polarity/trigger in
resource list, 10
Which is in /sys/contrib/dev/acpica/rsirq.c :
/*
* Check for HE, LL interrupts
*/
switch (Temp8 & 0x09)
{
case 0x01: /* HE */
OutputStruct->Data.Irq.EdgeLevel = ACPI_EDGE_SENSITIVE;
OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_HIGH;
break;
case 0x08: /* LL */
OutputStruct->Data.Irq.EdgeLevel = ACPI_LEVEL_SENSITIVE;
OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_LOW;
break;
default:
/*
* Only _LL and _HE polarity/trigger interrupts
* are allowed (ACPI spec, section "IRQ Format")
* so 0x00 and 0x09 are illegal.
*/
ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
"Invalid interrupt polarity/trigger in resource list, %X\n", Tem
p8));
return_ACPI_STATUS (AE_BAD_DATA);
}Conclusion, in kvm-userspace/bios/acpi-dsdt.dsl, if you have "ActiveHigh", you must have "Edge" instead of "Level":
- IRQ (Level, ActiveHigh, Shared)
+ IRQ (Edge, ActiveHigh, Shared)
But I found nothing in ACPI specification explaining the freeBSD behavior.
Avi, if you think this anlysis is correct I can provide the patch changing "Level" to "Edge"...
Laurent
Signature · 2 lines
---------------- Laurent.Vivier-6ktuUTfB/[email protected] ----------------- "Given enough eyeballs, all bugs are shallow" E. S. Raymond
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
A message that is not in the archive (sent off-list or not yet received): 47063B31.6000001-6ktuUTfB/[email protected]
Quoted 28 lines · Laurent Vivier
Digging in the FreeBSD sources I found the origin of the problem:
I added some ACPI traces:
rsirq-0234 [13] RsIrqResource : Invalid interrupt polarity/trigger in
resource list, 10Which is in
/sys/contrib/dev/acpica/rsirq.c:/* * Check for HE, LL interrupts */ switch (Temp8 & 0x09) { case 0x01: /* HE */ OutputStruct->Data.Irq.EdgeLevel = ACPI_EDGE_SENSITIVE; OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_HIGH; break; case 0x08: /* LL */ OutputStruct->Data.Irq.EdgeLevel = ACPI_LEVEL_SENSITIVE; OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_LOW; break; default: /* * Only _LL and _HE polarity/trigger interrupts
Quoted 9 lines
* are allowed (ACPI spec, section "IRQ Format")
* so 0x00 and 0x09 are illegal.
*/
ACPI_DEBUG_PRINT ((ACPI_DB_ERROR,
"Invalid interrupt polarity/trigger in resource list, %X\n", Tem
p8));
return_ACPI_STATUS (AE_BAD_DATA);
}Good catch!
Quoted 8 lines
Conclusion, in kvm-userspace/bios/acpi-dsdt.dsl, if you have "ActiveHigh", you must have "Edge" instead of "Level":
(quoted diff) +1
-1- IRQ (Level, ActiveHigh, Shared) + IRQ (Edge, ActiveHigh, Shared)But I found nothing in ACPI specification explaining the freeBSD behavior.
It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are connected to PIC-compatible interrupt controllers, which can only be programmed for Active-High-Edge-Triggered or Active- Low-Level-Triggered interrupts. Any other combination is illegal. The Extended Interrupt Descriptor can be used to describe other combinations.
Quoted 3 lines
Avi, if you think this anlysis is correct I can provide the patch changing "Level" to "Edge"...
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
Signature · 10 lines
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [email protected] | [email protected] `- people.debian.org/~aurel32 | www.aurel32.net ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line · Aurelien Jarno
On Fri, Oct 05, 2007 at 03:25:05PM +0200, Laurent Vivier wrote:
[snip]
Quoted 5 lines
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
A third solution should be to restore active level to "ActiveLow" but I tested it and it doesn't work.
Moreover, according qemu/hw/i8259.c I think i8259 works like ACPI spec expects.
But there should be more bugs in ACPI as my Debian Serge amd64 install CD (linux 2.6.8) is only able to boot with "-no-acpi".
Laurent
Signature · 2 lines
---------------- Laurent.Vivier-6ktuUTfB/[email protected] ----------------- "Given enough eyeballs, all bugs are shallow" E. S. Raymond
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Quoted 70 lines · Aurelien Jarno
Quoted 28 lines · Laurent Vivier
Digging in the FreeBSD sources I found the origin of the problem:
I added some ACPI traces:
rsirq-0234 [13] RsIrqResource : Invalid interrupt polarity/trigger in
resource list, 10Which is in
/sys/contrib/dev/acpica/rsirq.c:/* * Check for HE, LL interrupts */ switch (Temp8 & 0x09) { case 0x01: /* HE */ OutputStruct->Data.Irq.EdgeLevel = ACPI_EDGE_SENSITIVE; OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_HIGH; break; case 0x08: /* LL */ OutputStruct->Data.Irq.EdgeLevel = ACPI_LEVEL_SENSITIVE; OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_LOW; break; default: /* * Only _LL and _HE polarity/trigger interruptsQuoted 10 lines
* are allowed (ACPI spec, section "IRQ Format") * so 0x00 and 0x09 are illegal. */ ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "Invalid interrupt polarity/trigger in resource list, %X\n", Tem p8)); return_ACPI_STATUS (AE_BAD_DATA); }Good catch!
Quoted 9 lines
Conclusion, in kvm-userspace/bios/acpi-dsdt.dsl, if you have "ActiveHigh", you must have "Edge" instead of "Level":
(quoted diff) +1
-1- IRQ (Level, ActiveHigh, Shared) + IRQ (Edge, ActiveHigh, Shared)But I found nothing in ACPI specification explaining the freeBSD behavior.
It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are connected to PIC-compatible interrupt controllers, which can only be programmed for Active-High-Edge-Triggered or Active- Low-Level-Triggered interrupts. Any other combination is illegal. The Extended Interrupt Descriptor can be used to describe other combinations.
Quoted 4 lines
Avi, if you think this anlysis is correct I can provide the patch changing "Level" to "Edge"...
Quoted 6 lines
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
Edge-triggered means we can't share interrupt lines. Since we have only two or three that limits the number of devices we can have.
So I'd like to try moving to active low pci interrupts, and implementing polarity in the qemu ioapic. It's probably closer to real hardware anyway.
Signature · 8 lines
Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
A message that is not in the archive (sent off-list or not yet received): 47066153.2040406-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 82 lines · Avi Kivity
Quoted 72 lines · Aurelien Jarno
Quoted 28 lines · Laurent Vivier
Digging in the FreeBSD sources I found the origin of the problem:
I added some ACPI traces:
rsirq-0234 [13] RsIrqResource : Invalid interrupt polarity/trigger in
resource list, 10Which is in
/sys/contrib/dev/acpica/rsirq.c:/* * Check for HE, LL interrupts */ switch (Temp8 & 0x09) { case 0x01: /* HE */ OutputStruct->Data.Irq.EdgeLevel = ACPI_EDGE_SENSITIVE; OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_HIGH; break; case 0x08: /* LL */ OutputStruct->Data.Irq.EdgeLevel = ACPI_LEVEL_SENSITIVE; OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_LOW; break; default: /* * Only _LL and _HE polarity/trigger interruptsQuoted 11 lines
* are allowed (ACPI spec, section "IRQ Format") * so 0x00 and 0x09 are illegal. */ ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "Invalid interrupt polarity/trigger in resource list, %X\n", Tem p8)); return_ACPI_STATUS (AE_BAD_DATA); }Good catch!
Quoted 10 lines
Conclusion, in kvm-userspace/bios/acpi-dsdt.dsl, if you have "ActiveHigh", you must have "Edge" instead of "Level":
(quoted diff) +1
-1- IRQ (Level, ActiveHigh, Shared) + IRQ (Edge, ActiveHigh, Shared)But I found nothing in ACPI specification explaining the freeBSD behavior.
It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are connected to PIC-compatible interrupt controllers, which can only be programmed for Active-High-Edge-Triggered or Active- Low-Level-Triggered interrupts. Any other combination is illegal. The Extended Interrupt Descriptor can be used to describe other combinations.
Quoted 5 lines
Avi, if you think this anlysis is correct I can provide the patch changing "Level" to "Edge"...
Quoted 7 lines
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
Quoted 8 lines
Edge-triggered means we can't share interrupt lines. Since we have only two or three that limits the number of devices we can have.
So I'd like to try moving to active low pci interrupts, and implementing polarity in the qemu ioapic. It's probably closer to real hardware anyway.
The docs are conflicting. The piix3 spec describes the pic irqs (PIRQ[A-D]#) as active low, but the internal pic describes level interrupts as active high. There's probably an inverter in there somewhere.
Signature · 8 lines
Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Quoted 75 lines · Avi Kivity
Quoted 63 lines · Aurelien Jarno
Quoted 28 lines · Laurent Vivier
Digging in the FreeBSD sources I found the origin of the problem:
I added some ACPI traces:
rsirq-0234 [13] RsIrqResource : Invalid interrupt polarity/trigger in
resource list, 10Which is in
/sys/contrib/dev/acpica/rsirq.c:/* * Check for HE, LL interrupts */ switch (Temp8 & 0x09) { case 0x01: /* HE */ OutputStruct->Data.Irq.EdgeLevel = ACPI_EDGE_SENSITIVE; OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_HIGH; break; case 0x08: /* LL */ OutputStruct->Data.Irq.EdgeLevel = ACPI_LEVEL_SENSITIVE; OutputStruct->Data.Irq.ActiveHighLow = ACPI_ACTIVE_LOW; break; default: /* * Only _LL and _HE polarity/trigger interruptsQuoted 10 lines
* are allowed (ACPI spec, section "IRQ Format") * so 0x00 and 0x09 are illegal. */ ACPI_DEBUG_PRINT ((ACPI_DB_ERROR, "Invalid interrupt polarity/trigger in resource list, %X\n", Tem p8)); return_ACPI_STATUS (AE_BAD_DATA); }Good catch!
Quoted 9 lines
Conclusion, in kvm-userspace/bios/acpi-dsdt.dsl, if you have "ActiveHigh", you must have "Edge" instead of "Level":
(quoted diff) +1
-1- IRQ (Level, ActiveHigh, Shared) + IRQ (Edge, ActiveHigh, Shared)But I found nothing in ACPI specification explaining the freeBSD behavior.
It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are connected to PIC-compatible interrupt controllers, which can only be programmed for Active-High-Edge-Triggered or Active- Low-Level-Triggered interrupts. Any other combination is illegal. The Extended Interrupt Descriptor can be used to describe other combinations.
Quoted 10 lines
Quoted 4 lines
Avi, if you think this anlysis is correct I can provide the patch changing "Level" to "Edge"...
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
Quoted 6 lines
Edge-triggered means we can't share interrupt lines. Since we have only two or three that limits the number of devices we can have.
So I'd like to try moving to active low pci interrupts, and implementing polarity in the qemu ioapic. It's probably closer to real hardware anyway.
Avi,
I've two questions:
- why, when you implemented the ioapic polarity bit in kvm (commit 0203e2d5d0d0cea6eed6e437d9456aad71135913, kvm_ioapic_set_irq()), you didn't implement it in qemu (in qemu/hw/apic.c ioapic_set_irq()) ?
- why implementing polarity changes active level in ACPI ?
Thanks,
Laurent
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
A message that is not in the archive (sent off-list or not yet received): 47074989.9080100-6ktuUTfB/[email protected]
Quoted 9 lines · Laurent Vivier
Quoted 8 lines
Edge-triggered means we can't share interrupt lines. Since we have only two or three that limits the number of devices we can have.
So I'd like to try moving to active low pci interrupts, and implementing polarity in the qemu ioapic. It's probably closer to real hardware anyway.
Quoted 8 lines
Avi,
I've two questions:
- why, when you implemented the ioapic polarity bit in kvm (commit
0203e2d5d0d0cea6eed6e437d9456aad71135913,kvm_ioapic_set_irq()), you didn't implement it in qemu (inqemu/hw/apic.cioapic_set_irq()) ?
Laziness
Quoted 2 lines
- why implementing polarity changes active level in ACPI ?
Qemu has two bugs:
- ACPI (and MP-BIOS) advertises the PCI interrupts as active low
- IOAPIC polarity is not implemented
The bugs cancel each other out. I fixed one by implementing polarity, now we have to fix the other.
Signature · 8 lines
Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Quoted 10 lines · Aurelien Jarno
It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are connected to PIC-compatible interrupt controllers, which can only be programmed for Active-High-Edge-Triggered or Active- Low-Level-Triggered interrupts. Any other combination is illegal. The Extended Interrupt Descriptor can be used to describe other combinations.
Quoted 9 lines
Quoted 4 lines
Avi, if you think this anlysis is correct I can provide the patch changing "Level" to "Edge"...
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
The attached patch attempts to override the pci irqs (now limited to 5, 9, 10, and 11) to be active high level triggered. Linux boots and parses this correctly. Freebsd still fails.
Signature · 1 line
Any sufficiently difficult bug is indistinguishable from a feature.
bios/rombios32.c +23 -1
@@ -1181,6 +1181,14 @@ struct madt_io_apic* lines start */ }; +struct madt_interrupt_source_override { +APIC_HEADER_DEF + uint8_t bus; +uint8_t source; +uint32_t gsi; +uint16_t flags; +} __attribute__((__packed__ )); +#include "acpi-dsdt.hex" static inline uint16_t cpu_to_le16 (uint16_t x)
@@ -1273,7 +1281,8 @@ void acpi_bios_init(void) madt_addr = addr; madt_size =sizeof (*madt) +sizeof (struct madt_processor_apic ) * smp_cpus + -sizeof (struct madt_io_apic ); +sizeof (struct madt_io_apic ) + +sizeof (struct madt_interrupt_source_override ) *4 ; madt = (void *)(addr); addr += madt_size;
@@ -1335,6 +1344,8 @@ void acpi_bios_init(void) {struct madt_processor_apic *apic;struct madt_io_apic *io_apic; +struct madt_interrupt_source_override *iso; +static int pci_irq[4 ] = {5 ,9 ,10 ,11 };memset (madt,0 , madt_size); madt->local_apic_address =cpu_to_le32 (0xfee00000 );
@@ -1354,6 +1365,17 @@ void acpi_bios_init(void) io_apic->io_apic_id = smp_cpus; io_apic->address =cpu_to_le32 (0xfec00000 ); io_apic->interrupt =cpu_to_le32 (0 ); + io_apic++; + iso = (void *)io_apic; +for (i =0 ; i <4 ; ++i) { + iso->type =APIC_XRUPT_OVERRIDE ; + iso->length =sizeof (*iso); + iso->bus =0 ; + iso->source = pci_irq[i]; + iso->gsi =cpu_to_le32 (iso->source); + iso->flags =cpu_to_le16 (0xd );// active high level trigger + ++iso; + }acpi_build_table_header ((struct acpi_table_header *)madt,"APIC" , madt_size);
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
A message that is not in the archive (sent off-list or not yet received): 4709E2DF.10701-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 28 lines · Avi Kivity
Quoted 20 lines · Aurelien Jarno
It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are
connected to PIC-compatible
interrupt controllers, which can only be programmed for
Active-High-Edge-Triggered or Active-
Low-Level-Triggered interrupts. Any other combination is illegal.
The Extended Interrupt
Descriptor can be used to describe other combinations.Quoted 5 lines
Avi, if you think this anlysis is correct I can provide the patch changing
"Level" to "Edge"...Quoted 6 lines
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
Quoted 3 lines
The attached patch attempts to override the pci irqs (now limited to 5, 9, 10, and 11) to be active high level triggered. Linux boots and parses this correctly. Freebsd still fails.
FreeBSD will fail while ACPI will have Active-High and Level-triggered, except if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI table.
BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your patch (as before).
Moreover, I don't understand what this patch resolves...
Laurent
Signature · 2 lines
---------------- Laurent.Vivier-6ktuUTfB/[email protected] ----------------- "Given enough eyeballs, all bugs are shallow" E. S. Raymond
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
A message that is not in the archive (sent off-list or not yet received): 4709E896.1090806-6ktuUTfB/[email protected]
Quoted 36 lines · Laurent Vivier
Quoted 29 lines · Avi Kivity
Quoted 20 lines · Aurelien Jarno
It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are
connected to PIC-compatible
interrupt controllers, which can only be programmed for
Active-High-Edge-Triggered or Active-
Low-Level-Triggered interrupts. Any other combination is illegal.
The Extended Interrupt
Descriptor can be used to describe other combinations.Quoted 6 lines
Avi, if you think this anlysis is correct I can provide the patch changing
"Level" to "Edge"...Quoted 7 lines
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
Quoted 4 lines
The attached patch attempts to override the pci irqs (now limited to 5, 9, 10, and 11) to be active high level triggered. Linux boots and parses this correctly. Freebsd still fails.
Quoted 7 lines
FreeBSD will fail while ACPI will have Active-High and Level-triggered, except if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI table.
BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your patch (as before).
Moreover, I don't understand what this patch resolves...
I thought this was the extended interrupt descriptor; sorry my confusion.
Meanwhile I changed the dsdt to use the _real_ extended enhanced advanced improved interrupt descriptor, and freebsd now boots. FC6 and Windows survived. I'll push this after further testing.
Signature · 8 lines
Any sufficiently difficult bug is indistinguishable from a feature. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
A message that is not in the archive (sent off-list or not yet received): 4709FAC1.8050502-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 42 lines · Avi Kivity
Quoted 41 lines · Laurent Vivier
Quoted 29 lines · Avi Kivity
Quoted 20 lines · Aurelien Jarno
It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are
connected to PIC-compatible
interrupt controllers, which can only be programmed for
Active-High-Edge-Triggered or Active-
Low-Level-Triggered interrupts. Any other combination is illegal.
The Extended Interrupt
Descriptor can be used to describe other combinations.Quoted 6 lines
Avi, if you think this anlysis is correct I can provide the patch changing
"Level" to "Edge"...Quoted 7 lines
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
Quoted 4 lines
The attached patch attempts to override the pci irqs (now limited to 5, 9, 10, and 11) to be active high level triggered. Linux boots and parses this correctly. Freebsd still fails.
FreeBSD will fail while ACPI will have Active-High and Level-triggered, except if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI table.
BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your patch (as before).
Quoted 7 lines
Quoted 1 line
Moreover, I don't understand what this patch resolves...
I thought this was the extended interrupt descriptor; sorry my confusion.
Meanwhile I changed the dsdt to use the _real_ extended enhanced advanced improved interrupt descriptor, and freebsd now boots. FC6 and Windows survived. I'll push this after further testing.
Great !
If you send me your patch I can test it and make it run on distros I have (I can wait the push too).
Is this THE solution to this issue or only a workaround ?
Laurent
Signature · 2 lines
---------------- Laurent.Vivier-6ktuUTfB/[email protected] ----------------- "Given enough eyeballs, all bugs are shallow" E. S. Raymond
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
A message that is not in the archive (sent off-list or not yet received): 470A07FC.80407-6ktuUTfB/[email protected]
Quoted 60 lines · Laurent Vivier
Quoted 49 lines · Avi Kivity
Quoted 47 lines · Laurent Vivier
Quoted 33 lines · Avi Kivity
Quoted 22 lines · Aurelien Jarno
It's actually described page 200 of the specifications (page 216 in ACPIspec30.pdf):
Note: This descriptor is meant for describing interrupts that are
connected to PIC-compatible
interrupt controllers, which can only be programmed for
Active-High-Edge-Triggered or Active-
Low-Level-Triggered interrupts. Any other combination is illegal.
The Extended Interrupt
Descriptor can be used to describe other combinations.Quoted 7 lines
Avi, if you think this anlysis is correct I can provide the patch changing
"Level" to "Edge"...Quoted 8 lines
It looks like the solution is either to describe the IRQ with an "Extended Interrupt Descriptor" or to change this value to one of the two allowed values. In the later case we have to make sure it is consistent with the way the PIC works.
Quoted 5 lines
The attached patch attempts to override the pci irqs (now limited to 5, 9, 10, and 11) to be active high level triggered. Linux boots and parses this correctly. Freebsd still fails.
FreeBSD will fail while ACPI will have Active-High and Level-triggered, except if you define, as Aurélien said, an "Extended Interrupt Descriptor" in ACPI table.
BTW, I'm not able to boot Debian Sarge (2.6.8-11-amd64-generic) with your patch (as before).
Quoted 8 lines
Quoted 2 lines
Moreover, I don't understand what this patch resolves...
I thought this was the extended interrupt descriptor; sorry my confusion.
Meanwhile I changed the dsdt to use the _real_ extended enhanced advanced improved interrupt descriptor, and freebsd now boots. FC6 and Windows survived. I'll push this after further testing.
Quoted 5 lines
Great !
If you send me your patch I can test it and make it run on distros I have (I can wait the push too).
It's now pushed.
Quoted 2 lines
Is this THE solution to this issue or only a workaround ?
I think this solves the issue completely. The only question is whether other guests have regressed.
Signature · 8 lines
Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/