Arch Linux

Maybe need to request reopen this task[#1] and close this.

[#1]  FS#14479  - [pm-utils] pm-suspend doesn't resume correctly with kernel 2.6.29.1-4

My own laptop only responds to the power button when going into suspend. Keyboard or lid doesn't respond. Isn't this the same on your laptop?

Please try with kernel bootparameter: hpet=disable
On 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

@Jan
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.

confirmed on my dell latitude d820 with nvidia driver.
Also acpi suspend, at resume, reboot my system.

Same bug for me for a desktop computer. When I push the power button, the computer restarts (the leds light and the fans spin) but nothing happens (no screen, keyboard isn't responding). I tried to ssh from a laptop but the host was unreachable. I'm forced to reset the computer. And nothing is printed in the log messages about this (not in everything.log and the supposed pm-resume.log does not exist).

Same for me on my macbook, the laptop appears to suspend fine (led starts to pulse) but when resuming the power comes back on but the screen stays blank and there is no response from the system.
Suspend/resume was fine on 2.6.29.

I have the same problem on a lenovo s10e netbook, but this appeared with the recent upgrade to kernel26 2.6.30.1, suspend to ram worked fine with kernel26 2.6.30-5. I tried the hpet=disable kernel boot parameter, but it didn't work.

with the new kernel the problem isn't solved on my laptop.

I suspect this is related to video. For those of you commenting, please specify the graphics card and driver you're using.

Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)

xf86-video-intel 2.7.1-1

For my desktop computer, it's xf86-video-ati. What make you think it's related to video?

On my side this is solved with 2.6.30.1 (I don't need the hpet=disable anymore, the mentioned patch therefore is applied in this patch level).
Myself have a nvidia card.

I also have this problem on a ThinkPad T61 with the latest kernel from core installed and an NVidia chipset (driver nvidia from extra). The computer reboots instead of resuming after being suspended (pm-suspend).
hpet=disable option makes no difference.

My Lenovo netbook has the following graphic card
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.

I have the same problem.
kernel26 2.6.30.1 installed.
Toshiba Satellite A200
GF 7300 Go (nvidia 185.18.14 driver)

kernel26 2.6.30.1 installed.
Dell Latitude d820
intel core2 duo t7200
Quadro nvs 120m (nvidia 185.18.14 driver)

Upgrading to kernel26 2.6.30.1-1 did not fix the problem.

I was suffering from this bug but have now managed to recover a fully working system (on 2.6.30.1 and 2.6.31-rc3), the only problem is I'm not entirely sure how. I shall, however, try to describe as best as possible what I did in case it might be useful. There is a fairly long tale of woe associated of which I shall try to spare you most of the details.

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.

I am experiencing the same issue with HP 510 (Pentium M/ Intel i915GM). Strangely enough, resuming works ok with my custom build kernel, I will try to isolate the relevant config option.

The suspend problem is solved for my Lenovo s10e after the latest kernel upgrade to version 2.6.30.2.

Same problem, my configuration:
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.

@Mikołaj
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.

@Giuseppe
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

@Mikołaj
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.

Hmmm...

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.

i had this problem and solved it by removing the "autodetect" hook in /etc/mkinitcpio.conf. hope this helps!

@mjheagle8: could you report this as a bug in mkinitcpio then? (and please don't forget to mention your configuration)

what about inserting "resume" option in Hooks, as pm-utils arch-wiki suggests?
at the moment I can't try it sorry.

p.s. Sorry for my english

I've checked both mjheagle8's and Marco Tangaro's solutions but only the first one (removing 'autodetect' from HOOKS) actually works for me. Thanks.

@romashka: would that be a bug in mkinitcpio? or just something that some users have to change? i'd assume its there for a reason, but i'm no expert.

hm, I was thinking more of it and I think the reason why removing autodetect worked for you is that some module which does not get autoloaded was included in initcpio image.
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.

sure, when i get around to using my laptop again (i'm on my desk for a bit now).

Removing autodetect from hooks works for me, too. Also explains why resuming worked in my custom kernel built without initramfs support.

@JM: see my comment above, a diff of module lists would be helpful.

Here's a diff of modules included in initcpio with and without autodetect.
The file probably has CR+LF line break, sorry for that.

hm, I don't see anything suspicious in that list. :-/

pm-suspend (or s2ram) is broken here too, even when suspending from console
none of the tip mentioned here worked (hpet-disable or removing mkinitcpio autodetect)

dell xps m1530 - kernel26 2.6.30.4-1

Any additional info you might need, Roman?

@JM: I don't know. I don't even use suspend on my laptop (yet).

I am happy to report that after a system update the problem is gone for me.

Great!
Anyone else still have this problem? If not then we can finally close this.

JM : what did you update? the kernel? you did not have 2.6.30.4-1 yet?

Anyway, I don't know what arch can do about suspend issues.. We probably need to see with upstream directly.

@Xavier, yes, 2.6.30.4 and xorg-server were among the packages updated, I had problems with my wlan network before.

As of 2.6.30.4-1, the problem still persists. Will try mjheagle8's and Marco Tangaro's solutions and post the results.

The last kernel does not solve my problem, but...
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 :)

someone could try to modify only suspend.conf without any change to mkinitcipio.conf?

This issue is still present in kernel-2.6.31 from testing. I'm actively looking into it now though.

Removing autodetect from my mkinitcpio.conf fixed it. Probably some module gets autodetected and loaded that causes trouble. I'll look into it...

After some investigation, I have some information, but no real solutions:
- 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.

try to insert u resume in hooks line into mkinitcpio.conf
HOOKS="base udev autodetect pata scsi sata uresume filesystems"

Same problem here -- used to be able to suspend to RAM and resume fine.
Tried removing autodetect and re-mkinicpio but made not difference.
Not sure if HOOKS should contain uresume or resume.

this is a regression bug since 2.6.29 worked just fine.
the question is if they fixed this in the new kernel version (2.6.31).

@stephen wilkinson: resume for me. just try one at a time and see what works. :)

also, the same thing still works for me on the 2.6.31 kernel.

I'm using 2.6.31 on a msi u100 and i have no problems suspending, resuming, etc.

This is also present on a ASUS F5R with ati graphics, and resume in hooks array.
suspend to disk works fine though...

I don't know what's going on. I tried now almost everything except recompiling the kernel and tuxonice.
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.

BTW: setting acpi=off as kernel boot parameter works. But then i have only one cpu core.
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

I had the same problem on my Asus Eee PC 1000H (VGA: Intel Corporation Mobile 945GME Express) as described above. I have fixed it with removing "autodetect" and adding "resume" in the HOOKS. I believe that it is not a kernel bug.

Jiri, that is impossible. Neither one has anything to do with suspending - this is done entirely by your BIOS, the initramfs is not involved in any way.

Does this remain an issue for users with kernel26-2.6.31.6-1? If not I'm going to close this ticket.

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.

It is not solved on Asus F5R - 32bit - xf86-video-ati, with kernel26-2.6.31.6-1...

I wonder if we should make a distinction between two issues :
- 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)

@toffyrn: Have a look at this Ubuntu article: http://wiki.ubuntu.com/UnderstandingSuspend

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.

Oops yeah I forgot to mention that. I suppose I was using nvidia with 2.6.30 and then I switched to 2.6.31 and it worked again.
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.

Even when initiated from outside Xorg may screen stays black. (So probably graphics related?)

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.