On Thu, 4 May 2017, Andreas Hartmann wrote: > 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. I don't know what you mean by "deactivated". During a rescan the kernel checks the card reader to see what sort of device it is, whether any card is present, how the card is partitioned, and so on. > >> 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. But I don't know what the GUI is doing. So I can't tell what's going wrong. > >> 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 Is there any difference if you do the unmount and the echo manually, instead of using the GUI? > 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. How would that work with the card reader? You can't replug it because it's built in. > Iow: the echo 1 > /sys/block/sdh/device/delete is missing or gets > "overwritten" by the rescan. It probably is not missing. I don't know what causes the rescan to happen. But then, I also don't know how your system would normally tell when a new card was inserted after writing to /sys/block/sdh/device/delete. Maybe the GUI writes to /sys/class/scsi_host/hostN/scan, with the appropriate value for N. > > 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. It is possible to deconfigure the card reader and then reconfigure it: (first do the unmount) echo 0 >/sys/bus/usb/devices/1-1.1/bConfigurationValue (remove the card and insert a new one) echo 1 >/sys/bus/usb/devices/1-1.1/bConfigurationValue Probably this issue could be fixed by changing the way the driver implements TEST UNIT READY. But since I don't know how the card reader works, I don't know how to make the necessary changes. Maybe the person who originally wrote this driver can help. 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
