Date: Tue, 17 Sep 2013 10:16:07 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Harald Schmalzbauer <h.schmalzbauer@omnilan.de> Cc: lev@FreeBSD.org, FreeBSD Stable <freebsd-stable@FreeBSD.org>, freebsd-usb@FreeBSD.org, Hans Petter Selasky <hans.petter.selasky@bitfrost.no> Subject: Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs Message-ID: <1379434567.1197.48.camel@revolution.hippie.lan> In-Reply-To: <5238775C.8010000@omnilan.de> References: <52372DBA.6020703@omnilan.de> <zarafa.5237e529.2bc6.08fde6eb34c27a87@mail.lockless.no> <875323075.20130917124437@serebryakov.spb.ru> <523816E1.10603@omnilan.de> <1857258551.20130917124737@serebryakov.spb.ru> <5238198C.3070604@bitfrost.no> <52381BAC.5010801@omnilan.de> <52381FCA.5030509@bitfrost.no> <5238775C.8010000@omnilan.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote: > Bez=FCglich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24 > (localtime): > > 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 wit= h > >> 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: > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- umcs.c (revision 255492) > > +++ umcs.c (local) > > @@ -230,6 +230,7 @@ > > .bufsize =3D 0, /* use wMaxPacketSize */ > > .callback =3D &umcs7840_intr_callback, > > .if_index =3D 0, > > + .interval =3D 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 >=20 > I tried your patch and it works as expected: IRQs decreased to ~64/s > when idle/disconnected. >=20 > 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. >=20 > Doing the same with uart0 results in 1444irqs/s. > Is it by design/unavoidable that transfering the same via USB multiplie= s > by factor 5-6? >=20 > Thanks, >=20 > -Harry >=20 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. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1379434567.1197.48.camel>