Bug 402096 - Removing memory card causes device to disappear from the system.
Summary: Removing memory card causes device to disappear from the system.
Status: RESOLVED FIXED
Alias: None
Product: frameworks-solid
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.53.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Lukáš Tinkl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-13 15:40 UTC by S.Trzmiel
Modified: 2019-01-02 14:51 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.54


Attachments
udev info of SDCard (1.04 KB, text/plain)
2018-12-13 17:51 UTC, S.Trzmiel
Details
udev info of SDcard partition 1 of 1 (1.90 KB, text/plain)
2018-12-13 17:51 UTC, S.Trzmiel
Details
udisk mmcblk0 info (1.29 KB, text/x-log)
2019-01-01 15:54 UTC, S.Trzmiel
Details
udisk SU02G info (1.24 KB, text/x-log)
2019-01-01 15:57 UTC, S.Trzmiel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description S.Trzmiel 2018-12-13 15:40:51 UTC
SUMMARY
Removing memory card via device notifier/Dolphin causes card reader device disappear from the system, thus card reader cannot be used again untill reboot/usb port reset/physical reconnection of the device (hard do to when device is build in into your computer/laptop ;)).


On system with card-reader
STEPS TO REPRODUCE
1. Insert memory  into the reader.
2. Mount it and browse its content
3. Remove card via device notifier/nontext menu of card in file browser:places

OBSERVED RESULT
Memory card disappears from the device notifier/filebrowser:places
Card reader dissapears from list of usb devices (lsusb output)
There's no reaction if card is removed/inserted again.


EXPECTED RESULT
Memory card disapears from device notifier/filebrowser:places or goes to unmouned state.
lsusb still lists Card reader
Device notifier reacts to card reinsertion.


SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Fedora 29
KDE Plasma Version: 5.14.4
KDE Frameworks Version: 5.52
Qt Version: 5.11.1

ADDITIONAL INFORMATION
I guess it happens because action used to do so is 'safe removal' that powers down the device. So I suppose 'eject' action should be used instead

output of lsusb before card is safely removed:
Bus 002 Device 003: ID 8087:07da Intel Corp. 
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 1bcf:2895 Sunplus Innovation Technology Inc. 
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 046d:0802 Logitech, Inc. Webcam C200
Bus 003 Device 003: ID 0461:4d62 Primax Electronics, Ltd HP Laser Mobile Mini Mouse
Bus 003 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

and after safe removal

Bus 002 Device 003: ID 8087:07da Intel Corp. 
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 1bcf:2895 Sunplus Innovation Technology Inc. 
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 046d:0802 Logitech, Inc. Webcam C200
Bus 003 Device 003: ID 0461:4d62 Primax Electronics, Ltd HP Laser Mobile Mini Mouse
Bus 003 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Comment 1 Kai Uwe Broulik 2018-12-13 16:42:28 UTC
It is probably powered down by Solid because people wanted us to power down external hard drives...
Comment 2 S.Trzmiel 2018-12-13 16:47:14 UTC
(In reply to Kai Uwe Broulik from comment #1)
> It is probably powered down by Solid because people wanted us to power down
> external hard drives...

I guess so, would it be possible to offer different actions for different media types?
Ie 'safe removal' for external hard drives/pendrives and 'eject' for memory cards?
Comment 3 Stefan Brüns 2018-12-13 17:33:22 UTC
Hardware vendors are unfortunately to dumb to properly implement standards ...

Therefor, UDisks adds a list of quirks for known devices.

Try adding a file "/etc/udev/rules.d/80-udisks2-local.rule" with the following contents to your system:
--- >8 ---
SUBSYSTEMS=="usb", ENV{ID_VENDOR_ID}=="0bda",ENV{ID_MODEL_ID}=="0129", ENV{ID_DRIVE_FLASH_CF}="1"
--- 8< ---

Also please provide the output of the following commands:
$> udevadm info -n /dev/sdX > /tmp/udev_info_sdX.txt
$> udevadm info -n /dev/sdXN > /tmp/udev_info_sdXN.txt

replace sdX with the correct device name for your card reader, e.g. sdb, sdc ...
replace N in sdXN with the number(s) of the partitions.
Comment 4 S.Trzmiel 2018-12-13 17:51:27 UTC
Created attachment 116902 [details]
udev info of SDCard
Comment 5 S.Trzmiel 2018-12-13 17:51:55 UTC
Created attachment 116903 [details]
udev info of SDcard partition 1 of 1
Comment 6 S.Trzmiel 2018-12-13 18:12:46 UTC
(In reply to Stefan Brüns from comment #3)
> Hardware vendors are unfortunately to dumb to properly implement standards
> ...
> 
> Therefor, UDisks adds a list of quirks for known devices.
> 
> Try adding a file "/etc/udev/rules.d/80-udisks2-local.rule" with the
> following contents to your system:
> --- >8 ---
> SUBSYSTEMS=="usb", ENV{ID_VENDOR_ID}=="0bda",ENV{ID_MODEL_ID}=="0129",
> ENV{ID_DRIVE_FLASH_CF}="1"
> --- 8< ---
> 
> Also please provide the output of the following commands:
> $> udevadm info -n /dev/sdX > /tmp/udev_info_sdX.txt
> $> udevadm info -n /dev/sdXN > /tmp/udev_info_sdXN.txt
> 
> replace sdX with the correct device name for your card reader, e.g. sdb, sdc
> ...
> replace N in sdXN with the number(s) of the partitions.

udevdm output provided. I've created udev rule, even rebooted OS to be sure it's loaded (most likely unnessesary) but it made no difference, removing SDcard still power downs the reader

Right now it loks like this:

#--- >8 ---
SUBSYSTEMS=="usb", ENV{ID_VENDOR_ID}=="0bda",ENV{ID_MODEL_ID}=="0129", ENV{ID_DRIVE_FLASH_CF}="1"
#--- 8< ---

I've tried with header footer/commented out, not commented and not present, still no difference
Comment 7 Bug Janitor Service 2018-12-28 03:44:31 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 8 S.Trzmiel 2018-12-28 13:10:02 UTC
As posted above, workaround didn't make a difference, udevadm output provided as attachements.
Comment 9 Stefan Brüns 2018-12-29 17:42:21 UTC
The malfunction is likely caused by the device identifying itself as a MMC block device, contrary to the typical USB cardreader using the SCSI/SATA command set.

Can you provide the output of:
$> udisksctl info -b /dev/mmcblk0
$> udisksctl info -d FooBar

Replace FooBar with the value from the block device "Drive" property, like:
$> udisksctl info -b /dev/sdb | grep Drive
    Drive:                      '/org/freedesktop/UDisks2/drives/FooBar'
Comment 10 S.Trzmiel 2019-01-01 15:54:12 UTC
Created attachment 117229 [details]
udisk mmcblk0 info

output of  udisksctl info -b /dev/mmcblk0
Comment 11 S.Trzmiel 2019-01-01 15:57:04 UTC
Created attachment 117230 [details]
udisk SU02G info

output of udisksctl info -d SU02G_0x0eea8c36
Comment 12 S.Trzmiel 2019-01-01 15:58:05 UTC
Requested info provided