Bug 237634 - Panic on S3 Resume
Panic on S3 Resume
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: hal-info (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On: 244330
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-24 06:22 EDT by Simon Goodall
Modified: 2013-03-05 22:50 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 21:33:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci -vvv output (7.99 KB, text/plain)
2007-04-24 06:22 EDT, Simon Goodall
no flags Details

  None (edit)
Description Simon Goodall 2007-04-24 06:22:44 EDT
Description of problem:
When resuming from suspend using the FC7 Live CD, it looks like the kernel
panics (flashing caps lock and scroll lock). All that is displayed is a yellow
"Linu" piece of text.
This machine can wake up sucessfully in FC6.

I have a Dell Inspiron 8500. See attached lspci output for system details.

Version-Release number of selected component (if applicable):
FC7 Test 3 Live CD.

How reproducible:
Always

Steps to Reproduce:Tried once so far.
1. Boot off live cd using option 1.
2. Single clicked on user to log in
3. Use gnome-power-manager to suspend.
4. Wake up machine.
  
Actual results:
Panic


Expected results:
Wake up into usable state.

Additional info:
Comment 1 Simon Goodall 2007-04-24 06:22:44 EDT
Created attachment 153341 [details]
lspci -vvv output
Comment 2 Dave Jones 2007-04-24 11:47:52 EDT
somehow I knew this was going to be an nvidia card even before I opened up the
lspci output.   We get that wrong on quite a few of their cards it seems.   As
we don't have programming specs, we don't know how to reinitialise the video, so
we resort to calling the vbios to do it for us.  Sometimes it works, others, not
so much..

Anyway, it's a pm-utils problem, but the 'fix' probably isn't so easy.
Comment 3 Richard Hughes 2007-05-24 08:06:34 EDT
You might also like to check http://people.freedesktop.org/~hughsient/quirk/ for
ideas.
Comment 4 Simon Goodall 2007-06-01 04:49:54 EDT
I still get a panic on FC7 final, however the screen does not come back up.
Enabling /sys/power/pm_trace leads to hash matches pointing to pci device 00:1d.0 

lspci shows;

00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 03)

Examining dmesg I see the following error;

Jun  1 09:00:39 echo kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA]
-> GSI 11 (level, low) -> IRQ 11
Jun  1 09:00:39 echo kernel: BUG: warning at
kernel/softirq.c:138/local_bh_enable() (Not tainted) 
Jun  1 09:00:39 echo kernel:  [<c042b0cf>] local_bh_enable+0x45/0x92
Jun  1 09:00:39 echo kernel:  [<c06002bd>] cond_resched_softirq+0x2c/0x42
Jun  1 09:00:39 echo kernel:  [<c059adf3>] release_sock+0x4f/0x9d
Jun  1 09:00:39 echo kernel:  [<c05c670d>] tcp_sendmsg+0x90b/0x9f9
Jun  1 09:00:39 echo kernel:  [<c05dec95>] inet_sendmsg+0x3b/0x45
Jun  1 09:00:39 echo kernel:  [<c0598731>] sock_aio_write+0xf6/0x102
Jun  1 09:00:39 echo kernel:  [<c04754ee>] do_sync_write+0xc7/0x10a
Jun  1 09:00:39 echo kernel:  [<c0436e71>] autoremove_wake_function+0x0/0x35
Jun  1 09:00:39 echo kernel:  [<c0475d47>] vfs_write+0xbc/0x154
Jun  1 09:00:39 echo kernel:  [<c0476342>] sys_write+0x41/0x67
Jun  1 09:00:39 echo kernel:  [<c0404f70>] syscall_call+0x7/0xb
Jun  1 09:00:39 echo kernel:  [<c0600000>] __sched_text_start+0x6e8/0x89e
Jun  1 09:00:39 echo kernel:  =======================

removing the *hci_hcd modules before suspending lets my machine resume without
panicing, although there are still other issues to resolve (e.g. no display)

I didn't have this problem in FC6 using the 2.6.20 and earlier kernels. I was
also playing with a vanilla 2.6.21 kernel build last week and I did not have
this problem then either (although I was stripping out drivers to speed up build
time). Is there a usb related patch pulled in for the fedora kernel?
Comment 5 Richard Hughes 2007-06-01 04:56:28 EDT
(In reply to comment #4)
> 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
> USB UHCI Controller #1 (rev 03)

This is quite a common controller. I would open a bug on bugzilla.kernel.org and
file the panic there.

> removing the *hci_hcd modules before suspending lets my machine resume without
> panicing, although there are still other issues to resolve (e.g. no display)

Do any of the quirks get your display back up after you've rmmod'd the driver?

> I didn't have this problem in FC6 using the 2.6.20 and earlier kernels. I was
> also playing with a vanilla 2.6.21 kernel build last week and I did not have
> this problem then either (although I was stripping out drivers to speed up build
> time). Is there a usb related patch pulled in for the fedora kernel?

Hmm, there are a lot of patches, but none I think would contribute to this
crash. If you can, could you try the latest linux-2.6 (linus git tree) and see
if there is still a problem there? Thanks.
Comment 6 Simon Goodall 2007-06-04 12:17:35 EDT
Ok, filed a bug report with the kernel bugzilla as I can reproduce the problem
with the latest tree.
I've not been able to get my display back up using the nv driver. The nvidia
driver does work however.
I think the nv driver requires posting, but this quirk (--quirk-vbe-post) has
not worked. /var/log/pm-suspend.log says vbetool not found.
I do not have a /usr/sbin/vbetool, although as far as I could tell it is
provided by the pm-utils package (although it is not listed as a file?).
Comment 7 Simon Goodall 2007-06-06 09:07:07 EDT
Interestingly, when my machine is plugged into it's port replicator, the display
resumes. When it's not the display does not resume. A quick test with a serial
console showed X taking up most of the CPU (~90%) in these situations.
Comment 8 Simon Goodall 2007-06-10 12:19:54 EDT
The patch  21-firewire-implement-suspend-resume-hooks.patch  from
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/
resolved my panic problem. This looks like it will be in the kernel from 2.6.22-rc4.
Comment 9 Simon Goodall 2007-07-22 04:46:46 EDT
The new kernel-2.6.22.1-27.fc7 has a working uhci_hcd module. However, the nv
driver still does not work as expected.
Is there supposed to be a vbetool binary still?
Comment 10 Till Maas 2007-08-31 09:46:29 EDT
(In reply to comment #9)
> Is there supposed to be a vbetool binary still?

Yes, there is already a bug about this: #244330
Comment 11 Till Maas 2007-09-19 18:12:49 EDT
Can you please test the new pm-utils with:
yum --enablerepo=updates-testing update pm-utils

It will install  vbetool (and radeontool), too. So --quirk-vbe-post is supported
again.
Comment 12 Simon Goodall 2007-09-29 17:12:44 EDT
Running pm-suspend with --quirk-vbe-post  now works.
I've not managed to get suspend initiated through my suspend button working
however. Probably needs the hal config files tweaking.
Comment 13 Till Maas 2007-09-30 05:28:45 EDT
To get your suspend buton working, you may need to use acpid, e.g. add a file to
/etc/acpi/events with the contents:

event=button/sleep
action=/usr/sbin/pm-suspend --quirk-vbe-post

To get the name of the event right, you need to look into /var/log/acpid, there
should be a new entry when you hit your suspend button, e.g.
[Sun Sep  2 12:38:59 2007] received event "button/sleep SLPB 00000080 00000004"

You may also want to submit a patch to hal-info, like it is described here:
http://people.freedesktop.org/~hughsient/quirk/
Comment 14 Bug Zapper 2008-04-03 20:14:36 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 15 Bug Zapper 2008-05-06 21:33:13 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.