Date: Tue, 12 Feb 2013 08:01:35 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@FreeBSD.org, Brett Wynkoop <wynkoop@wynn.com> Subject: Re: BeagleBone locked up Message-ID: <1360681295.4545.165.camel@revolution.hippie.lan> In-Reply-To: <4AF15BB9-4174-4564-A770-BF9EB9D447F5@kientzle.com> References: <20130210231709.26f122dc@ivory.local> <B4346DD4-BA90-4A2C-A2B3-D5DBB6B68942@kientzle.com> <20130211190606.1c985baf@ivory.local> <1360629932.4545.150.camel@revolution.hippie.lan> <4AF15BB9-4174-4564-A770-BF9EB9D447F5@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1360681295.4545.165.camel>