On Wed, 20 Aug 2003, David Wuertele wrote: > I am trying to augment the 2.4.18 SCSI/USB code (usb-storage) code > to be able to hot-plug and detect usb-memory cards when > plugged in. I have things working, except when I pull > out a card when a lot of I/O is happening.
Doing development on 2.4.18 is not the best way to go; you should be using 2.6.0. > The general strategy that I am using is: > > 1. a task polls (READ_CAPACITY) for the 3 LUNs that i have > (using a Phison chip). > > 2. When it succeeds, it mounts the device > > -- user process does file i/o -- > > 3. When the card is pulled, ideally, a READ_CAPACITY fails > and the processes with open files are sent a kill signal (SIGHUP) > and the device unmounted. Killing the processes is a rather drastic approach. But working from a user task you have no other choice. > PROBLEM > When a process is reading from the card, if the card is pulled > the Phison chip sometimes locks up, so I: > 1. reset the hub port > 2. Fail the pending read So you have to contend with hardware failures in addition to everything else! How does your polling task, which is in a different process from the one doing the read, manage to fail the pending read? > However there is times when the usb (submit) does not come back > fast enough, so the READ_10 times out (seems to take over 10 seconds). > The abort handler is called (by scsi), which unlinks the urb > and says ok (to abort). I then return a DID_ERROR to the > SCSI-CMD. What do you mean, _you_ return DID_ERROR? The usb-storage driver does that. > However the bottom half handler of this command > says that since the timer went off, it returns doing nothing. > In the meanwhile the user-process is stuck inside the file/io > routines (waiting on the buffer completion - in TASK_UNINTERRUPTIBLE > state). So I cannot unmount the device (or handle new mounts). That's one of the disadvantages of not working within the kernel. > Questions: > > 1. Is there a better strategy than the above for dectecting > plug-unplug? Using polling isn't a good way to do this. Ideally, the chip would return Unit Attention whenever a card was installed or removed. If it does, and you modify the SCSI driver to detect those events, you'd have a better chance of making things work as they should. > 2. How do i handle the failure? You can't. The SCSI driver in 2.4 doesn't handle hot-unplugging. That's another reason to work with 2.6. > 3. What am i supposed to do in abort handler, so that the SCSI > subsystem can continue working? There's nothing you can do. An abort handler must handle many different kinds of problems; a card being removed is just one of them. In fact, there probably isn't any way for the abort handler to realize that the cause of the abort is a card removal. Sorry to be so negative, but your approach just isn't viable. Alan Stern ------------------------------------------------------- This SF.net email is sponsored by Dice.com. Did you know that Dice has over 25,000 tech jobs available today? From careers in IT to Engineering to Tech Sales, Dice has tech jobs from the best hiring companies. http://www.dice.com/index.epl?rel_code=104 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
