Bug 14074
| Summary: | Oops on disk access after suspend/resume | ||
|---|---|---|---|
| Product: | Platform Specific/Hardware | Reporter: | Gavin Kinsey (gavin.kinsey) |
| Component: | i386 | Assignee: | platform_i386 |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.31-rc7 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
dmesg output before the suspend
Oops captured from a netconsole Kernel config lspci -vvv Output of ver_linux script |
||
Created attachment 22883 [details]
Oops captured from a netconsole
Created attachment 22884 [details]
Kernel config
Created attachment 22885 [details]
lspci -vvv
Created attachment 22886 [details]
Output of ver_linux script
|
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.