Hi, First of all i need to apologize for the summary not being clear, but i'm fairly new to ACPI problem and i can't say what is the root of this one (probably a buggy BIOS, so i make only one post with all my bug as i think they're all related). I encounter the following bug in a fresh install of gentoo Linux with the 2.6.37 linux kernel vanilla source and after googling around, i can't find anywhere a real explanation of this problem and if i can fix it. 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) and some line after [ 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 line. And just after this firware bug stuff : [ 0.547508] ACPI Exception: AE_NOT_FOUND, Evaluating _PRW (20101013/scan-723) I don't know if this is related but my fan doesn't work as expected (35°C at boot and 65°C after 1 hour of idle) I attach my dmesg log, all of my /sys/firmware/acpi/tables, my kernel .config file, and the result of lspci -vvv. Please let me know if you need more information. I'm not understanding well what happen but i have time to debug, test everything you want to solve this problem and to learn
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.