Latest working kernel version: 2.6.27 Earliest failing kernel version: 2.6.29 Distribution: openSUSE Factory (11.2) Hardware Environment: IBM ThinkPad T42 Software Environment: Problem Description: When I suspend my notebook to sleep (state S3), then the power consumption remains high and drains the battery in a couple of hours. When I boot with the older kernel version (2.6.27.13) then I have a normal power drainage during sleep. I have tested this with the acpi-sleep script from thinkwiki.org, which is used to test if an IBM laptop is suffering from the radeon bug. This is exactly the same system and I am just booting with either on of the kernels. So nothing in the hardware nor distribution is changed apart from the used kernel. Steps to reproduce: Execute the attached script and validate the values in the /var/log/battery.log file.
Created attachment 20466 [details] Logfile that shows power consumption (kernel 2.6.27-13)
Created attachment 20467 [details] Logfile that shows power consumption (kernel 2.6.29-rc6-git1)
Created attachment 20468 [details] dmesg output for kernel 2.6.27-13
Created attachment 20469 [details] dmesg output for kernel 2.6.29-rc6-git1
Created attachment 20470 [details] Script from thinkwiki.org which is used to test how much power is consumed
Reassigned to acpi, marked as a regression.
Raymond, can you also test 2.6.28, please?
Hi, Raymond Will you please attach the output of acpidump? From the description it seems that this is a regression. Will you please use git-bisect to identify the commit which causes the regression? Thanks.
Created attachment 20486 [details] ACPIDUMP file
Hi Rafael, Unfortunately openSUSE does not offer the 2.6.28 kernel, so I am currently trying to build it. As far as I can remember from the past, I ran a couple of weeks on this one without any complaints. So i assume that this issue was not in 2.6.28, however I will test and attach the results here. Hi Yakui, I have attached the acpidump of my system, but unfortunately I can not use the git-bisect command. I have just a small laptop and I do not have enough space for it. I am really sorry for this. Regards Raymond
please verify if the problem still exists with commit 1fb25cb8b83e85f5bf1a4adb3c9a254c4ce92405 reverted.
this seems like a duplicate of bug #3022, but I wonder why this is a regression.
Hi, I am still working on getting the kernel 2.6.28.7 compiled through the openSUSE build service. That is unfortunately the only place where I would be able to build kernels. I will check again among the openSUSE community to validate if others have the same issue. Also once I have the 2.6.28.7 kernel build, I will try to pull the kernel sources with git and then to revert the above indicated commit. Thanks Raymond
With regards to the duplicated of bug #3022, I am not sure about this. In the logfiles it can be seen that the radeon chip is reporting to go the D2 state. The same lines are reported when suspending on the working 2.6.27 kernel.
Hi Rui, >please verify if the problem still exists with commit >1fb25cb8b83e85f5bf1a4adb3c9a254c4ce92405 reverted. I finally managed to built the 2.6.28-rc8 kernel with this commit reverted. I have tested again according to the same method and the result is that the correct behavior is there. The logfile /var/log/battery.log shows the following : Sun Mar 15 12:51:19 CET 2009 before: 29860 mWh after: 29530 mWh diff: -330 mWh seconds: 2613 sec result: -454 mW Congratulations, your model seems NOT to be affected. This result is comparable with the kernel 2.6.27, so this commit causes the issue for the radeon chips. Regards Raymond
Caused by: commit 1fb25cb8b83e85f5bf1a4adb3c9a254c4ce92405 Author: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: Thu Feb 5 12:06:52 2009 +1100 radeonfb: Fix resume from D3Cold on some platforms First-Bad-Commit : 1fb25cb8b83e85f5bf1a4adb3c9a254c4ce92405 In fact, 2.6.29-rc8 contains patches that are supposed to fix the problems exposed by the above commit. It the problem still present in vanilla 2.6.29-rc8?
Hi Rafael, I have also tried 2.6.29-rc8 first, but this has exactly the same issue as rc6 and rc7. Only reverting the indicated commit, solved the problem. Maybe the patches in rc8 were more focused on resolving the issues with resuming and not on power drainage during sleep ??
Could be. CCing Ben.
The difference here seems to be that before that commmit, we would manually stick the chip into D2 state by whacking its config space, while after that commit we use pci_set_power_state(...,PCI_D2) Raymond, can you try editing radeon_set_suspend() in radeon_pm.c and basically replace the pci_set_power_state(rinfo->pdev, PCI_D2) call with what was there before, that is: for (;;) { pci_read_config_word( rinfo->pdev, rinfo->pm_reg+PCI_PM_CTRL, &pwr_cmd); if (pwr_cmd & 2) break; pci_write_config_word( rinfo->pdev, rinfo->pm_reg+PCI_PM_CTRL, (pwr_cmd & ~PCI_PM_CTRL_STATE_MASK) | 2); mdelay(500); } You'll also need to add back u16 pwr_cmd; at the top of the function.
re-assign to benjamin. :)
Hi Benjamin, I have applied the patch to the standard 2.6.29-rc8 kernel and this is working. During sleep the system is having the expected battery consumption. Please find the output of /var/log/battery.log Mon Mar 16 12:32:25 CET 2009 before: 29260 mWh after: 29050 mWh diff: -210 mWh seconds: 1521 sec result: -497 mW Congratulations, your model seems NOT to be affected. Regards Raymond
Now that's interesting. So something isn't working in pci_set_power_state(). Any chance you can sprinkle some printk's inside that function and the function it itself calls to see what it's doing ? Is it failing with an error ? Or the problem is purely due to the fact that we do a loop trying multiple times to set D2 state until it "sticks" while the core isn't ?
Hi Benjamin, Unfortunately I am not a developer, but I know how to change files and create patchfiles :-) If you tell me what printk's to put and where to find the pci_set_power_state function, then I can do this and I can deliver you the output. Another thing is that this might also have to do with the old bug around the Radeon chip and the difficulty to get it into sleep mode. I have such "faulty" radeon chip and therefore it might be that the standard pci_set_power_state does not work. As also mentioned in comment #12, it seems as if the old bug is back again. I know that I definitely require the Radeon Workaround for Thinkpad notebooks in order to have it "sleeping" correctly. But please let me know what to do and I will do it :-) Regards Raymond
Created attachment 20589 [details] debug pci power stuff This patch adds various printk's to the PCI set power state code, please try with that (and without the previous change that fixes the problem), and send me the output in dmesg
Hi Benjamin, Thanks for the patch. Will rebuild the kernel and send you the dmesg as soon as possible. Regards Raymond
Hi Benjamin, Please find the dmesg attached. Hope that this helps . Regards Raymond
Created attachment 20597 [details] Dmesg output with additional printk
Created attachment 20613 [details] Here's the patch that I sent privately that fixes it
Fixed by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=18a0d89e54ca0f6f33582f99ae39867b2c975559