Subject: kern/12079: usb is panicking my machine somewhat regularly
To: None <gnats-bugs@gnats.netbsd.org>
From: Andrew Brown <atatat@atatdot.net>
List: netbsd-bugs
Date: 01/29/2001 10:55:21
>Number:         12079
>Category:       kern
>Synopsis:       usb panicking somewhat regularly
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 29 10:58:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     TheMan
>Release:        -current from 2000/01/12
>Organization:
none
>Environment:
	
System: NetBSD this 1.5Q NetBSD 1.5Q (THAT) #27: Fri Jan 12 12:15:56 GMT 2001     andrew@this:/usr/src/sys/arch/i386/compile/THAT i386


>Description:

my ricochet usb modem works really well, but occasionally loses
contact and needs to be redialed.  sometimes it gets stuck and likes
to be reset by hand, which usually means (or used to mean) using cu
and issuing an ATH and an ATZ command.  more recently (not that i've
changed anything in my kernel), that results in a panic.  this time i
did i from the console before starting x, so i have a decent
traceback, but with no core.  usually what happens is the usb panic
and then almost directly after that, another panic because the dump
device "isn't ready".  there's a bit missing at the top because my
message buffer is only so large.

......5608f4,cf57cf30) at vn_close+0x2b
vn_closefile(cf5375d4,cf5608f4,cf5375d4,0,cf5608f4) at vn_closefile+0x17
closef(cf5375d4,cf5608f4,cf57cf80,cf5608f4,c038aee0) at closef+0x19b
fdrelease(cf5608f4,0,cf57cfa8,c027681d,cf5608f4) at fdrelease+0xa0
sys_close(cf5608f4,cf57cf88,cf57cf80) at sys_close+0x1a
syscall_plain(bfbf001f,1f,bfbfdff0,bfbfdbbc,bfbfdb2c) at syscall_plain+0x95
End traceback...

dumping to dev 0,1 offset 17063
dump device not ready


panic: wdc_exec_command: polled command not done

Begin traceback...
wdc_exec_command(c07df8f8,cf57c794) at wdc_exec_command+0xca
wd_flushcache(c07cb000,10,cf57c7d0,c015bc69,c07cb000) at wd_flushcache+0x4d
wd_shutdown(c07cb000) at wd_shutdown+0xd
doshutdownhooks(cf57c804,cf57c7f8,c0165169,104,0) at doshutdownhooks+0x25
cpu_reboot(104,0,c07df8b4,c07e0030,1) at cpu_reboot+0x68
panic(c034ed4c,c034ed20,c07df814,0,0) at panic+0xcd
wdc_ata_bio_intr(c07df8b4,c07e0030,1,c07d0ca0,c0101c16) at wdc_ata_bio_intr+0x7e
wdcintr(c07df8b4,cf57c85c,c01018ec,c07df8b4,80000000) at wdcintr+0xb1
pciide_compat_intr(c07df8b4) at pciide_compat_intr+0x22
Xintr14() at Xintr14+0x70
--- interrupt ---
Xspllower(cf57c8d0,cf57c8cc,c0100e50,cf57c8d0,0) at Xspllower+0xe
clockintr(cf57c8d0) at clockintr+0xb
Xintr0() at Xintr0+0x6c
--- interrupt ---
Xspllower(cf57c954,10,c037731e,2,0) at Xspllower+0xe
usb_delay_ms(c07e1000,1) at usb_delay_ms+0x61
uhci_run(c07e1000,0,cf57c984,c015bc69,c07e1000) at uhci_run+0xb8
uhci_shutdown(c07e1000) at uhci_shutdown+0xd
doshutdownhooks(cf57c9b8,cf57c9ac,c0165169,104,0) at doshutdownhooks+0x25
cpu_reboot(104,0,c0281670,c07cb000,1) at cpu_reboot+0x68
panic(c034ea00,2,cf57cb3c,c0281468,1) at panic+0xcd
wddump(1,a41cd7,cf57cb04,200,63ea0) at wddump+0x1f2
cpu_dump(100,c034c25b,100,84,23) at cpu_dump+0x101
dumpsys(cf57cd70,cf57cd64,c0165169,100,0) at dumpsys+0xed
cpu_reboot(100,0,deadb000,0,6) at cpu_reboot+0x63
panic(c034c25b,c000ef6c,c000ef6c,deadbf5f,cf57cddc) at panic+0xcd
trap() at trap+0x1dd
--- trap (number 6) ---
uhci_abort_xfer(deadbeef,6,cf57ce08,c02fd9d9,deadbeef) at uhci_abort_xfer+0x24
uhci_device_bulk_abort(deadbeef) at uhci_device_bulk_abort+0xd
usbd_ar_pipe(c0898900,c089fa00,ceb4258c,cf57ce30,c03043e1) at usbd_ar_pipe+0x1d
usbd_abort_pipe(c0898900,c089fa00,c089fa00,cf57ce44,c0303a32) at usbd_abort_pipe+0x35
ucom_cleanup(c089fa00) at ucom_cleanup+0x15
ucomclose(4200,3,2000,cf5608f4,cf56deec) at ucomclose+0x6a
spec_close(cf57cea8,cf56deec,cf56deec,cf56df70,30002) at spec_close+0x153
ufsspec_close(cf57cea8,3,c038ce00,cf56deec,3) at ufsspec_close+0x124
VOP_CLOSE(cf56deec,3,c0898480,cf5608f4,cf56deec) at VOP_CLOSE+0x38
vn_close(cf56deec,3,c0898480,cf5608f4,cf57cf30) at vn_close+0x2b
vn_closefile(cf5375d4,cf5608f4,cf5375d4,0,cf5608f4) at vn_closefile+0x17
closef(cf5375d4,cf5608f4,cf57cf80,cf5608f4,c038aee0) at closef+0x19b
fdrelease(cf5608f4,0,cf57cfa8,c027681d,cf5608f4) at fdrelease+0xa0
sys_close(cf5608f4,cf57cf88,cf57cf80) at sys_close+0x1a
syscall_plain(bfbf001f,1f,bfbfdff0,bfbfdbbc,bfbfdb2c) at syscall_plain+0x95
End traceback...

dumping to dev 0,1 offset 17063
dump device not ready

the "deadbeef" in the call to uhci_device_bulk_abort() seems to be a
good place to start dying.  :)

>How-To-Repeat:

not entirely concrete.  lately, when i get dropped, simply doing

   # pppd call ricochet
   # kill <pid of chat program>
   # cu -l /dev/ttyU0

is enough to trigger it.

>Fix:

dunno.  but i do seem to crash less if i unplug and powercycle the
modem instead of trying to reset it by hand.
>Release-Note:
>Audit-Trail:
>Unformatted: