Arch Linux

I apologize for the unfinished message (is there no option to Edit the report?). As I wrote:
When I try to shutdown the machine it also fails, it freezes on "Saving System Clock", but after that comes "Deactivating Swap" (/sbin/swapoff -a) so I belive the problem is there. I tried uswsusp development version with the same effect and after that I switched to direct kernel method which also failed. What can be done with swap, any suggestions? Thank you.

Additional info:
* kernel26 2.6.28

Steps to reproduce:
Try to hibernate the second time.

Suspend to ram using pm-utils works fine for me on my laptop with 2.6.28. (By the way, unless you are losing data or the kernel is raping you, this is not high severity stuff. Medium will suffice)

I can't save my work nor properly shutdown the machine so it has great potential to mess up my data (never gets to unmounting) by unplugging. I take it very seriously, should have been more careful, sorry.

Anyway, I found reports of hibernation corrupting swap, and rendering it unusable without a reformat. This is not the case here, my swap partition is fine on next boot. When shutdown procedure stops the *machine* is not frozen, it just waits for swap which doesn't respond, like it's "busy".

Since you can't reproduce it, more information about my system:

Partition table
/dev/sda1 * 1 5 40131 83 Linux
/dev/sda2 6 2340 18755887+ 83 Linux
/dev/sda3 2341 2468 1028160 82 Linux swap / Solaris
/dev/sda4 2469 9729 58323982+ 5 Extended
/dev/sda5 2469 4900 19535008+ 83 Linux
/dev/sda6 4901 8547 29294496 83 Linux
/dev/sda7 8548 9729 9494383+ 83 Linux
--------------
/dev/sda2 ext3 /
none tmpfs /dev/shm
/dev/sda1 ext3 /boot
/dev/sda5 ext3 /home
/dev/sda6 ext3 /mnt/storage
/dev/sda7 ext3 /mnt/backup

$ swapon -vs
Filename Type Size Used Priority
/dev/sda3 partition 1028152 0 -1

Hardware:
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
02:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02)
04:00.0 Network controller: Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01)
0f:06.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
0f:06.1 FireWire (IEEE 1394): Texas Instruments PCIxx12 OHCI Compliant IEEE 1394 Host Controller
0f:06.2 Mass storage controller: Texas Instruments 5-in-1 Multimedia Card Reader (SD/MMC/MS/MS PRO/xD)
0f:06.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller

I found a very similar report (although I do not run out of swap), I will try to re-enable swap as suggested there and then hibernate again. That report also states a possible bug in swapoff which gives no errors, that would explain why I had no logs/errors to show here.

http://bugzilla.kernel.org/show_bug.cgi?id=12239

I have absolutely no experience with uswsusp so I might not be of much help.

When you call pm-suspend the second time, are you doing so from a terminal? No output whatsoever is printed? Have you checked /var/log/pm-suspend.log for details? Please call suspend twice (as you describe above) and then attach this log file.

> After the first wakeup, calling pm-suspend or pm-hibernate results in absolutely nothing, no action, no log, no error

This is what I wrote, meaning, yes I call it from the terminal. I also switched to direct kernel method with the same results, swap is somehow rendered unusable by both hibernation methods.

However I had luck with the above bug report. I finished by creating a pm-utils hook which disables and then enables swap on thaw/resume. Which "solves" it, what would happen if I actually had any data stored in swap?

> what would happen if I actually had any data stored in swap?

Frankly I have no idea. For the record however, swap is not necessary (nor used) when suspending (aka standby). Swap is only used when writing to the disk (aka full hibernation).

Out of curiosity, is there a particular reason you have chosen to use uswswap rather than the default pm-utils methods? pm-utils should be more than adequate for most workstations/notebooks and I can't help but wonder if you are complicating things by adding yet another layer.

I hope that contents of swap would be reloaded to ram.

> Out of curiosity, is there a particular reason you have chosen to use uswswap
> rather than the default pm-utils methods?

pm-utils supports: kernel, uswsusp and tuxonice. The first two show the same behaviour (as I wrote twice earlier) while I have no intention on trying tuxonice since it requires kernel modification.

Why I choosed uswsusp in general, before pm-utils became default pm framework it offered you to use quirks. But also uswsusp supports encrypting images and in the future hibernating to swap files (which would *now* solve all my problems) while being completly user space.

After going about it the whole day(and night) I'm almost certain this is caused by enabling link power management for intel SATA controllers (/sys/class/scsi_host/*/link_power_management_policy).

I also managed to get an error from s2ram: "s2ram_do Resource temporarily unavailable" and doing a web search among first results were topics from Arch BBS (surprise, surprise) where users reported that they had to downgrade to kernel26 2.6.27.4 (from 2.6.27.9) and laptop-mode-tools 1.42 (from 1.45). Reading the changelog for laptop-mode-tools I saw that they introduced support for the same "Power management for Intel SATA controllers" in 1.43.

So I'm now almost certain (2.6.27 worked here, with power management enabled) this causes it. If this is true, we can also solve the problem for those users, the thread is here: http://bbs.archlinux.org/viewtopic.php?pid=463620#p463620

It still seems odd however if the problem is due to a module setting, and yet it's not generating any logs as per standard pm-utils logging. You made it sound as if nothing at all happens, nothing initiates, nothing fails, and nothing is logged. I would expect *something* to be reported--especially since you have also attempted to use a vanilla pm-utils setup.

I posted to that topic, and am waiting a reply from the user that reported laptop-mode-tools needs downgrading. This report could be closed as far as I'm concerned, I won't "Request closure", maybe you would like to wait until 2.6.28 hits [core] to see if someone else will run into problems.

It is odd, executing pm-suspend or pm-hibernate *immediately* returns to the terminal without *any* output, or any logging to /var/log/pm-suspend.log (with both suspend methods). Calling "s2ram --force" directly produced that one error line (why wasn't the same logged trough pm-suspend... it seems pm-suspend didn't even start to suspend).

In the meantime I was able to find only one error report on ALPM and suspend http://markmail.org/message/263fnn5uq5bhinfs which claims it fixed in Linux 2.6.26.

Hello,

I had a maybe related problem :
with ALPM on in laptop-mode-tools and kernel 2.6.28.1 from testing, my laptop was unable to reboot.
When switiching off ALPM (default) everything works fine.