kern/43318: Recent -current asserts with USB activity

[scotte%warped.com@localhost]

>Number:         43318
>Category:       kern
>Synopsis:       Recent -current asserts with USB activity
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 16 23:10:00 +0000 2010
>Originator:     Scott Ellis
>Release:        amd64-current (5.99.29)
>Organization:
None
>Environment:
NetBSD intrepid 5.99.29 NetBSD 5.99.29 (INTREPID.P5W.DEBUG) #1: Sun May 16 
08:15:45 PDT 2010  
scotte@intrepid:/nbu/source/netbsd/src/obj.amd64/nbu/source/netbsd/src/sys/arch/amd64/compile/INTREPID.P5W.DEBUG
 amd64

>Description:
USB activity eventually causes kernel to assert and panic.  This is evident 
from reboots in my daily scripts (backing up via rsync to a umass disk), but 
also seen manifesting itself with uplcom not actually sending any data, and 
then eventually a kernel panic.  Kernel reports:

usbd_do_request: not in process context
usbd_do_request: not in process context
usbd_do_request: not in process context
usbd_do_request: not in process context
usbd_do_request: not in process context
usbd_do_request: not in process context
usbd_do_request: not in process context
usbd_do_request: not in process context
panic: kernel diagnostic assertion "c->c_func != NULL" failed: file 
"/nbu/source/netbsd/src/sys/kern/kern_timeout.c", line 331
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ffffffff8014a8ad cs 8 rflags 246 cr2  7f7ffdb51020 cpl 8 
rsp ffff8000534ba530
Stopped in pid 0.3 (system) at  netbsd:breakpoint+0x5:  leave
db{0}>
db{0}> bt
breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x2ba
kern_assert() at netbsd:kern_assert+0x2d
callout_schedule_locked() at netbsd:callout_schedule_locked+0x168
syn_cache_add() at netbsd:syn_cache_add+0x4ca
tcp_input() at netbsd:tcp_input+0x910
ip_input() at netbsd:ip_input+0x5b0
ipintr() at netbsd:ipintr+0x90
softint_dispatch() at netbsd:softint_dispatch+0xcc
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xffff8000534bad70
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---
0:

db{0}> machine cpu 1
using CPU 1
db{0}> bt
x86_mwait() at netbsd:x86_mwait+0xd
idle_loop() at netbsd:idle_loop+0x199
?() at 0
db{0}>

Appears to have been introduced sometime after April 21st, and before May 14th 
(my gap in staying with -current).  I don't have an exact workload to trigger 
it, but from the backtrace it appears that it's not "load" related, but more a 
timing problem.
>How-To-Repeat:
Generate USB traffic on uplcom or umass.
Wait.
(Sad steps, I know.)
>Fix: