Hi Keith, Scott,
> Like Keith says, you need to find out who owns the page lock. But it
> is likely that even knowing that won't point to the root cause, which
> is why fsck needs so much memory; either you're checking a _very_ large
> filesystem, or the filesystem is broken.
Turning up the console loglevel reveals that the RAID controller is
exhibiting broken behaviour - it stops responding to any requests, making
it hard for anything that wants to read/write to disk to work. So the
lock_page just sits there (I assume in the case where it has to do disk
I/O)... All beyond me, so the board designers are looking into it.
Thanks for the insight into what was going on in that stack trace, I learn
a little bit every dday.
Chris
|