Re: usb panic

[Andrew Atrens <atrens@xxxxxxxxxxxxxxxxxx>]

On Tuesday 13 January 2004 17:06, Matthew Dillon wrote:
> :Hi,
> :
> :Here's part of the trace from my usb panic. Happens during boot, when my
> : flash stick is plugged in -
>
>     There are a couple of delayed-timeout crashes that can occur with USB
>     devices.  What happens is that the USB device schedules a delayed
> timeout on a related structue but then unexpectedly detaches and it's
> related structures are freed before the timeout occurs.
>
>     Is there any chance you can get a crash dump?  It may not be possible
>     due to being so early in the boot sequence.
>

The initial attach seems to be fine. But your right a detach does happen later 
on in the boot sequence (for no apparent reason). And this is the trigger for 
the trap. When the detach doesn't happen, trap doesn't happen either (which 
is 2/5 times, maybe). In these instances I do get some error messages -
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <KINGSTON DATA TRAVELER 1.11> Removable Direct Access SCSI-CCS device
da0: 1.000MB/s transfers
da0: 246MB (503808 512 byte sectors: 64H 32S/T 246C)
cam_periph_alloc: attempt to re-allocate valid device pass2 rejected
passasync: Unable to attach new device due to status 0x6
cam_periph_alloc: attempt to re-allocate valid device da0 rejected
daasync: Unable to attach to new device due to status 0x6

which don't seem to be so good either ... but the device works (well, provided 
I don't transfer big chunks of data from it). ;)


I can break to the debugger, but when I ask it to panic it says 'Synching 
filesystems' and hangs forever.. I've set dumpdev in loader.conf and it 
doesn't seem to help. Following a crash of this type the system doesn't fsck 
filesystems so when it crashes it must not be getting far enough along for 
filesystem access.

As another data point I figured that the panic was happening in cam_xpt.c due 
to a null pointer / function call so I put some simple checks in to stop that
from happening. So now no trap, and I get attach/detach messages when I'm 
plugging/unplugging the device, but the boot is hung. I suppose the 
func/pointer call must normally be manipulating the IPL, and in it's absence 
we're wedged. Here's my pretty braindead patch for this -

Index: cam_xpt.c
===================================================================
RCS file: /usr/dfly/repo/src/sys/bus/cam/cam_xpt.c,v
retrieving revision 1.8.2.1
retrieving revision 1.8
diff -b -B -r1.8.2.1 -r1.8
2876d2875
<         if ( sim && sim->sim_action && *(sim->sim_action) ) 
2942d2940
<         if ( sim && sim->sim_action && *(sim->sim_action) ) 
2951d2948
<         if ( sim && sim->sim_action && *(sim->sim_action) ) 
3735d3731
<         if ( sim && sim->sim_action && *(sim->sim_action) ) 
5960d5955
<         if ( sim && sim->sim_action && *(sim->sim_action) ) 


It shows where the trap is (by preventing it), but I still can't get panic
to produce a coredump, so I'm no further ahead :P

Cheers,

Andrew.

> 					-Matt
> 					Matthew Dillon
> 					<dillon@xxxxxxxxxxxxx>
>
> :--- trap 0xc eip = 0, esp = 0xc221dce8, ebp = 0xc221d0c ---
> :(null)(c2342f00) at 0
> :xpt_release_devq_device(d181ce30,1,1,c221dd64,c01c92b9) at
> : xpt_release_devq_device+0xda xpt_release_devq_timeout(d181ce30,0,0,16,58)
> : at xpt_release_devq_timeout+0x10 swi_softclock(0) at swi_softclock+0xd1
> :ithread_handler(16,0,0,0,0) at ithread_handler+0x41

Attachment: pgp00006.pgp
Description: signature