ucom/uftdi high interrupt load

Hans Petter Selasky hselasky at c2i.net
Thu Jun 16 07:07:11 UTC 2011


On Thursday 16 June 2011 08:58:02 Charles Sprickman wrote:
> On Thu, 16 Jun 2011, Hans Petter Selasky wrote:
> > On Thursday 16 June 2011 02:01:03 Charles Sprickman wrote:
> >> On Tue, 14 Jun 2011, Hans Petter Selasky wrote:
> >>> On Tuesday 14 June 2011 02:58:44 Charles Sprickman wrote:
> >>>> On Mon, 13 Jun 2011, Hans Petter Selasky wrote:
> >>>>> On Sunday 12 June 2011 23:50:24 Charles Sprickman wrote:
> >>>>>> On Sun, 12 Jun 2011, Hans Petter Selasky wrote:
> >>>>>>> On Saturday 11 June 2011 23:43:11 Charles Sprickman wrote:
> >>>>> Ok, then those quirks won't help.
> >>>>> 
> >>>>> For OHCI, I guess you should check vmstat -i.
> >>>> 
> >>>> Oddly enough, the box paniced today, but it appeared to be related to
> >>>> fxp. However in the coredump summary, I have "vmstat -i" output, and
> >>>> ohci seems fairly high in comparison to everything else:
> >>>> 
> >>>> vmstat -i
> >>>> 
> >>>> interrupt                          total       rate
> >>>> irq4: uart0                          106          0
> >>>> irq10: ohci0                   142322001     968176
> >>>> irq14: ata0                         1178          8
> >>>> irq20: fxp0                      3008691      20467
> >>>> irq21: fxp1                      1733357      11791
> >>>> irq28: sym1                           30          0
> >>>> irq29: sym0                      2624749      17855
> >>>> cpu0: timer                    728063100    4952810
> >>>> cpu1: timer                    728044684    4952684
> >>>> Total                         1605797896   10923795
> >>>> 
> >>>> Also, just a brief summary of the panic, since it mentions the
> >>>> interrupt
> >>> 
> >>>> process again:
> >>> Hi,
> >>> 
> >>> The OHCI IRQ rate is too high. It should never exceed 1000 IRQ/s. Maybe
> >>> you can build a kernel with "options USB_DEBUG", then run the following
> >>> command and post some of the resulting dmesg:
> >>> 
> >>> sysctl hw.usb.ohci.debug=16 ; sleep 1; sysctl hw.usb.ohci.debug=0
> >> 
> >> Thanks again...  I just booted a kernel with USB_DEBUG and turned the
> >> sysctl on for a bit.  Was quite hard to turn it off though, but it also
> >> looks like time went backward on the machine, so maybe "sleep" never
> >> caught up with itself.  The output is pretty long, so I posted it here:
> >> 
> >> http://pastebin.com/HdnBYk6k  (set to never expire)
> >> 
> >> Another interesting note.  On boot, conserver failed to start for no
> >> reason I could find.  When I initially ran "vmstat -i" before manually
> >> starting conserver, the interrupt rate for ohci was much lower, maybe
> >> 30/S or so.  Starting conserver brought it up to 200-300/S.  Conserver
> >> was running during the debug logging.
> >> 
> >> Also a full dmesg is here:
> >> 
> >> http://pastebin.com/4kEYYNse
> > 
> > The logs look OK. Are you using suspend/resume on this machine?
> 
> Nope.  It's an old 1U server that we just use for utility tasks such as
> the console server.
> 
> I can tell you that during the debug, the box was nearly locked up.
> 
> Could something unusual be happening just due to the sheer number of USB
> to serial adapters involved?  There's 16 on one box, 8 on another.  In
> total, I think 20 are actually in use.

Hi,

See if any warnings pop up when you use a kernel with options USB_DEBUG.

It can be that this is overflowing the OHCI. Are you sure there is enough 
bandwidth on the OHCI to handle 16 concurrent streams?

Have you tested loopback on all 16 ports at the same time?

> 
> Any other information I can provide?
> 

Not at the present moment.

--HPS


More information about the freebsd-usb mailing list