Bug 14074

Summary: Oops on disk access after suspend/resume
Product: Platform Specific/Hardware Reporter: Gavin Kinsey (gavin.kinsey)
Component: i386Assignee: platform_i386
Severity: normal    
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.31-rc7 Tree: Mainline
Regression: Yes
Attachments: dmesg output before the suspend
Oops captured from a netconsole
Kernel config
lspci -vvv
Output of ver_linux script

Description Gavin Kinsey 2009-08-27 16:14:03 UTC
Created attachment 22882 [details]
dmesg output before the suspend

For a while now I have had crashes on newer kernels that I was unable to track the cause of.  I've finally managed to nail down a test case for it now though.  It seems that there is a problem with some disk accesses after a suspend/resume, it doesn't happen on the first access but some time later which is what made it hard for me to identify.

The following will always cause the error to show up though:
1) Boot and login as root
2) Suspend using pm-suspend
3) Resume with power button
4) Run "find / -xdev -type f | xargs -t -l1 cat > /dev/null"

At some point during that find command the kernel will Oops.

The last kernel that definitely worked was v2.6.27.  I've done a git bisect and I believe the problem commit to be e621bd18958ef5dbace3129ebe17a0a475e127d9 and indeed reverting that commit on a v2.6.28 codebase does fix my problem.

I've been unable to generate a working patch for v2.6.31, and even if I could I don't think just reverting the commit is the correct solution as the commit was a bug fix itself.

Relevant logs attached.
Comment 1 Gavin Kinsey 2009-08-27 16:15:00 UTC
Created attachment 22883 [details]
Oops captured from a netconsole
Comment 2 Gavin Kinsey 2009-08-27 16:15:28 UTC
Created attachment 22884 [details]
Kernel config
Comment 3 Gavin Kinsey 2009-08-27 16:16:01 UTC
Created attachment 22885 [details]
lspci -vvv
Comment 4 Gavin Kinsey 2009-08-27 16:16:32 UTC
Created attachment 22886 [details]
Output of ver_linux script
Comment 5 Gavin Kinsey 2009-09-10 02:12:22 UTC
I believe this is the same bug as #13149.

*** This bug has been marked as a duplicate of bug 13149 ***