Most recent kernel where this bug did not occur: None Distribution: Mandriva Linux Cooker Hardware Environment: Lenovo 3000 V100 Software Environment: N/A Problem Description: Fan control does not work on this system (an ultraportable notebook produced by Lenovo). No matter how high the CPU load or how hot the system gets, the fans never spin up above their minimum speed. This means that as soon as the CPU is under full load for a few minutes (e.g. compiling anything), the system hits the critical temperature point (100 C, it appears to be thermal zone 1 that hits this temperature, I'm guessing that's the core temperature of one of the processors) and automatically shuts down (it's a kernel-triggered clean shutdown, not a BIOS triggered hard cut-out). I mark this as high severity because it severely restricts what you can actually *do* with the system without causing it to shut down. More info: I talked to someone (I forget who) a few months back who thought the fact that /proc/acpi/fan is empty is significant here, so I mention that. I did check the DSDT, following the instructions at http://acpi.sourceforge.net/dsdt/index.php : it contains one error, which I corrected, but booting with the corrected DSDT does not help. It also contains some warnings I don't know how to fix. I can provide more info on this if necessary. I mostly use a Mandriva kernel (actually kernel-tmb, produced by Thomas Backlund), but I have verified that this also occurs with a clean upstream kernel. No proprietary kernel modules are loaded. I have never observed this working with any kernel since I bought the machine (that goes back to 2.6.17), so I conclude that it's never worked. Steps to reproduce: Hard part is getting hold of the same model laptop, I guess. When you have one it's easy: just try and compile anything that takes more than a couple of minutes. Monitor the temperature while it happens, note that the fans don't spin up, then watch it power down in the middle of the process.
Additional notes: there's an Ubuntu forum thread on the issue here: http://ubuntuforums.org/showthread.php?p=2962823 the exact model variant of my v100 is 0763-C5U , in case that's important. I've updated the BIOS and embedded controller firmware several times from the Lenovo website without improvement, I'm going to and double-check that I've tried the latest BIOS now.
Forgot to update the bug report: yes, I am indeed already using the latest BIOS. would appreciate some attention on this. Now it's summer I can't even run VirtualBox without the system shutting down. sigh.
please attach the output from acpidump
Here you go. Thanks for taking a look at this.
Created attachment 12150 [details] output of acpidump on Lenovo 3000 V100
Well, nothing interesting. :( No fan device shown in acpidump. Could you please check the BIOS and see if there are any options that related to fan control? BTW: four dynamic SSDTs are loaded, but I think they are for CPU P-state/C-state control. You can dump them as well. #acpidump --addr 0x5F69A2B7 --length 0x1A8 >CPU0-IST #acpidump --addr 0x5F69A45F --length 0x45F >CPU1-IST #acpidump --addr 0x5F69A01E --length 0x214 >CPU0-CST #acpidump --addr 0x5F69A232 --length 0x85 >CPU1-CST
"Could you please check the BIOS and see if there are any options that related to fan control?" I have done before, and...nada. It's probably worth noting that I've never actually run Windows on this machine so I can't say 100% it doesn't do the same thing there too. I'm just assuming that Lenovo aren't dumb enough to ship a laptop that crashes after a few minutes of full CPU load in Windows...and the Ubuntu thread seems to confirm that. Do you guys know anyone at Lenovo? I'll do the additional dumps tomorrow.
I'm now trying to verify it really does have fan control... This review says it does: http://www.notebookcheck.net/Review-Lenovo-3000-V100.1373.0.html "Suffice to say that during normal operation (as well as while idle) the fan sets in motion from time to time only (every 5-8 minutes while browsing the web with the help of the WLAN module) and rotates so discreetly, that one can't really realize when exactly it fades away (provided that we're indulged in work and not doing a test of the emissions). Speeding it up to a higher gear (level 2) is quite a feat. In order to achieve it, one needs a full load applied to it, preferably 3D graphics processing." Anyway, I'm attaching the additional dumps you requested. I'll try and do some by-ear testing later...
Created attachment 12159 [details] CPU0-CST dump
Created attachment 12160 [details] CPU0-IST dump
Created attachment 12161 [details] CPU1-CST dump
Created attachment 12162 [details] CPU1-IST dump
You know what, after isolating all noise sources in the room I've realized that it actually does spin the fans up under load. It's just very hard to notice, and they're about as useful as a sponge submarine, as the thing still overheats (took about one minute of building Secret Maryo Chronicles for the fans to spin up and the temperature to hit 94 degrees according to acpi -V). So it seems that what I didn't believe is actually true - Lenovo just built a laptop with really shit thermal characteristics and there's not much we can do about it. Sorry for the noise.
*** Bug 9188 has been marked as a duplicate of this bug. ***
This is a regression bug, because it didn't happen with previous versions of the kernel. It didn't happen to me until I upgraded from Ubuntu 7.04 to Ubuntu 8.04. I'm not sure what kernel version I had then. This should be reopened.
Are you sure you have the same bug as this one? Please file a new bug report and attach the dmesg of 7.04/8.04 and acpidump output.
Created attachment 16296 [details] Output of sudo dmesg (In reply to comment #16) > Are you sure you have the same bug as this one? > Please file a new bug report and attach the dmesg of 7.04/8.04 and acpidump > output. Hi Rui. Right now I'm compiling the kernel to fix the ACPI after compiling a new DSDT.aml file. I followed these instructions: http://forums.gentoo.org/viewtopic.php?t=122145 I did a clear install from Ubuntu 7.04 to Ubuntu 8.04. So the dmesg and acpidump is just for 8.04. If you search in Google you will find that a lot of people are having fan problems with the new kernels, and most people report that it didn't happen to them before. It didn't happen to me before, and I had FoldingAtHome installed, so my CPU was working hard most of the time. So you are right and the problem seems to be in the BIOS' DSDT.aml file, but shouldn't Linux "just work", like Windows? I'm not a kernel developer, but I would like to understand why this cannot be fixed at kernel level. I cannot encourage people to use Linux if it is not going to work in their laptops with their buggy BIOS's. Thanks.
Created attachment 16297 [details] Output of acpidump
Created attachment 16346 [details] Fixed compilation error in the BIOS ACPI
Created attachment 16347 [details] Compiled DSDT.aml with compilation error fixed I followed the instructions in the Gentoo forum about how to fix the ACPI in the BIOS: http://forums.gentoo.org/viewtopic.php?t=122145 So I decompiled DSDT.aml and tried to compile it again. It gave one error and two warnings. I fixed the error, but couldn't fix the warnings. I placed the compiled DSDT.aml in /boot/DSDT.aml with the following options in /boot/grub/menu.lst: title Ubuntu 8.04, kernel 2.6.24-17-generic root (hd0,0) kernel /boot/vmlinuz-2.6.24-17-generic root=UUID=6bc031bf-50e0-446d-b30 8-a682677d9fb4 ro quiet acpi_no_auto_ssdt initrd /boot/initrd.img-2.6.24-17-generic quiet The key is in the parameter acpi_no_auto_ssdt and the new fixed DSDT.aml. It seems to work fine now. I installed lmsensors and the temperature of my two CPU's is always between 65 and 80ºC. Still pretty hot, but at least it doesn't reach 97ºC as before, forcing it to shutdown. See the source code of DSDT.aml in my previous post: http://bugzilla.kernel.org/show_bug.cgi?id=8713#c18 I tried to compile the latest 2.6.25.4 kernel patched ACPI DSDT in initrd, but I did something wrong and end up with no sound and no wifi, so I went back to the 2.6.24-17 that comes with Ubuntu 8.04, but with the parameter acpi_no_auto_ssdt at start and the fixed DSDT.aml file placed ant /boot/. The result is that finally I'm not sure if it is working now just because of the acpi_no_auto_ssdt parameter or if the fixed DSDT.aml file is needed. I hope somebody can tell me. I know all the above is confusing. Sorry for that, but I couldn't find information anywhere and I'm sure this will be still helpful for the people trying to fix their lenovos to work with Linux. Should I post these 2 files somewhere else? I guess I should send this to Lenovo at least. Is the kernel going to fix this with this new DSDT.aml file? Should a Linux distribution fix it? Or should just Lenovo fix its BIOS?
I am using Freebsd 7.0 on lenovo 3000 V100. When I compile something. It always overheating. I used the fixed DSDT.aml in #20.It just worked fine. I can't compile the JDK now. Thanks.
Sorry There have a typos. I means I can compile the JDK now. Before using DSDT.aml,it will overheat after 5 minutes.
First, you don't need the boot parameter "acpi_no_auto_ssdt", just compile the kernel with customized DSDT. About the customized DSDT, DSDT.dsl 974: Name (_HID, "*pnp0c14") Error 4001 - ^ String must be entirely alphanumeric (*pnp0c14) Changing the name to "PNP0C14" is enough to fix the problem, right? It seems that the ACPI WMI driver plays a key role in the fan control. Carlos, By reading the code and wmi spec, I didn't find any piece of code related with fan/thermal control, it seems that the WMI action is transparent to the OS, right? Even the WMI driver doesn't know what its action stands for.
I'm fairly sure back when I reported this, I did the same DSDT 'fix' myself and it didn't change a darn thing. Not surprisingly as I - the original filer - am *still convinced there is no bug here*. That's why it was closed in the first place.
Okay, then re-close this bug. :p Daniel and Yao, please open another bug if you still have any questions.
Well, while this bug is dead, just to address Zhang's comment: Correct - WMI basically just lets vendors plug whatever they want into ACPI, and it's up to some userspace application to know how to deal with it in Windows. And I can also tell you that, interestingly enough, this laptops' WMI implementation is actually supported by acer-wmi (which doesn't offer fan control on that particular interface).
(In reply to comment #26) > And I can also tell you that, interestingly enough, this laptops' WMI > implementation is actually supported by acer-wmi (which doesn't offer fan > control on that particular interface). > do you mean that fixing the Name (_HID, "*pnp0c14") error won't affect the fan control on this laptop?
Correct - ACPICA can handle the * just fine, it's only IASL that complains.
(In reply to comment #24) > I'm fairly sure back when I reported this, I did the same DSDT 'fix' myself > and > it didn't change a darn thing. Not surprisingly as I - the original filer - > am > *still convinced there is no bug here*. That's why it was closed in the first > place. > When I tried to get the bug reopend I didn't belive that there is no bug, I had the same overheating problem and it got worse and worse. So I finally decided to open the laptop since it was useless anyways... What I found was surprising the heat sink ( I mean the part of it which is located next to the fan ) was completly coverd with grey felt - so no wonder that the fan had no effect at all. After removing it the laptop does not overheat at all. I can put a 100% cpu load on the system (according to top) via cpuburn for more than 1h and causing lots of IO with find and dd (after that time I stopped) not causing the system to overheat. The case is a bit tricky to open and you have to start with the peace of plastic between the keyboard and the screen. After that remove the keyboard. For removing the display you have to remove the grey caps (there are no screws ). Than remove all the screws on the bottom of the laptop and the hd as well as the cdrom. No the tricky part is to open all the plastic clips holding the top and bottom part together without braking them. They are quite resistive and a (jack) knife is a good tool for that. Be carefull not to rip of the wires which connect to the speakers and the touchpad (i didn't care about the fingerprint scanner), to unplug the touchpad cable you will have to pull on the plastic on either side of the wire. This procedure takes about 30 minutes and is absolutely worth it. I will try to post a picture that you see what it looks like and if you are too scared to try.
Created attachment 17383 [details] Picture of the felt coverd heat sink If you have any questions on how to open the case feel free to ask :)
Created attachment 17384 [details] Picture of the open laptop It is not hard to open the laptop, it was my first try aswell ...
valuable information. Thanks, Sebastian. :)