USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi]
Tim Kientzle
tim at kientzle.com
Sat May 10 18:43:47 UTC 2014
On May 10, 2014, at 10:14 AM, Ian Lepore <ian at 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
More information about the freebsd-arm
mailing list