On Thu, 24 May 2012, Pantelis Antoniou wrote: > Hi Alan, Hi. > >>>> Using udisks to send a detach command I get to see this on the console: > >>>> > >>>>> May 23 17:55:48 beagleboard [ 335.725341] lun0: unload attempt prevented > >>>>> May 23 17:55:48 beagleboard [ 335.725372] gadget: sending command-failure status > >>>>> > >>>> > >>>> And this is the result on the host: > >>>> > >>>>> root@ubuntu:~# sudo udisks --detach /dev/sdb > >>>>> Detach failed: Error detaching: helper exited with exit code 1: Detaching device /dev/sdb > >>>>> USB device: /sys/devices/pci0000:00/0000:00:11.0/0000:02:03.0/usb1/1-1) > >>>>> SYNCHRONIZE CACHE: OK > >>>>> STOP UNIT: FAILED: No such file or directory > >>>>> > >>>> > >>>> So udisks does send a STOP UNIT command too. Which fails because there was > >>>> a previous command that disallowed media unmounting. > >>> > >>> There is no such command. However there is a command that prevents > >>> media _unloading_. If you unmount all the filesystems on the device > >>> first, unloading will be allowed again. The "eject" command will do > >>> both for you. > >>> > >> > >> All the partitions were unmounted before. The command that prevented > >> media unloading was apparently issued. > > > > Okay, yes. It was issued when the device file was opened by udisks (or > > by the agent that udisks invokes). This may be a bug in udisks or > > udev; if so, don't blame the mass-storage driver. > > > > I doubt that's the case; same thing happens when using standard mount/unmount > commands instead of using udisks. What same thing happens? Do you mean that the mount/umount commands also send PREVENT MEDIUM REMOVAL commands? Or do you mean that they fail in the same way that udisks --detach fails? Besides, why would you expect either mount or unmount to behave like udisks --detach? They aren't supposed to do the same things. > > All right. I dug out my MacBook (OS-X version 10.7) and tried the same > > thing. The gadget system was running Linux 3.4 plus a few irrelevant > > additions. Note: I used the file-storage gadget (g_file_storage) > > instead of the mass-storage gadget, which might account for some > > differences, but I doubt it. > > > > > When I loaded the gadget driver with the "removable=y" option, ejecting > > the volume did indeed cause the backing file to be closed, as you > > experienced. When I loaded g_file_storage without "removable=y", > > ejecting the volume did not cause the backing file to be closed -- and > > yet it still worked perfectly well. No errors from OS-X. > > > > Do you get different results when using g_file_storage as opposed to > > g_mass_storage? > > > > > First of all, I thought g_file_storage is supposed to be deprecated. It is. I use it for testing because I'm a little more familiar with it than with g_mass_storage. The differences between the two drivers are pretty small. Ah, but now I remember one important difference that I forgot about yesterday. In order to duplicate g_mass_storage's behavior for the START STOP UNIT command, you have to build g_file_storage with CONFIG_USB_FILE_STORAGE_TEST enabled. > This is the results I get so far: > > 1. modprobe g_file_storage file=backing_file removable=n > > This is the configuration that seems to work best. Disk gets unmounted > and stays unmounted. Same as I saw. > 2. modprobe g_file_storage file=backing_file removable=y > > Ejecting the disk, makes it go away for 1sec and then remounts. That is not what I experienced. Ejecting the disk closes the backing file, so there is nothing to remount. This was probably because you didn't have CONFIG_USB_FILE_STORAGE_TEST set. > 3. modprobe g_mass_storage file=backing_file removable=n > > Same as #1, i.e. seems to work. Earlier you said that this doesn't work. You wrote: Unfortunately this has been tried, and what it does is canceling the unmount. So the disk remains perpetually mounted. What has changed? And isn't this behavior now exactly what you want? > 4. modprobe g_mass_storage file=backing_file removable=y > > Ejecting the disk once makes it impossible to mount it again. Which is the same as what I saw with g_file_storage. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
