umcs (4-Port-USB-serial) triggering way too much ehci IRQs
ian at FreeBSD.org
Tue Sep 17 16:16:13 UTC 2013
On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote:
> Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24
> > On 09/17/13 11:06, Harald Schmalzbauer wrote:
> >> ...
> >> Shall we switch to non-list-comm?
> > Hi,
> > That's OK.
> >> Hmm, in my case, this 4-port-serial-USB-hub will be used as console
> >> concentrator. So most time it's doing nothing, just feeding tmux with
> >> consoles output. What latency are we talking about? Less than a some
> >> milliseconds should be fine.
> >> What I'm curious about is why my prolific USB-serial converter doesn't
> >> generate these high irqs.
> > Try this patch and see what happens:
> > ==================================================================
> > --- umcs.c (revision 255492)
> > +++ umcs.c (local)
> > @@ -230,6 +230,7 @@
> > .bufsize = 0, /* use wMaxPacketSize */
> > .callback = &umcs7840_intr_callback,
> > .if_index = 0,
> > + .interval = 20, /* ms */
> > },
> > };
> > BTW: I see that the umcs driver shouldn't do synchronous control
> > transfers from the USB interrupt transfer callback. This should be
> > postponed into some worker thread, for example the USB explore thread.
> > See USB audio driver for an example.
> > --HPS
> I tried your patch and it works as expected: IRQs decreased to ~64/s
> when idle/disconnected.
> One interesting thing I never measured before:
> Console connection with 115k2 via umcs and 'while ( 2>1 ) echo "---..."
> end' results in 8000 irqs/s :-( But that's also true for the prolific
> (uplcom). The latter just goes down to 0.0 irqs/s when idle.
> Doing the same with uart0 results in 1444irqs/s.
> Is it by design/unavoidable that transfering the same via USB multiplies
> by factor 5-6?
I don't know about that chipset, but with the FTDI chips it does xfers
in 64 byte chunks and high speed bulk data results in an astronomical
number of interrupts (and if you go fast enough, lost data). I have
some patches that assemble lots of the little chip-size buffers into
bigger xfers that the ohci/ehci controller can handle without
interrupting the processor; that helps the problem a bunch.
More information about the freebsd-stable