Hi Alan, thanks for taking the time to reply. > > I think it's safe to assume that if a USB device is disconnected and > > reconnected > > then the old USB device will have called shutdown_atm_dev (this is called > > in the > > disconnect method) before the new USB device creates an ATM device (this is > > done > > in the probe method or later). But I'm not sure. It might not be true if > > someone > > managed to unplug from one port and plug into another in less than 200 > > milliseconds. > > It also might not be true I suppose if the device was disconnected by the > > hub due > > to some kind of electrical problem, and reassigned by the hub to a > > different port > > (I don't know if any hubs play this kind of trick). I guess that any kind > > of > > disconnect/reconnect on the same USB port, real or logical, will see the > > old device > > disconnected before the new device is probed. Maybe some of the USB guys > > can > > confirm this. > > It is true that disconnect on a port will always complete before a > reconnect on that same port begins. It will also complete before > reconnect on another port, although here you're getting into a murky area. > For instance, what if someone has two of these USB ATM devices and plugs > the second one in just before disconnecting the first? > > A driver should be robust enough to work in any situation, regardless of > the order of disconnect and probe calls. The only reason for possible > problems would be if the driver had a notion of "device identity" -- that > is, it could tell if two different instances actually were the same > device.
The problem here is the way ATM connections are opened: you specify a device number, called the interface number, as well as some other info. Alternatively, you can specify ATM_ITF_ANY instead of a device number, and all devices will be queried until one is found that is prepared to open the connection. With the speedtouch USB modems, the problem people usually see is: (A) for normal people, the modem is the only ATM device (and there's only one modem). Thus this is ATM device zero. (B) people connect using pppd; pppd doesn't support ATM_ITF_ANY, so most people specify that the connection should be to device number 0. pppd is usually run from a hotplug or init script. (C) at some point the modem spontaneously disconnects and reconnects (surprisingly common with some motherboards). pppd takes several seconds to understand that ATM device 0 has died; until it understands this, it keeps a connection open, which means that the ATM device hangs around. The "new" modem (= old one reconnected) creates a new ATM device, which is given device number 1, because number 0 is still being used by the old device. (D) a new instance of pppd is launched from a hotplug script, or the old instance of pppd tries to open a new connection once it understands that the old connection has died. It tries to connect to device 0, but there is no longer any device 0, only device 1, so the connection attempt fails. (E) the user notices that there is no internet connection and wonders why. The user runs pppd by hand - and it still fails to connect (no device 0). Eventually the user gives up and reboots the machine. Ciao, Duncan. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
