Bug 14320 - Various BUGs on resume
Various BUGs on resume
Status: RESOLVED INSUFFICIENT_DATA
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel)
All Linux
: P1 normal
Assigned To: drivers_video-dri-intel@kernel-bugs.osdl.org
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2009-10-04 16:32 UTC by Alan Jenkins
Modified: 2009-12-03 17:13 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.32-rc1-git
Tree: Mainline
Regression: No


Attachments
Current kconfig (62.39 KB, text/plain)
2009-10-04 16:33 UTC, Alan Jenkins
Details
Dmesg showing "bad swap file entry" on current kernel (49.86 KB, text/plain)
2009-10-04 16:35 UTC, Alan Jenkins
Details
Another dmesg showing "bad swap file entry" on current kernel (56.93 KB, text/plain)
2009-10-04 16:36 UTC, Alan Jenkins
Details
Dmesg showing BUG in fget_light() on slightly earlier kernel (52.80 KB, text/plain)
2009-10-04 16:38 UTC, Alan Jenkins
Details
/var/log/messages showing freezer/scheduler debug spew after suspend to ram (741.24 KB, text/plain)
2009-10-04 16:45 UTC, Alan Jenkins
Details
Dmesg showing hung tasks after suspend to ram (122.00 KB, application/octet-stream)
2009-10-04 16:49 UTC, Alan Jenkins
Details

Description Alan Jenkins 2009-10-04 16:32:29 UTC
References: http://lkml.org/lkml/2009/10/4/64


I'm seeing a variety of BUGs on my EeePC 701 after hibernation.  Sometimes they cause a hang during resume; sometimes they happen just after resume.  It doesn't happen all the time either -  I've just hibernated three times in a row with no problems.  It's most perplexing.
 
One resume hang showed a series of SCSI backtraces and errors.  Unfortunately I wasn't able to capture it at the time.  They were most probably related to the root device, an SSD controlled by ata_piix.

I have full dmesgs for two different sets of backtraces following resume: "bad swap file entry" backtraces, and BUGs in fget_light().  The fget_light() bug was on a slightly older kernel (still a child of 32-rc1).  I will attach them forthwith.
Comment 1 Alan Jenkins 2009-10-04 16:33:22 UTC
Created attachment 23258 [details]
Current kconfig
Comment 2 Alan Jenkins 2009-10-04 16:35:46 UTC
Created attachment 23259 [details]
Dmesg showing "bad swap file entry" on current kernel
Comment 3 Alan Jenkins 2009-10-04 16:36:55 UTC
Created attachment 23260 [details]
Another dmesg showing "bad swap file entry" on current kernel
Comment 4 Alan Jenkins 2009-10-04 16:38:09 UTC
Created attachment 23261 [details]
Dmesg showing BUG in fget_light() on slightly earlier kernel
Comment 5 Alan Jenkins 2009-10-04 16:42:20 UTC
And then suspend-to-ram failed with a long freezer/scheduler debug spew, followed by a set of hung task warnings.  I used suspend-to-ram a couple of times in the past few days before finding this problem.
Comment 6 Alan Jenkins 2009-10-04 16:45:14 UTC
Created attachment 23262 [details]
/var/log/messages showing freezer/scheduler debug spew after suspend to ram

Ah, I should also have said that the suspend actually failed, unlike the hibernation problems
Comment 7 Alan Jenkins 2009-10-04 16:49:17 UTC
Created attachment 23263 [details]
Dmesg showing hung tasks after suspend to ram

This is the same event as the /var/log/messages attachment.  Dmesg shows the "hung task" message which /var/log/messages misses.

(/var/log/messages is otherwise more complete, since the kernel log buffer has overflowed).
Comment 8 Alan Jenkins 2009-10-04 16:55:53 UTC
And here's ps showing the hung tasks:

$ ps ax | grep D
  PID TTY      STAT   TIME COMMAND
 3521 ?        D      0:00 /usr/lib/ConsoleKit/run-session.d/udev-acl.ck session_active_changed
 3691 ?        D      0:00 setfacl -m u:1000:rw /dev/audio -m u:1000:rw /dev/dsp -m u:1000:rw /dev/mixer -m u:1000:rw /dev/snd/controlC0 -m u:1000:rw /dev/snd/hwC0D0 -m u:1000:rw /dev/snd/pcmC0D0c -m u:1000:rw /dev/snd/pcmC0D0p -m u:1000:rw /dev/snd/timer -m u:1000:rw /dev/video0
 3874 ?        D      0:00 /usr/lib/ConsoleKit/run-session.d/udev-acl.ck session_active_changed
 4050 ?        D      0:00 setfacl -m u:1000:rw /dev/audio -m u:1000:rw /dev/dsp -m u:1000:rw /dev/mixer -m u:1000:rw /dev/snd/controlC0 -m u:1000:rw /dev/snd/hwC0D0 -m u:1000:rw /dev/snd/pcmC0D0c -m u:1000:rw /dev/snd/pcmC0D0p -m u:1000:rw /dev/snd/timer -m u:1000:rw /dev/video0
Comment 9 Rafael J. Wysocki 2009-10-04 20:30:35 UTC
Is this reproducible without KMS?
Comment 10 Rafael J. Wysocki 2009-10-06 00:06:02 UTC
The issue doesn't appear to be reproducible without KMS.
Comment 11 Alan Jenkins 2009-10-06 09:03:45 UTC
> 2. Did it work with 2.6.31 (and with KMS)? 

I thought so, but my recollection is hazy.  I didn't test it for very
long if I did.  I've tried it now and 2.6.31 behaves pretty similarly. 
Sorry for ringing the regression bell.  (Corrected in bugzilla).


Firstly the _hibernation_ process hung (after a couple of suspend-to-ram
cycles).

No text on the console (despite using s2disk).  It echoed keypresses and
responds to SysRq keys.  No messages from lockdep or the hung task
detector (after waiting 5 minutes).  SysRq-P said we're in the idle
loop; SysRq-T said both events/0 and hald-addon-input were runnable.


Then suspend-to-ram hung (following a hibernation cycle).  This time it
showed the contents of vt1, but didn't appear to respond to anything
short of SysRq+B.
Comment 12 Jesse Barnes 2009-12-02 19:12:42 UTC
Can you bisect it?  Sounds like we may be corrupting memory...
Comment 13 Alan Jenkins 2009-12-03 12:16:17 UTC
I don't have a "last known good version" with KMS enabled.

It seems to be working fine now (2.6.32-rc8).  I use hibernation frequently and I've left KMS enabled, so I'll notice if it breaks again :).
Comment 14 Jesse Barnes 2009-12-03 17:13:26 UTC
Ok, thanks for the update.

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