Distribution: Debian Etch Hardware Environment: MSI-9625, Pentium M 733, 2x 512MB DDR2 Problem Description: I tried to korrekt the DSDT for the MSI-9625 board following some tutorials I found, but it becomes worse than before. dmidecode, acpidump and dmesg will be attached. Symptoms of my problem are: [1] no correct values in /proc/acpi/processors/CPU0/info (Pentium M 773 ULV) [2] no changes in /proc/acpi/thermal_zone/THRM/temperature (permanently 40°C, is not true) [3] could not load kernel module acpi_cpufreq (No such device, < should it be possible to load?) [4] part of kern.log: Jul 11 15:56:14 unimatrix kernel: ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] Jul 11 15:56:14 unimatrix kernel: ACPI: Getting cpuindex for acpiid 0x1 Jul 11 15:56:14 unimatrix kernel: ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] Jul 11 15:56:14 unimatrix kernel: ACPI: Getting cpuindex for acpiid 0x2 Jul 11 15:56:14 unimatrix kernel: ACPI Exception (acpi_processor-0681): AE_NOT_FOUND, Processor Device is not present [20060707] Jul 11 15:56:14 unimatrix kernel: ACPI: Getting cpuindex for acpiid 0x3
Created attachment 11996 [details] dmidecode
Created attachment 11997 [details] acpidump
Created attachment 11998 [details] dmesg
The main problem seem to be that APIC table lists only one processor (true), while DSDT lists four. Linux then thinks that other processors 0x01,0x02,0x03 could be hot-plugged, but they lack _STA method (don't support hotplug). Thus acpi_processor gets an error, and don't show any information at all. Could you please check if latest kernel from kernel.org (2.6.22 ATM) has this problem too?
You get 40 degrees because of SSHU value refenced in Method RTMP is 0x01.
(In reply to comment #4) > Could you please check if latest kernel from kernel.org (2.6.22 ATM) has this > problem too? I checked with Kernel 2.6.22.1 an it seems to be the same problem. Jul 13 00:38:25 unimatrix kernel: ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not present [20070126] Jul 13 00:38:25 unimatrix last message repeated 2 times
(In reply to comment #5) > You get 40 degrees because of SSHU value refenced in Method RTMP is 0x01. I'm not really close to ASL, so how can I fix that?
I would start from checking if the BIOS is latest and that all values in it are at default settings... SSHU is exported by BIOS/HW, so the only choice in DSDT is to ignore it (remove check in RTMP).
(In reply to comment #4) > The main problem seem to be that APIC table lists only one processor (true), > while DSDT lists four. Linux then thinks that other processors 0x01,0x02,0x03 > could be hot-plugged, but they lack _STA method (don't support hotplug). So will it be a fix removing the 0x01, 0x02, 0x03 entry in DSDT?
bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8734 > > > > > > ------- Comment #9 from norman_ziert@web.de 2007-07-21 04:09 ------- > (In reply to comment #4) > >> The main problem seem to be that APIC table lists only one processor (true), >> while DSDT lists four. Linux then thinks that other processors >> 0x01,0x02,0x03 >> could be hot-plugged, but they lack _STA method (don't support hotplug). >> > > So will it be a fix removing the 0x01, 0x02, 0x03 entry in DSDT? > > > May be, worth a try. Regards, Alex.
> > So will it be a fix removing the 0x01, 0x02, 0x03 entry in DSDT? > > > May be, worth a try. > It seems to be a fix, but I need the PBlK System IO adress for Processor (\_PR.CPU0, 0x00, ...) Is it possible to find out the correct adress?
Norman, please check http://bugzilla.kernel.org/show_bug.cgi?id=8570#c21 to see how to get rid of these message when they are not necessary. could you please try that and tell us the new result of those problems? Again, have you checked to see if there is a newer bios available? thanks.
A new bios is not available. Before I reported the bug here, I argued with the MSI support. They only answered with a BIOS for a different board. It is be a bit risky to flash this, isn't it??? I tried to compile 2.6.23.1 with the suggested patch, but I get an error. I will try it with debian-kernel 2.6.18 the next time.
Norman, what's the error you get from compiling the suggested patch?
Sorry, I was too busy the last weeks, so I could not take care about my problem. I forgot the error message, but now I tried to compile it another time from scratch. It resulsts with no error on kernel 2.6.23.1 and there aren't any ACPI exceptions anymore, so it seams to work fine. So we can say point [3] is solved. Thanks a lot! But [1] and [2] are still to be done. May be they're BIOS-related.
Will you please attach the output of dmesg and /proc/cpuinfo ? It will be great if you can enable the debug function of ACPI and CPU freq in kernel configuration and boot the system with the option of "acpi.debug_layer=0x01000000 acpi.debug_level=0x1F".
> [1] no correct values in /proc/acpi/processors/CPU0/info (Pentium M 773 ULV) Please paste the contents of /proc/acpi/processors/CPU0/info here > [2] no changes in /proc/acpi/thermal_zone/THRM/temperature > (permanently 40°C, is not true) per Alexey's comments above, this is a BIOS/platform issue that Linux can not fix. > [3] could not load kernel module acpi_cpufreq > (No such device, < should it be possible to load?) please respond to comment #16
Created attachment 14381 [details] dmesg-output
Created attachment 14382 [details] proc_cpuinfo
Created attachment 14383 [details] proc_acpi_processor_cpu0_info
Sorry ykzhao for my late response. I added the outputs you an Len wanted of the patched kernel 2.6.23.1 (see comment #15).
Will you please attach the output using the following command ? acpidump --addr 0xff810 --length 0x100 -o output Thanks.
Hi, Norman Thanks for the info. What Alexey said is right. The remained two problems are caused by broken BIOS. a. /proc/acpi/processors/CPU0/info In the DSDT there is no PBLK address in the definition of processor block. >Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00) Correct defintion should be : Processor(\_PR.CPU0, 0x00, 0x410, 0x06) At the same time there is no _PTC defintion for throttling control in DSDT. The flag of throttling control and limit will be zero. In the FADT table the following can be found: [060h 096 2] C2 Latency : 0065 . [062h 098 2] C3 Latency : 03E9 [068h 104 1] Duty Cycle Offset : 01 [069h 105 1] Duty Cycle Width : 01 In the DSDT table there is no _CST defintion for power management. And C2 latency 0x65 > 100, C3 latency 0x3E9 > 1000 means that system can't support C2 /C3. The power interface can't be supported. b. Temperature always is 40. In the DSDT table the result of _TMP is related to the following two definitions: SENF, SSHU If the values of SENF and SSHU are both one, the temperature will always be 40. (Linux can't fix it). The output in comment #22 can confirm whether the the values are one.
Created attachment 14640 [details] requested acpidump output of acpidump --addr 0xff810 --length 0x100
Hi, Norman Thanks for the info. From the info in comment #24 we can know that SENF is 0x0001 and SSHU bit is 1. So the _TMP method will always return 40 temperature.( _TMP returns 0xC3C and the result is converted to 40). So this problem is caused by broken bios. It is more appropriate to fix this by bios.(Linux can't fix it).
Hi, Norman From the log in comment #18 it seems that the acpi-cpufreq module isn't loaded. But it is not helpful to find the root cause. Will you please enable the debug function of acpi and cpufreq in kernel configuration and boot the system with the option of "acpi.debug_layer=0x01000000 acpi.debug_level=0x1f cpufreq.debug=0x7" ? Please attach the output of dmesg. It will be great if you can attach the .config file. Thanks.
There are four problems in this bug. The first two problems are caused by broken bios. The detailed explanation can be found in the comment #23 and #25. The patch for the following problem can be found in comment #54 of http://bugzilla.kernel.org/show_bug.cgi?id=8570 >AE_NOT_FOUND, Processor Device is not present [20060707] The remaing problem is that acpi_cpufreq can't be loaded. (No such device) Since there is no reponse for more than one month, the bug will be rejected. If the problem still exists, please reopen the bug and attach the output required in comment #26. Thanks.