Hi Alan,
On May 23, 2012, at 10:58 PM, Alan Stern wrote:
> 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 doubt that's the case; same thing happens when using standard mount/unmount
commands instead of using udisks.
>>>> 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?
>
First of all, I thought g_file_storage is supposed to be deprecated.
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.
2. modprobe g_file_storage file=backing_file removable=y
Ejecting the disk, makes it go away for 1sec and then remounts.
3. modprobe g_mass_storage file=backing_file removable=n
Same as #1, i.e. seems to work.
4. modprobe g_mass_storage file=backing_file removable=y
Ejecting the disk once makes it impossible to mount it again.
> 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
>
I'll try this one tomorrow.
Regards
-- Pantelis
--
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
