(Please CC: these messages to the USB development list in addition to sending directly to me.)Disconnect is called when I unplug the wlan card. In the case of a dataflash device when device_del is called dev->parent is not NULL
On Wed, 14 Jan 2004, Stavros Markou wrote:
Alan Stern wrote:
On Tue, 13 Jan 2004, Stavros Markou wrote:This happens only with eeprom devices that need reset in order to get the new descriptors. I am currently working with two types of WLAN devices (eeprom and dataflash). I 've observed that the devices that don't need reset (dataflash) load and unload without problem. Devices that need reset (eeprom) load succesfully, but inside usb_disable_device (which is called by usb_disconnect) I get a NULL pointer reference in device_del so all urbs remain pending and the system is in panic.
I am using that patch but now I am facing problems during disconnect because inside usb_disable_device after device_del I get a crash.That sounds like something new. Can you post the details of what happens when the crash occurs?
I think you're running up against one of a number of imperfections related to the current usb_reset_device() code. This particular problem arises because usb_disconnect() assumes that all the interfaces will have been registered before any disconnect occurs.
Do you know why usb_disconnect() is getting called at all? Is it happening inside your call to usb_reset_device()? Or is it happening sometime later? Can you post the stack trace from your system panic?
but in the case of eeprom device dev->parent is NULL. My opinion is that the use of __usb_reset_device (ex usb_physical_reset_device) by the one type of device and not the other has nothing to do with the fact that when I unplug those devices I get two distinct results.
Stavros Markou.I could believe that usb_disconnect is getting called by mistake. There is a flaw in usb_reset_device(); it sends a port reset command to the hub upstream of your device, but it then does not prevent the hub driver from responding to connect-changed or enable-changed status messages on that port. Either one could cause usb_disconnect() to be called prematurely.
The fact is, parts of the hub driver and in particular the usb_reset_device() routine need to be rewritten. This process has already begun, but I'm waiting for the current changes to be accepted into the kernel before sending in any more.
Alan Stern
------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
