public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Éric Brunet" <Eric.Brunet@lps.ens.fr>
To: Pavel Machek <pavel@ucw.cz>
Cc: Linux Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: swsuspend not working
Date: Mon, 19 Jul 2004 21:19:06 +0200	[thread overview]
Message-ID: <20040719191906.GA7053@lps.ens.fr> (raw)
In-Reply-To: <20040715132348.GA9939@lps.ens.fr>

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
that.

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: http://www.scyld.com/network/ne2k-pci.html
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 <http://tudia.nerim.net/bug-reports/>.

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

Regards,

	Éric Brunet

  parent reply	other threads:[~2004-07-19 19:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040715121042.GB9873@lps.ens.fr.suse.lists.linux.kernel>
2004-07-15 12:10 ` swsuspend not working Éric Brunet
2004-07-15 12:18   ` Pavel Machek
2004-07-15 13:23     ` Éric Brunet
2004-07-15 13:21       ` Nigel Cunningham
2004-07-19 19:19       ` Éric Brunet [this message]
2004-07-20 13:17         ` Pavel Machek
2004-07-20 15:50           ` Romano Giannetti
2004-07-31 18:20           ` Éric Brunet
2004-08-06 19:06             ` Pavel Machek
2004-08-06 23:54               ` Éric Brunet
2004-08-07  7:13                 ` Paul Gortmaker
     [not found]                   ` <20040807140845.GA8353@lps.ens.fr>
2004-08-21 12:14                     ` PATCH swsuspend for ne2k-pci cards Éric Brunet
2004-08-23 19:51                       ` Pavel Machek
2004-09-01 14:56                       ` PATCH (RESENT) " Éric Brunet
2004-07-15 12:47   ` swsuspend not working Stefan Seyfried

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040719191906.GA7053@lps.ens.fr \
    --to=eric.brunet@lps.ens.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox