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

Hi Aurélien,

did you try kvm-45 ?

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 · 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 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.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.

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.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.

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 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.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.

The RSDT checksum problem is not new, but it was harmless on previous versions (like kvm-37).

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).

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.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.

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 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.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.

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?

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.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.

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.

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.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.

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 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.

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 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.

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 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?

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?

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.

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 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?

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?

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.

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.

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

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 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?

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 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.

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?

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?

From my side, I haven't found time to debug the problem. Instead I am

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.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.

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?

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 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.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.

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 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.

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

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":

(quoted diff) +1 -1

-                    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"...

On Fri, Oct 05, 2007 at 03:25:05PM +0200, Laurent Vivier wrote:

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 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, 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

Quoted 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"...

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 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, 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

Quoted 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.

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 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, 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

Quoted 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.

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

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 ?

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"...

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 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.

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 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).

Moreover, I don't understand what this patch resolves...

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 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.

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.

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 ?