BeagleBone locked up

[Ian Lepore]

On Mon, 2013-02-11 at 22:38 -0800, Tim Kientzle wrote:
> On Feb 11, 2013, at 4:45 PM, Ian Lepore wrote:
> 
> > On Mon, 2013-02-11 at 19:06 -0500, Brett Wynkoop wrote:
> >> Greeting-
> >> 
> >> While building a kernel the Bone stopped responding on the net and this
> >> is what I found on the console:
> >> 
> >> ti_mmchs0: Error: current cmd NULL, already done?
> >> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 5534, size: 8192
> > [...]
> >> ti_mmchs0: Error: current cmd NULL, already done?
> >> ifaddr cache = 0xc1fbd700  is deleted
> >> ti_mmchs0: Error: current cmd NULL, already done?
> >> ti_mmchs0: Error: current cmd NULL, already done?
> >> 
> >> The interesting thing is I have seen this same swap_pager error message
> >> on my 32 bit x86 FreeBSD 9 box when it drops it's IDE disks and goes
> >> off the net as well.
> >> 
> >> The last I saw of the kernel recompile it was at linking just before it
> >> locked up.
> >> 
> >> Ideas?
> > 
> > That's the second report recently of indefinite wait buffer.  What it
> > really means is that it has been waiting more than 20 seconds to pull a
> > page (or block of pages) in from swap.  That plus the cmd NULL errors
> > tend to point in the direction of the mmchs driver.
> 
> This is something that's degraded fairly recently.
> I only started seeing these in the last week or so.
> 
> And the BeagleBone MMCHS driver has not been
> touched in a very long time.

Hrm, good point.  What has been touched recently that might be related
to this?  This first thing that comes to mind is the recent change for
allocating kmem map space proportional to the available ram.  I wonder
if that has led to some unexpected under- or over-allocation of buffer
resources, which, when combined with slow IO, leads to unusually long
waits for swapping?  (Purely guessing here, but I have found in the past
that playing with tuning NBUF in kernel config can lead to some odd
lockups and panics.)

-- Ian