From owner-freebsd-arm@freebsd.org Thu Jan 7 21:24:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 114ECA67727 for ; Thu, 7 Jan 2016 21:24:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C895D174B; Thu, 7 Jan 2016 21:24:35 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [62.141.129.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F0DAA1FE022; Thu, 7 Jan 2016 22:24:31 +0100 (CET) Subject: Re: FYI: various 11.0-CURRENT -r293227 (and older) hangs on arm (rpi2): a description of sorts To: Mark Millard References: <1452183170.1215.4.camel@freebsd.org> <1452196099.1215.12.camel@freebsd.org> <568EC4D8.7010106@selasky.org> <8B728C93-9C90-4821-A607-5D157F028812@dsl-only.net> Cc: Ian Lepore , freebsd-arm From: Hans Petter Selasky Message-ID: <568ED810.8010309@selasky.org> Date: Thu, 7 Jan 2016 22:26:40 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <8B728C93-9C90-4821-A607-5D157F028812@dsl-only.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 21:24:37 -0000 On 01/07/16 21:20, Mark Millard wrote: > > On 2016-Jan-7, at 12:04 PM, Hans Petter Selasky 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