On Wed, 23 May 2012, Pantelis Antoniou wrote:
> >> Speaking of which, I did try to replicate the behavior of the Mac on Linux.
> >>
> >> 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 does sound like we have a code path (STOP UNIT command) that wasn't been
> >> exercised at all on Linux hosts, but on the Mac it is being exercised with
> >> unexpected results.
> >
> > It _has_ been exercised on Linux hosts. I tested it when it was
> > originally written.
>
> What is the explanation for the sequence above then? Kernel used on the
> device is mainline 3.4.
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?
One other thing. You could very well argue that this change:
--- usb-3.4.orig/drivers/usb/gadget/f_mass_storage.c
+++ usb-3.4/drivers/usb/gadget/f_mass_storage.c
@@ -1448,6 +1448,9 @@ static int do_start_stop(struct fsg_comm
return 0;
}
+ if (!loej)
+ return 0;
+
/* Are we allowed to unload the media? */
if (curlun->prevent_medium_removal) {
LDBG(curlun, "unload attempt prevented\n");
@@ -1455,9 +1458,6 @@ static int do_start_stop(struct fsg_comm
return -EINVAL;
}
- if (!loej)
- return 0;
-
/* Simulate an unload/eject */
if (common->ops && common->ops->pre_eject) {
int r = common->ops->pre_eject(common, curlun,
is needed. If this fixes your problem, or if it improves the behavior
of udisks (I haven't tried testing it myself), such a change would be
acceptable. Either way, I'm quite sure that your original patch does
not go in the right direction.
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
