Re: swsuspend not working

From: Éric Brunet
Date: Mon Jul 19 2004 - 14:20:12 EST

On Thu, Jul 15, 2004 at 03:23:48PM +0200, Éric Brunet wrote:
> Next I tried to suspend with the standard Fedora kernel
> (2.6.6-1.435.2.3). I booted normally, did a telinit 1, umounted
> everything except /proc and /, removed all modules except jbd and ext3
> and did echo 4 > /proc/acpi/sleep and nothing happened. Half a second
> later, sh was waiting for more input. The screen didn't blink, no line
> was output, nothing in the logs.

Ok, it is not surprising that the fedora kernel does not suspend to disk;
suspend to disk is not compiled in. What a weird decision from them.

Anyway, I recompiled a vanilla 2.6.8-rc1 with a usable configuration (usb
as modules, network, agpgart, drm, etc.) and could suspend and resume
from X11 after a standard boot sequence.

However, usb devices are in big troubles. I had at the time a wireless
usb mouse and an usb memory key plugged in. Mouse goes through the uhci
host controller and key through ehci. In short, they don't work after
resume. The weird thing is that /proc/bus/usb/devices is different after
resume: the identification strings are missing:

diff -rU 1 usb-before/devices usb-after/devices
--- usb-before/devices 2004-07-19 19:15:09.000000000 +0200
+++ usb-after/devices 2004-07-19 19:15:09.000000000 +0200
@@ -15,5 +15,2 @@
P: Vendor=0d7d ProdID=1320 Rev= 0.50
-S: Manufacturer=ASUS
-S: Product=Ai Flash-4
-S: SerialNumber=07420B100083
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=200mA
@@ -48,4 +45,2 @@
P: Vendor=1733 ProdID=0101 Rev= 0.01
-S: Manufacturer=Cellink Co., LTD.
-S: Product=Wireless RF Mouse
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=100mA

If I rmmod ehci_hcd and modprobe it back, I can have the memory key
working again (except that if it was mounted before, troubles ahead. I
had a kernel oops that way.) If I rmmod uhci_hcd and modprobe it back,
the mouse becomes alive again.

If, instead of unloading/reloading the modules, I unplug and replug the
radio emiter of the mouse, I get it back working. If I unplug the memory
key, the device REMAINS as managed by the ehci controller. If I plug it
back again, the memory key appears A SECOND TIME in the list of usb
device, but as an uhci device, this time.

I guess I could rmmod the usb modules before suspending and modprobe back
them after resuming, but that means I need to remember that if a memory
key, a camera or a zip drive is plugged in and mounted, I will probably
crash the kernel. Hmm.

Another device is not working after resume: it is an old realtek 8029
100 Mb LAN pci card. If I try to ping something on the LAN, I get a
« Destination Host Unreachable » and nothing more. The interrupt count of
the card is increasing, however. Unloading and reloading ne2k_pci fixes

Note that when I suspend, I get in the log
20:13:46: ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11
20:13:47: ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 5 (level, low) -> IRQ 5
20:13:51: eth0: link down
20:13:51: ACPI: PCI interrupt 0000:01:08.0[A] -> GSI 10 (level, low) -> IRQ 10
20:13:51: Fixing swap signatures... ok
20:13:51: Restarting tasks... done

and at resume time:
20:15:52: eth1: mismatched read page pointers 4c vs 68.

eth1 is the misbehaving LAN card, and its interrupt is 10.

When I unload/reload the ne2k_pci module, I get at reload time:
20:21:11: ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
20:21:11: ACPI: PCI interrupt 0000:01:08.0[A] -> GSI 10 (level, low) -> IRQ 10
20:21:11: eth1: RealTek RTL-8029 found at 0xc800, IRQ 10, 00:40:05:E2:2A:CF.

Notice the ACPI: PCI interrupt line. I have something similar when I
reload the ehci module
20:20:31: ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 11 (level, low) -> IRQ 11

I am not sure what all of this means. I could try to fiddle the kernel
configuration, but is it worth it ? For instance, would you recommend
using APIC or try different pci=... command line options to change the
way interrupts are initialized ?

Data on my computer on <>.

Oh, by the way, the merging of pmdisk and swsuspend is great news !


Éric Brunet
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at