ucom/uftdi high interrupt load

[Hans Petter Selasky]

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?

--HPS