From owner-freebsd-arm@FreeBSD.ORG Sat May 10 19:00:39 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FFEB234; Sat, 10 May 2014 19:00:39 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D16AE40; Sat, 10 May 2014 19:00:38 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WjCVa-000ClB-SF; Sat, 10 May 2014 19:00:31 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s4AJ0Sau031990; Sat, 10 May 2014 13:00:28 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/C7RS4aPvFDNDHRdTvX2ja Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] From: Ian Lepore To: Tim Kientzle In-Reply-To: <690B2DB4-046A-43CE-8AE4-F897E7997707@kientzle.com> References: <20140425154430.GA76168@utility-01.thismonkey.com> <535A8AEA.1000100@selasky.org> <20140425204134.GA458@cicely7.cicely.de> <20140430091411.GA45015@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7! 030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan> <690B2DB4-046A-43CE-8AE4-F897E7997707@kientzle.com> Content-Type: text/plain; charset="us-ascii" Date: Sat, 10 May 2014 13:00:28 -0600 Message-ID: <1399748428.22079.420.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 19:00:39 -0000 On Sat, 2014-05-10 at 11:25 -0700, Tim Kientzle wrote: > On May 10, 2014, at 10:14 AM, Ian Lepore wrote: > > > -- but upon return from > > handling the interrupt we'll unconditionally go to sleep until the next > > interrupt instead of returning to the scheduler which would now find new > > non-idle work to do. > > Could any of this be related to the regular > system stalls that have plagued BeagleBone? > > Run a heavy load on BBB (buildworld) > and watch the CPU idle via top in another > ssh session. > > On about a 30s cycle, you will see the > CPU usage vary from completely busy > to totally idle. > > When it goes idle, disk I/O in other logins > seems to be stalled, so I've long suspected > some problem in the disk I/O path, with > recovery tickled by the next sync flush. > > I suspect this is one of the reasons that > buildworld on BBB takes ~40hrs right now. > (The other being CPU frequency and cache > enabling; I've not yet updated U-Boot on > my BBBs.) > > I've seen this on FreeBSD-CURRENT for > as long as FreeBSD-CURRENT has run > on BeagleBone. (Almost 2 years now.) > > Tim > Is that by any chance with the object files being written to sdcard? If so, I'd expect that that's the usual bad behavior of the vfs buffer layer with slow devices. Eventually all the buffers in the system are full of dirty data waiting to be written, so new reads can't proceed, and it takes a long time to drain that many buffers to an sdcard. Anyway, to directly answer your question... No, what I was describing couldn't be the BB's problem because our code doesn't currently enable interrupts before WFI. I was explaining why I think the patch HPS proposes wouldn't be a good idea. I don't know what you mean by cache enabling... caches have always been enabled on BB. -- Ian