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