Laurent Vivier wrote: > Avi Kivity wrote: > >> Laurent Vivier wrote: >> >>> Avi Kivity wrote: >>> >>> >>>> Aurelien Jarno wrote: >>>> >>>> >>>>> 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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> 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. >>>> >>>> >>> 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. >> > > 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. > 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. -- 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/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
