Most recent kernel where this bug did *NOT* occur: Distribution: Debian etch Hardware Environment: toshiba P100-473 (intel) Software Environment: Problem Description: Hi, I'm posting here from Len Brown advice. This is a well-known issue, I know. So I have browsed http://acpi.sourceforge.net/dsdt/view.php but I did not see my model (aka PSPAGE-00S011FR). So I have followed http://forums.gentoo.org/viewtopic-t-444743-highlight-sndhdaintel.html which has almost fixed issues (ie ACPI enabled + sound works perfectly). By the way, that fix seems to break elsewhere: for instance, keyboard does not work anymore as expected (a few multimedia keys are broken). Steps to reproduce: I have modified a few lines in my original DSDT, as described in the gentoo's forum: - replace all occurences of _T_[0-7] by something else because iasl does not like them; - complete the return path for method BTST with Return (Zero) - replace "*PNP0C14" by "PNP0C14" - comment a few lines in Scope (\_SB) and added to the end the line Store (0x07D6, OSYS) which is commented as "Fake Windows 2006" in the gentoo's forum. Please note that if the only last line (Store (0x07D6, OSYS)) is omitted, sound does not work (and keyboard works fine ;-) Thanks in advance for any help. Cheers,
> - replace "*PNP0C14" by "PNP0C14" The Linux/ACPI interpreter includes a workaround to ignore the leading '*' in PNP-id's. However, iASL requires that you address this if you want to build your DSDT. PNP0C14 is the id for Windows Management Instrumentation (WMI) which Linux does not support, so you should get the same results if you delete this device from the DSDT entirely. (though this reminds me, Linux should warn when it finds PNP0C14 that it can't talk to the platform's windows-specific hooks) Please attach the complete output from acpidump, plus the diff showing the changes you made to get sound to work. Store (0x07D6, OSYS) sounds like it might be an _OSI issue.
Looking on the gentoo forums link, I see this: Scope (\_SB) { Method (_INI, 0, NotSerialized) { If (DTSE) { TRAP (0x47) } Store (0x07D0, OSYS) // If (CondRefOf (_OSI, Local0)) // { // If (_OSI ("Linux")) // { // Store (0x03E8, OSYS) // } // Else // { // Store (0x07D1, OSYS) // If (_OSI ("Windows 2001 SP2")) // { // Store (0x07D2, OSYS) // } // If (_OSI ("Windows 2001.1")) // { // Store (0x07D3, OSYS) // } // If (_OSI ("Windows 2001.1 SP1")) // { // Store (0x07D4, OSYS) // } // If (_OSI ("Windows 2006")) // { // Store (0x07D6, OSYS) // } // If (LAnd (MPEN, LEqual (OSYS, 0x07D1))) // { // TRAP (0x3D) // } // } // } Store (0x07D6, OSYS) // Fake Windows 2006 } The issue here is that the BIOS is explicitly looking for "Linux" and setting OSYS based on that. When I get your acpidump, we can look at what the AML does with OSYS, but the quick thing to try right now is to boot with the original BIOS with "acpi_osi=" which will disable _OSI support alltogether. It will not cause the BIOS to go down the WinXP path, but it will prevent it from going down the "Linux" path, whatever that turns out to be.
Created attachment 10973 [details] patch vs 2.6.21-rc5 to remove "Linux" from kernel _OSI strings This patch removes "Linux" from the pre-defined kernel _OSI strings. Please try it out using the unmodified BIOS and without the use of the acpi_osi= parameter. It will cause the BIOS to not take the "Linux" path above. But until we review the actual DSDT, it is a guessing game exactly what effect(s) this will have on the system.
*** This bug has been marked as a duplicate of 7787 ***
Created attachment 10974 [details] complete acpidump file log
Created attachment 10975 [details] DSDT diff between original & modified files
bugme-daemon@bugzilla.kernel.org a