what's going on in this trace?

[Chris Pascoe]

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