ucom/uftdi high interrupt load

[Charles Sprickman]

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

Thanks,

Charles

> --HPS
>
>>
>> #7  0x8059139b in fxp_new_rfabuf (sc=0x8564c000, rxp=0x8564c1c0)
>>      at /usr/src/sys/dev/fxp/if_fxp.c:2611
>> #8  0x8059285b in fxp_intr (xsc=0x8564c000)
>>      at /usr/src/sys/dev/fxp/if_fxp.c:1931
>> #9  0x8067b1db in intr_event_execute_handlers (p=0x8553d7f8,
>> ie=0x8557d080)
>>      at /usr/src/sys/kern/kern_intr.c:1220
>> #10 0x8067c8eb in ithread_loop (arg=0x856525d0)
>>      at /usr/src/sys/kern/kern_intr.c:1233
>> #11 0x80678f11 in fork_exit (callout=0x8067c880 <ithread_loop>,
>>      arg=0x856525d0, frame=0xd80e7d38) at /usr/src/sys/kern/kern_fork.c:844
>> #12 0x80931de0 in fork_trampoline () at
>> /usr/src/sys/i386/i386/exception.s:270
>>
>> And also unrelated to usb, but fairly bizarre "netstat -m" output:
>>
>> 18446744073709550887/1355/626/25600 mbuf clusters in use
>> (current/cache/total/max)
>> 18014398509480560K/3497K/2073K bytes allocated to network
>> (current/cache/total)
>>
>> Sorry for all the extra noise, but I'm not adept enough at determining
>> whether this panic was usb related or fxp related.
>>
>> Thanks,
>>
>> Charles
>>
>>> --HPS
>