Date: Sat, 10 May 2014 13:00:28 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Tim Kientzle <tim@kientzle.com> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@FreeBSD.org>, Alexander Motin <mav@FreeBSD.org> Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] Message-ID: <1399748428.22079.420.camel@revolution.hippie.lan> 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> <CAGW5k5bZ_bTQUXuzNm=tbwx3npz1_HoOR3vM8TBRVFs8zWCq-w@mail.gmail.com> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <CAJ-Vmo=XmH-RX6_i13NuAXhq-jTC%2BWedGiyOMJaPO4r014DSgw@mail.gmail.com> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <CAJ-Vmok-%2B7%2Bcq%2BDa6_C2AA7BuP5readY_Gfwwm_RF5kh4VerQA@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2014-05-10 at 11:25 -0700, Tim Kientzle wrote: > On May 10, 2014, at 10:14 AM, Ian Lepore <ian@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1399748428.22079.420.camel>