Steven M. Bellovin wrote:
> In message <43F4A740.5090005@tadpole.com>, "Garrett D'Amore" writes:
>   
>> You are saying PCMCIA, but your dump indicates USB. Am I missing something?
>>
>>     
>
> This is a Cardbus card that contains on it a USB hub; the rest of the 
> electronics speak USB.  I assume they did that to make it easy to build 
> two versions of the device, one that plugs in to a PCMCIA slot and one 
> that plugs into a USB port.
>   
There are various controllers out there that might do bad things if
activity is occurring on the bus when you detach them. You're *supposed*
to receive a high-level interrupt and turn off the driver to stop any IO
(e.g. set a flag that says card removed), but my experience with the
PCMCIA stuff in NetBSD shows that this isn't done. Instead, they rely on
accesses to the PCMCIA bus to return garbage data and let the driver
deal with it.

Also complicating the matter is DMA. With DMA and Cardbus, it is usually
a really bad idea to hot-remove cards without stopping them first.

It looks like there is cardbus_function_disable() in the kernel that
should stop all this and power off the device, but I have no idea how
you get to it from userland.

Seems like what we really need is a userland routine to detach device
instances.

-- Garrett
>   
>> Steven M. Bellovin wrote:
>>     
>>> I have a card that, on removal, sometimes crashes my machine.  The card 
>>> is an EVDO modem:
>>>
>>> ohci0 at cardbus0 function 0: NEC USB Host Controller (rev. 0x43)
>>> ohci0: interrupting at 11
>>> ohci0: OHCI version 1.0
>>> usb4 at ohci0: USB revision 1.0
>>> uhub4 at usb4
>>> uhub4: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
>>> uhub4: 1 port with 1 removable, self powered
>>> ohci1 at cardbus0 function 1: NEC USB Host Controller (rev. 0x43)
>>> ohci1: interrupting at 11
>>> ohci1: OHCI version 1.0
>>> usb5 at ohci1: USB revision 1.0
>>> uhub5 at usb5
>>> uhub5: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
>>> uhub5: 1 port with 1 removable, self powered
>>> umodem0 at uhub4 port 1 configuration 1 interface 0
>>> umodem0: Curitel Communications, Inc. Curitel Communications, Inc., rev 1.10
>>>       
>> /0.00, addr 2, iclass 2/2
>>     
>>> umodem0: data interface 1, has CM over data, has break
>>> umodem0: status change notification available
>>> ucom0 at umodem0
>>>
>>> I run ppp over it.  (That has its own set of problems, but they're not 
>>> the point of this note.)
>>>
>>> Anyway -- I of course kill pppd before removing the cards.  With 
>>> moderate frequency, though -- say, about 10% of the time -- when I 
>>> remove the card the laptop reboots.  As best I can tell, it's not going 
>>> into ddb nor panicking, but since I've never seen any messages I can't 
>>> be certain.  (Recently, I've started killing my Console window and 
>>> switching to screen 1 before removing the card, to see if anything 
>>> shows up.)  There definitely haven't been any dumps.  The question, 
>>> then, is what would cause a machine to spontaneously reboot.
>>>
>>> My current working hypothesis is that it's a power glitch.  I'd like to 
>>> be able to power down the slot before removing the card.  If necessary, 
>>> I'm willing to power it back up manually when inserting a card, though 
>>> it would nicer if I didn't have to worry about that.
>>>
>>> So -- how can this best be done?  (And does anyone have any better 
>>> hypotheses about why the machine crashes?)
>>>
>>> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>>>
>>>   
>>>       
>> -- 
>> Garrett D'Amore, Principal Software Engineer
>> Tadpole Computer / Computing Technologies Division,
>> General Dynamics C4 Systems
>> http://www.tadpolecomputer.com/
>> Phone: 951 325-2134  Fax: 951 325-2191
>>
>>     
>
>
> 		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
>
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191