http://bugzilla.kernel.org/show_bug.cgi?id=9487
------- Comment #10 from [EMAIL PROTECTED] 2007-12-25 07:46 ------- The AML buffers are more interesting (cf. ACPI spec, p. 203): Here's what _CRS returns: 47 01 38 03 38 03 01 08 // IO 23 10 00 01 // IRQ: IRQ 4, 3 bytes, High true, edge sensitive, non-shareable 79 8c // END TAG And here's what the kernel passes to _SRS: 47 01 38 03 3f 03 00 08 // IO 22 10 00 // IRQ: IRQ 4, 2 bytes, hence it defaults to High true, edge sensitive, non-shareable 79 00 00 // END TAG Apparently the firmware has problems interpreting 2-byte IRQ descriptors. If I remove the code in drivers/acpi/resources/rsio.c that checks if the third byte is necessary, the following AML buffer is passed instead: 47 01 38 03 3f 03 00 08 23 10 00 01 79 00 and the device resumes properly. I'm not sure what to do now, since what the kernel does is correct the problem is buggy firmware. Just disabling the check could potentially break devices that are not standard-compliant in the opposite direction (I'm not sure how likely this is though). I think there is something to be said about being as faithful as possible to what _CRS returns, though. So maybe adding a field u8 use_3_byte_descriptor to acpi_resource_irq that keeps track of whether _CRS returned a 3-byte descriptor even though this wasn't necessary would be a better idea? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------- 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/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
