[lkml]   [2011]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Oops while going into hibernate

On Jan 12, 2011, at 1:49 PM, Sebastian Ott wrote:

> I did about 5 re-tests with different loads, the result was always:
> [ 249.238697] EXT4-fs (dasda1): inode #1106 has NULL jinode
> # debugfs /dev/dasda1
> debugfs 1.41.10 (10-Feb-2009)
> debugfs: ncheck 1106
> Inode Pathname
> 1106 /usr/bin/killall
> debugfs: q

That looks really bogus. /usr/bin/killall is a system binary, and there's no good reason that hibernation should be trying to write pages to that binary.

You said originally that the oops was happening "while going into hibernation right after resuming with...". So that means you did a successful suspend/resume, and then the second suspend caused the oops? It looks like somehow the pages were left marked as dirty, so the writeback daemons attempted writing back a page to an inode which was never opened read/write (and in fact as a text page for /usr/bin/killall, was mapped read/only). Given that ext4 initializes jinode only when the file is opened read/write, the fact that it is null, and the fact that it makes no sense that a program would be modifying /usr/bin/killall as part of a suspend/resume, it looks very much like we just unmasked a software suspend bug....

-- Ted

 \ /
  Last update: 2011-01-13 01:47    [W:0.098 / U:0.700 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site