Date: Thu, 7 Jan 2016 22:26:40 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Mark Millard <markmi@dsl-only.net> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: FYI: various 11.0-CURRENT -r293227 (and older) hangs on arm (rpi2): a description of sorts Message-ID: <568ED810.8010309@selasky.org> In-Reply-To: <8B728C93-9C90-4821-A607-5D157F028812@dsl-only.net> References: <E0379BE9-308A-4219-A8AE-A5FFE828BA93@dsl-only.net> <1452183170.1215.4.camel@freebsd.org> <FB0D5486-AD27-44A7-86CA-68989AE08EC7@dsl-only.net> <1452196099.1215.12.camel@freebsd.org> <568EC4D8.7010106@selasky.org> <8B728C93-9C90-4821-A607-5D157F028812@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/07/16 21:20, Mark Millard wrote: > > On 2016-Jan-7, at 12:04 PM, Hans Petter Selasky <hps at selasky.org> wrote: >> >> On 01/07/16 20:48, Ian Lepore wrote: >>> If the filesystems and swap space are on a usb drive, then maybe it's >>> the usb subsystem that's hanging. The wait states you showed for those >>> processes are consistant with what I've seen when all buffers get >>> backed up in a queue on one non-responsive or slow device. It may be >>> that there's a way to get the system deadlocked when it's low on >>> buffers and there is memory pressure causing the swap to be used (I >>> generally run arms systems without any swap configured). >>> >>> Running gstat in another window while this is going on may give you >>> some insight into the situation. Beyond that I don't know what to look >>> at, especially since you generally can't launch any new tools once the >>> system gets into this kind of state. >>> >>> -- Ian >> >> Hi, >> >> All USB transfers towards disk devices have timeouts, so if something is hanging at USB level, you'll get a printout eventually. > > What sort of timescale after deadlock/live-lock is observed to apparently have started does one have to wait in order to conclude that the timeouts would have happened and so they do not apply to the deadlock/live-lock? > >> The USB kernel processes needed for doing I/O transfers are not pinned to RAM. Can it happen if a USB process is swapped to disk, that the system cannot wakeup a swapped out process to get more swap? >> >> --HPS > Hi, > Wow. Could I use ddb to somehow check on the "USB kernel processes" swap status when the overall context is deadlocked/live-locked? Are you able to run something like: ps auxwwH | grep usb > If yes, how? Otherwise something in top or some such display that I'd left running over the serial console would have to present useful information on the subject. Is there anything that would? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?568ED810.8010309>