In message <1F064FC6-4010-4E18-BFD2-0B24A2626337@shagadelic.org>, Jason Thorpe 
writes:
>
>On Feb 16, 2006, at 12:44 PM, Steven M. Bellovin wrote:
>
>> In message <43F4E065.306@tadpole.com>, "Garrett D'Amore" writes:
>>
>>>> What is the "device" I'd use with 'drvctl -d'?  ohci0?  Or do I  
>>>> have to
>>>> do it recursively, starting with ucom0 and uhub5?  And what bus (and
>>>> perhaps locator or attribute) do I use with 'drvctl -r'?
>>>>
>>> Those are excellent questions. Unfortunately, I don't have an answer.
>>> Experiment and see what happens.
>>>
>>> As they say, "use the Source, Luke".
>>
>> I had looked at drvctl.c and kern_drvctl.c before I posted, but  
>> they're
>> both short and sweet and led to a complex maze of configuration
>> routines...
>
>Detach the ohci @ cardbus, and that will itself recurse down to  
>remove the children.
>

Thanks; that works; I've added that to my script and I'll see if it 
prevents crashes.  

I did see a crash today.  The traceback shows the following:

Page fault....

usbd_alloc_xfer
usbd_do_request
usbd_do_request_flags
usbd_reset_port
uhub_explore
usb_discover
usb_event_thread

I did discover that when I set up the system, I only allocated 1G for 
swap and I now have 2G of RAM, so I couldn't get a dump....  

I also tried the same thing after inserting a USB flash drive, to see 
if it would power down the drive.  No joy.  And I managed to crash the
machine during my experiments, though I'm not certain how; I'll have to
play with that some more later.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb