Mailinglist Archive: opensuse-bugs (8080 mails)

< Previous Next >
[Bug 211511] suspend to RAM hangs on resume on Dell, regression between and -0.25
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Sun, 4 Feb 2007 14:03:41 -0700 (MST)
  • Message-id: <20070204210341.42620FB9@xxxxxxxxxxxxxxxxxxxxxx>

------- Comment #25 from jimc@xxxxxxxxxxxxx 2007-02-04 14:03 MST -------
Per instructions I recompiled the 2.6.20-rc6 kernel with PM_DEBUG and PM_TRACE
(in power management config section), booted with the sabotaged initrd and no
modules loaded, and "echo 1 > /sys/power/pm_trace", then "echo mem >
/sys/power/state". As before, it suspended, then on resume it hung solid. But
I power cycled it and rebooted with kernel 2.6.20-rc6 and a functioning initrd.
The discs were said to have not been checked for 130 years :-) but in the boot
messages (/var/log/boot.msg) a clue was revealed:
<4> Magic number: 0:682:215
<4> hash matches /home/kernel/linux-2.6.19/drivers/base/power/resume.c:28
<4> hash matches device 0000:03:01.0
The device is the CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3) (PCI ID
1180:0476). No card was in the socket and the driver had never been loaded
(would have been yenta_socket.ko). The same chip has a Firewire controller and
a flash memory reader; no devices or media were plugged in. This is neither
the first nor last device group (chip) on the PCI bus, ordering by bus address
as displayed by lspci. I've attached the output of lspci.
The code is resume_device(struct device *dev). None of the dev_dbg or
dev_err messages were visible (the display's lamp was not yet turned on).
Comments for dpm_power_up indicate that some devices must be powered off/on
with interrupts disabled. Could this be one of them? How could I make that

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

< Previous Next >