Date: Sat, 10 May 2014 11:25:40 -0700 From: Tim Kientzle <tim@kientzle.com> To: Ian Lepore <ian@freebsd.org> 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: <690B2DB4-046A-43CE-8AE4-F897E7997707@kientzle.com> In-Reply-To: <1399742062.22079.403.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?690B2DB4-046A-43CE-8AE4-F897E7997707>