FS#15267 - [pm-utils] pm-suspend doesn't resume correctly with kernel 2.6.30
Attached to Project:
Arch Linux
Opened by Denis Kobozev (bhobbit) - Friday, 26 June 2009, 01:03 GMT
Last edited by Thayer Williams (thayer) - Tuesday, 19 January 2010, 19:05 GMT
Opened by Denis Kobozev (bhobbit) - Friday, 26 June 2009, 01:03 GMT
Last edited by Thayer Williams (thayer) - Tuesday, 19 January 2010, 19:05 GMT
|
Details
Description:
pm-suspend doesn't resume correctly with kernel 2.6.30. Worked fine before upgrading from 2.6.29.4-1 to 2.6.30-5. The laptop (Thinkpad x61) suspends correctly, but the screen remains black after opening lid, the "moon" LED stays on and the laptop does not respond to keypresses. Alternatively, the laptop attempts to wake up ("moon" LED goes off, HDD LED blinks), fails and restarts. pm-hibernate seems to work fine. Additional info: * kernel26 2.6.30-5 * pm-utils 1.2.5-1 Steps to reproduce: # pm-suspend |
This task depends upon
Closed by Thayer Williams (thayer)
Tuesday, 19 January 2010, 19:05 GMT
Reason for closing: Deferred
Additional comments about closing: Will consider opening an ongoing ticket containing tips for troubleshooting future hiccups.
Tuesday, 19 January 2010, 19:05 GMT
Reason for closing: Deferred
Additional comments about closing: Will consider opening an ongoing ticket containing tips for troubleshooting future hiccups.
[#1]
FS#14479- [pm-utils] pm-suspend doesn't resume correctly with kernel 2.6.29.1-4On german forum we have several similar reports about that.
Further Infos:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-06/msg07178.html
And a possible patch (IMHO accepted on LKML):
http://marc.info/?l=linux-kernel&m=124499077702983&w=2
No, it doesn't respond to the power button when I press it briefly (if I hold it for more than 4 seconds, the laptop shuts down). It might've or might've not responded to the power button with kernel 2.6.29.4-1 - I didn't try. It woke up with 2.6.29.4-1 when either the lid was open or Fn key was pressed.
@Gerhard
Adding hpet=disable to kernel boot parameters produces no result.
Also acpi suspend, at resume, reboot my system.
Suspend/resume was fine on 2.6.29.
xf86-video-intel 2.7.1-1
Myself have a nvidia card.
hpet=disable option makes no difference.
lspci|grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
and I'm using the xf86-video-intel 2.7.1-1 driver. It's running arch 32bit.
Resume from suspend to RAM works fine on my other two laptops, both running arch 64bit. One laptop has an Nvidia card, the driver is the closed source one from the repo, while the other 64bit laptop has a 945GM/GMS, 943/940GML graphic card, the driver is the xf86-video-intel 2.7.1-1 driver.
kernel26 2.6.30.1 installed.
Toshiba Satellite A200
GF 7300 Go (nvidia 185.18.14 driver)
Dell Latitude d820
intel core2 duo t7200
Quadro nvs 120m (nvidia 185.18.14 driver)
Basically I wasn't convinced the problem was the kernel, so I tried downgrading a load of packages that were installed in the upgrade which broke my suspend/resume with the older versions from my /var/cache/pacman/pkg/. The packages were:
devicekit-power, klibc, klibc-extras, klibc-kbd, klibc-module, klibc-udev, mkinitcpio, module-init-tools, syslinux, udev (note NOT kernel26)
(There was supposed to be some method to this madness, but it was mainly date based, clearly some/most of these aren't responsible.)
I then had an unbootable system... which eventually I recovered by backtracking and reinstalling current versions of above packages (further personal woes due to macbook hardware omitted). On returning to a working system I was surprised to find my suspend/resume working perfectly, from console in 2.6.30 (KMS/UXA breaks graphical things for me in 2.6.30) and from full X/KMS/UXA glory in 2.6.31-rc3.
Potentially reinstalling the above packages (or just whichever one the culprit is if identified more systematically) might fix the problem for some of you, hopefully it isn't just my random luck. Sorry I couldn't be any clearer on the exact solution, please excuse all the waffle.
kernel26 2.6.30.2-1
Intel Core 2 Duo T8300
Intel GM965/GL960 (xf86-video-intel 2.7.99.902-1 driver)
@Giuseppe
The kernel upgrade to 2.6.30.2 did not solve the problem work for me so maybe you were upgrading also some other packages which turned your suspend into work?
@dingus
I tried reinstalling the following packages:
klibc klibc-extras klibc-kbd klibc-module-init-tools klibc-udev udev mkinitcpio module-init-tools
as you've suggested but it didn't help.
I hadn't any IgnorePkg active in pacman.conf, so I updated the kernel along with other packages, if any other package was updated at the time. But I think it's the kernel, suspend to RAM worked with 2.6.30, didn't work with 2.6.30.1 and works again with 2.6.30.2.
I've reinstalled kernel26-firmware (2.6.30-1), kernel-headers (2.6.30.1-1) and kernel26 (2.6.30.2-1) to make sure the latter is built properly basing on the latest dependencies (all those three packages was already up-to-date, so i've just reinstalled them now, not updated). Unfortunetly, the problem does still exist. Maybe kernel options have some influence and this is why it works for you but not for me? In my GRUB menu.lst the corresponding line looks as follows:
kernel /vmlinuz26 root=/dev/disk/by-uuid/731b33a2-c7e0-4ecf-9a2d-73f152c043e4 ro vga=792
I forgot to mention that I use Kernel Mode Setting (KMS). I've used the 'late' start till kernel26 version 2.6.30.1 and switched to the 'early' start with 2.6.30.2. From your grub line I see you're not using KMS. I doubt this is the culprit, but you can try with KMS enabled and see what happens.
I think it's a problem due to some combination of hardware and kernel compilation options. I've had no problems with suspend to RAM on my other two laptops, both running on 64-bit.
My T60's suspend to RAM doesn't work anymore with kernel 2.6.30.* either. Sometimes it comes back up and reboots instead of resuming, and sometimes it comes back up but the screen stays black and the power light doesnt come on, although the fan spins up. My graphics card is an ATI X1400 though, which doesnt have an implementation of KMS in the 2.6.30 series.
For now I worked around it by forcing suspends to disk instead of ram, since I don't have a lot of time to dig in and figure it out right now.
at the moment I can't try it sorry.
p.s. Sorry for my english
Could you please make a diff of lists of modules included in initcpio images with and without autodetect?
I guess you may include some module(s) from that diff in MODULES and then have autodetect hook enabled again.
The file probably has CR+LF line break, sorry for that.
none of the tip mentioned here worked (hpet-disable or removing mkinitcpio autodetect)
dell xps m1530 - kernel26 2.6.30.4-1
Anyone else still have this problem? If not then we can finally close this.
Anyway, I don't know what arch can do about suspend issues.. We probably need to see with upstream directly.
I solved with this: http://wiki.archlinux.org/index.php/Suspend_to_RAM
following the first part of the wiki,
I've installed hibernate-script and I follow the s2ram part of wiki.
Note: I've not tryed to add to mkinitcpio.conf the option "resume" as suggested by pm-utils wiki, I'm sorry but I had not time :(
if you want I could try that tomorrow, too. But now it seems to work :)
- Both autodetected and non-autodetected initrds load the same modules on startup
- The only difference is the order they happen to load the modules in. Autodetect happens to load "ahci" before "ata_piix", while non-autodetect happens to load these two in the opposite order. All other modules are loaded in the same order. Looking at dmesg output, the only effect of switching the load order of these modules is the order in which drives get detected and added to the scsci and ata systems, the functionality and parameters of the devices is the same regardless of order.
So, having found this info, my best guess at the problem would be that on resume from RAM, the kernel runs through its list of drives and sends some sort of wakeup call to these devices, and that on some thinkpads, the hardware is picky about the order it gets woken up in. There's no way I can know for sure though, I'm only guessing here.
HOOKS="base udev autodetect pata scsi sata uresume filesystems"
Tried removing autodetect and re-mkinicpio but made not difference.
Not sure if HOOKS should contain uresume or resume.
the question is if they fixed this in the new kernel version (2.6.31).
also, the same thing still works for me on the 2.6.31 kernel.
suspend to disk works fine though...
Pm-utils with uswsusp (s2disk/s2ram) seemed to work ok, but after one day fine suspending/resuming it hung again after resuming.
The kernel method did not work reliable at all. It hung after almost each resume.
Also there were no kernel.log entries of interest.
Now i switched back to 2.6.29.4. Is it an Arch issue or a general one?
I googled, but i haven't found any comparable problems.
My Hardware:
* lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge
00:02.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (ext gfx port 0)
00:06.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 2)
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode]
00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:12.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:13.1 USB Controller: ATI Technologies Inc SB700 USB OHCI1 Controller
00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 3a)
00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:14.5 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation G73 [GeForce 7600 GS] (rev a1)
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit Ethernet Adapter (rev b0)
03:06.0 Multimedia video controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
03:06.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] (rev 05)
03:06.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] (rev 05)
* CPU: AMD Athlon(tm) Dual Core Processor 4850e
IMO there will always be at least one hardware platform that does not suspend/resume properly with these tools. Some hardware just isn't implemented well (or openly), thus threads such as this could remain open indefinitely.
- suspend/resume always fail, even with a custom kernel. in this case, report the issue upstream, not in arch bugzilla
- suspend/resume works with custom kernel but not with arch kernel. (and maybe) can also be worked around with different mkinitcpio.conf (see neotuli comments)
Does resume work when suspend is initiated outside of Xorg (e.g., from the console)?
Could you attach the log file from /var/log/pm-suspend.log?
@Xavier: I'm not entirely convinced it's the fault of the kernel, or at least not directly. Nine times out of ten it's the graphics driver, and usually when it's proprietary. Is your Dell now working with the current kernel?
I may still close this thread and open a new, indefinite ticket with explicit instructions on troubleshooting. It seems a lot of folks don't know the pm-utils wiki exists until after opening a ticket. It won't resolve all cases, but it may help eliminate the noise.
And then I started using nouveau on 2.6.31, suspend/resume still worked fine. Now with 2.6.32, I have troubles sometimes, where resuming completely freezes, but I still don't know if this is a kernel or nouveau issue. Might be a kernel one but well...
Anyway the issue that I initially reported here, where suspend/resume did not work at all, is probably gone.
The thing is that it used to work properly, but somewhere around 2.6.29-2.6.30 it stopped. That is why i think it is related to this FS#..
:)
However it is not an important issue to me, and i dont mind this bug being closed.