On 05/03/2017 at 08:10 PM, Alan Stern wrote:
> On Wed, 3 May 2017, Andreas Hartmann wrote:
> 
>>>> The remove part should start in usb-ene-3.log.gz with
>>>>
>>>> [ 4261.261188] *** thread awakened
>>>
>>> Starting from that point, the log file shows four apparently successful 
>>> writes, followed by what looks like a re-scan of the device and a bunch 
>>> of reads.
>>
>> Could it be that the rescan is responsible for those log entries, which
>> can be seen after removal?
> 
> Probably.  But I'm having trouble understanding this.  Which log
> entries in particular do you mean?  The writes could be the system 
> flushing its page buffer, and the reads could all be part of the 
> re-scan.

I referred to the res-cans you mentioned above.

>  I didn't do a detailed comparison between the re-scan and the 
> original scan near the start of the log.

My understanding of re-scan was: Device could have been deactivated and
right after disabling, it was enabled again. That's why I can see the
same device load entry as directly after putting in the card.

> 
>> A normal removal works like this:
>> click on remove and after a few seconds (stating, that the device is
>> ready to be removed now) the device entry disappears.
> 
> It's difficult to know what this involves.  Your GUI environment could
> be doing lots of stuff when you click on Remove.

That was the behavior before these changes and it's the behavior of all
other devices I know off.

> 
>> In this case, it's working like this:
>> Click on remove. Then always 3 device entries appear (stating, that the
>> device could be removed now) and shortly after, there are two entries,
>> each of them claiming that there are two actions for this device
>> (opening with filemanager or with some other application). Some time
>> later, one of those two entries disappear. With the resulting entry, the
>> device can be reopened again (exactly the same entry as on initially
>> plugged in card).
> 
> What do you mean by "3 device entries appear"?  Where do they appear? 

It's the tool (e.g. the KDE plasma ) to safely remove the device (= sdcad).
https://userbase.kde.org/Plasma/DeviceNotifier


> What kind of device entries are they?

After plugging in the device, this entry appears:
https://userbase.kde.org/File:Device_Notifier_Widget_Actions.png



Clicking on the left arrow which can be seen in the following
screenshot, removes the device again. Afterwards, no more device entries
should be there (if there wasn't anyone more before).

https://userbase.kde.org/File:Device_Notifier_Widget.png


But since these changes it behaves like that, that after clicking on
remove, there appear 3 entries stating, that the device can be removed
now (no screenshot at the given page), and short time later, there are 2
entries like this one:
https://userbase.kde.org/File:Device_Notifier_Widget_Actions.png . Very
short time late again, it's just one - same as at the beginning after
the sdcard has been plugged in.

>> From my point of view, the device never got disabled - if it would have
>> been disabled, it wouldn't be possible to reload it again after removing
>> (by click) without replugging it.
> 
> Why would clicking on Remove cause the device to be disabled?  For that
> matter, exactly what do you mean when you talk about disabling the
> device?  And which device are you trying to disable: the SCSI disk 
> device or the USB card reader device?

The device is the sdcard - the card reader is built in :-) and can't be
removed :-).

> Is Remove supposed to be the same as unmount?  Or is it supposed to 
> tell the system that the memory card has been taken out of the reader?

unmount and disabling with something like
echo 1 > /sys/block/sdh/device/delete

umount of the device leads to the initial entry again:
https://userbase.kde.org/File:Device_Notifier_Widget_Actions.png

echo 1 > /sys/block/sdh/device/delete removes the device from the list
of available devices. You have to replug the device again to see the
initial entry again.

Iow: the echo 1 > /sys/block/sdh/device/delete is missing or gets
"overwritten" by the rescan.

> 
> Bear in mind that the eneub6250 driver does not detect card removal 
> correctly.  If you want to change cards, the best approach would be to 
> do a "safely remove hardware" and then unplug the reader from the 
> computer and replug it with the new card inserted.

That's not possible as it is a build in reader. And there wasn't any
problem before these changes.



Kind regards,
Andreas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to