Bug 35392
Summary: | ACPI Firmware Bug in Asus K52JT | ||
---|---|---|---|
Product: | ACPI | Reporter: | Claude Juif (claude.juif) |
Component: | BIOS | Assignee: | Lan Tianyu (tianyu.lan) |
Status: | CLOSED INVALID | ||
Severity: | low | CC: | claude.juif, lenb, tianyu.lan |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 2.6.37 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
My dmesg log
kernel .config lspci -vvv output /sys/firmware/acpi/tables/APIC /sys/firmware/acpi/tables/DBGP /sys/firmware/acpi/tables/DSDT /sys/firmware/acpi/tables/ECDT /sys/firmware/acpi/tables/FACP /sys/firmware/acpi/tables/FACS /sys/firmware/acpi/tables/HPET /sys/firmware/acpi/tables/MCFG /sys/firmware/acpi/tables/SLIC /sys/firmware/acpi/tables/SSDT |
Description
Claude Juif
2011-05-19 09:06:20 UTC
Created attachment 58432 [details]
My dmesg log
Created attachment 58442 [details]
kernel .config
Created attachment 58452 [details]
lspci -vvv output
Created attachment 58462 [details]
/sys/firmware/acpi/tables/APIC
Created attachment 58472 [details]
/sys/firmware/acpi/tables/DBGP
Created attachment 58482 [details]
/sys/firmware/acpi/tables/DSDT
Created attachment 58492 [details]
/sys/firmware/acpi/tables/ECDT
Created attachment 58502 [details]
/sys/firmware/acpi/tables/FACP
Created attachment 58512 [details]
/sys/firmware/acpi/tables/FACS
Created attachment 58522 [details]
/sys/firmware/acpi/tables/HPET
Created attachment 58532 [details]
/sys/firmware/acpi/tables/MCFG
Created attachment 58542 [details]
/sys/firmware/acpi/tables/SLIC
Created attachment 58552 [details]
/sys/firmware/acpi/tables/SSDT
Tested with 2.6.38.6 mainline kernel, the following message has disappear : [ 0.547508] ACPI Exception: AE_NOT_FOUND, Evaluating _PRW (20101013/scan-723) But the two others message remain. Any idea on how to fix this ? (In reply to comment #0) > The first warning is : > > [ 0.000000] ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS > tables! (20101013/tbfadt-369) > [ 0.000000] ACPI Warning: 32/64X FACS address mismatch in FADT - > 0xBEDB7F40/0x00000000BEDD1D40, using 32 (20101013/tbfadt-486) This is just a warning. It has no affection. > [ 0.471714] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query honored via > cmdline > This line was originally : > [Firmware Bug] ACPI: BIOS _OSI(Linux) query ignored > and was replace by the new one after i set acpi_osi=Linux at the kernel > command When cmdline contains acpi_osi=Linux and _OSI(linux) is queried, kernel produces the message. _OSI(Linux) returns false default. Bios should not query _OSI(Linux). It's Bios issue. But kernel is compatible with such Bios. _OSI(Linux) return true when set acpi_osi=Linux. Since those messages just reflect the firmware bug and kernel has done some thing with those bugs, close the bug. I think you can try set acpi_osi=Linux or not to find whether your problem is resolved or not. Currently no clue is directly related with "fan work" problem. Please file a separate bug against the fan, and note if the fan works for Windows, or if that is untested. Re: OSI(Linux) The broken BIOS DSDT looks for this in two places. Store (0x07D0, OSYS) If (CondRefOf (\_OSI, Local0)) { If (\_OSI ("Linux")) { Store (0x03E8, OSYS) } If (\_OSI ("Windows 2001")) ... and then it checks a bunch of other versions of windows and Linux will answer YES to all of them. So this \_OSI ("Linux") has zero effect. Method (MSOS, 0, NotSerialized) { If (CondRefOf (\_OSI, Local0)) { If (\_OSI ("Windows 2001")) { Store (OSXP, OSFG) } If (\_OSI ("Windows 2001 SP1")) { Store (OSXP, OSFG) } If (\_OSI ("Windows 2001 SP2")) { Store (OSXP, OSFG) } If (\_OSI ("Windows 2006")) { Store (OSVT, OSFG) } If (\_OSI ("Linux")) { Store (OSEG, OSFG) } If (\_OSI ("Windows 2009")) { Store (OSW7, OSFG) } Return (OSFG) } Here they check Linux next to last before over-writing OSFG. So it will have an effect only if Linux doesn't answer YES to Windows 2009, which is does. ie. "acpi_osi=Linux" will have 0 effect on the operation of your system "acpi_osi=Linux" "acpi_osi=!Windows 2009" could have some effect on the operation of your system, though in reviewing the DSDT I didn't notice any. |