Bug 237634

Created attachment 153341 [details]
lspci -vvv output

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.

You might also like to check http://people.freedesktop.org/~hughsient/quirk/ for
ideas.

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?

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

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?).

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.

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.

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?

(In reply to comment #9)
> Is there supposed to be a vbetool binary still?

Yes, there is already a bug about this: #244330

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.

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.

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/

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.

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