On Sat, 5 Aug 2006, Pete Zaitcev wrote: > > With the iPod, there is nothing to eject. Even worse, when the iPod > > receives a SCSI eject command, it usually crashes! > > Well, yeah, this is what -71 is. However, when exactly the same > eject binary is used with ub, everything works fine. Funny, isn't it?
I looked into it a bit more closely. Here's the complete story. When sd opens a device, it issues a PREVENT-ALLOW command to lock the medium, unless the device is marked as not lockable. Any device with non-removable media is automatically not lockable, and usb-storage marks devices non-lockable if they have the US_FL_NOT_LOCKABLE flag. By contrast, when ub opens a device it does not issue a PREVENT-ALLOW command. When eject runs, the first thing it does is issue a CDROMEJECT ioctl. If the the medium is locked then of course the command fails with -EIO. So typically with usb-storage this step fails, whereas with ub it succeeds. Next eject issues several SG_IO ioctls. The first is a PREVENT-ALLOW command to unlock the medium. In general this succeeds, although some devices will crash when they receive the command. (These are the ones marked with US_FL_NOT_LOCKABLE. Luckily these devices would have succeeded already in the CDROMEJECT step.) The next SG_IO command is START-STOP with LoEj=0, Start=1. In other words, Start or Spin-Up. I don't know why it does this; maybe some devices have to be started before they can eject. Anyway, it's at this point that the iPod crashes. Then eject sends an SG_IO START-STOP command with LoEj=1, Start=0. In other words, a true Eject command. With the iPod it never gets this far because the iPod is already dead. It appears there's plenty of blame to go round. The SCSI stack, the eject program, and the iPod all do strange things that end up mutually interfering. Maybe the best answer is to issue another CDROMEJECT after the PREVENT-ALLOW SG_IO, and if it fails then issue Spin-Up followed by Eject (note that the Eject command is exactly the same as what CDROMEJECT ends up sending). You might want to pass this idea on to the people at RedHat who maintain the eject package. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
