Created attachment 109123 [details] mtp-detect log Brief description: after upgrading to Linux kernel 4.14 I cannot access my android device anymore via MTP using KDE. When I click on KDE's popup - I get message "The file or folder udi=/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:14.0/usb3/3-1 does not exist". It happens only with combination of: - 4.14 kernel; - KDE. When I switch back to kernel 4.13, I can mount device again. I also can access device via MTP with mtpfs command OR by using LXDE (and its default file manager and desktop) without any problems on the same system with kernel 4.14. So it looks like issue is purely related to KDE *and* Linux 4.14 "conflict". What I tried: - recompiled kernel, - tried vanilla-sources, - checked every new kernel option that was set during "make oldconfig", - recompiled kde-frameworks/solid-5.40.0, media-libs/libmtp-1.1.14 and sys-fs/mtpfs-1.1-r3, - recompiled all packages ("@world" in Gentoo) but no success so far. Also, there are people at manjaro forums complaining about the same issue: https://forum.manjaro.org/t/is-it-worth-upgrading-to-4-14-lts/35620/16 https://forum.manjaro.org/t/is-it-worth-upgrading-to-4-14-lts/35620/26
Created attachment 109124 [details] udevadm monitor log
I can confirm this behaviour under Manjaro stable. the package Android File Transfer works, accessing the device through Dolphin/Plasma does not work. inxi -Fx System: Host: manjamin-pc Kernel: 4.14.2-1-MANJARO x86_64 bits: 64 gcc: 7.2.0 Desktop: KDE Plasma 5.11.3 (Qt 5.9.2) Distro: Manjaro Linux Machine: Device: desktop Mobo: ASUSTeK model: Q170T v: Rev X.0x serial: N/A UEFI: American Megatrends v: 0215 date: 04/18/2016 CPU: Quad core Intel Core i5-6500TE (-MCP-) arch: Skylake-S rev.3 cache: 6144 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 18436 clock speeds: max: 3300 MHz 1: 2300 MHz 2: 2300 MHz 3: 2300 MHz 4: 2300 MHz Graphics: Card: Intel HD Graphics 530 bus-ID: 00:02.0 Display Server: x11 (X.Org 1.19.5 ) driver: intel Resolution: 1920x1080@50.00hz OpenGL: renderer: Mesa DRI Intel HD Graphics 530 (Skylake GT2) version: 4.5 Mesa 17.2.5 Direct Render: Yes Audio: Card Intel Sunrise Point-H HD Audio driver: snd_hda_intel bus-ID: 00:1f.3 Sound: Advanced Linux Sound Architecture v: k4.14.2-1-MANJARO Network: Card-1: Intel Ethernet Connection (2) I219-LM driver: e1000e v: 3.2.6-k bus-ID: 00:1f.6 IF: enp0s31f6 state: up speed: 100 Mbps duplex: full mac: 34:97:f6:8b:e1:a6 Card-2: Intel Wireless 7265 driver: iwlwifi bus-ID: 02:00.0 IF: wlp2s0 state: up mac: 60:57:18:73:95:5b Card-3: Realtek RTL8111/8168/8411 PCIE Gigabit Ethernet Controller driver: r8168 v: 8.044.02-NAPI port: e000 bus-ID: 04:00.0 IF: enp4s0 state: down mac: 34:97:f6:8b:e1:a7 Drives: HDD Total Size: 3756.7GB (74.2% used) ID-1: /dev/nvme0n1 model: SAMSUNG_MZVPV256HDGL size: 256.1GB ID-2: /dev/sda model: Samsung_SSD_850 size: 500.1GB ID-3: USB /dev/sdb model: Elements_25A2 size: 1000.2GB ID-4: USB /dev/sdc model: USB_2.0_Drive size: 1000.2GB ID-5: USB /dev/sdd model: Elements_10B8 size: 1000.2GB Partition: ID-1: / size: 39G used: 23G (62%) fs: ext4 dev: /dev/nvme0n1p3 ID-2: /home size: 119G used: 57G (51%) fs: ext4 dev: /dev/nvme0n1p5 Sensors: System Temperatures: cpu: 73.0C mobo: 29.8C Fan Speeds (in rpm): cpu: 0 Info: Processes: 225 Uptime: 1:37 Memory: 2773.6/15926.0MB Init: systemd Gcc sys: 7.2.0 Client: Shell (bash 4.4.121) inxi: 2.3.43
Created attachment 109171 [details] diff of /sys betweeen 4.11 and 4.14 I have a Slackware-based self compiled system, and I'm affected by the same issue. I have lurked the /sys filesystem, and I've found that the 4.14 device tree is "missing" a symlink to the usbfs (see attachment al line 109). I don't know how to check that solid or mtp do really use that file. Obviously, I wasn't able to create that symlink on 4.14 to see if it solves the issue neither delete it from 4.11. I'm available to do any test.
Problem pertains with Plasma 5.14.4 and Kernel 4.14.3. No problems when using last LTS Kernel (4.9.66). Last kernel version where it functioned was EOL 4.13 series.
KDE Apps 17.12, Linux 4.14.6, Solid 5.41 - still doesn't work with same error.
Hey! Now it works for me with the following configuration: Plasma 5.11.4, Kernel 4.14.5.1-MANJARO, Qt 5.9.3, Frameworks 5.40.0. If there is anything that I can provide to elucidate the issue further, let me know.
Doesn't work with the following configuration : Plasma 5.11.4, Kernel 4.14.10-2-MANJARO, Qt 5.10.0 , Frameworks 5.41.0
*** Bug 388347 has been marked as a duplicate of this bug. ***
Same issue here. Slackware Linux 14.2/-current with KDE 5.41.0 / Plasma 5.11.4. With Linux-4.14.12 i can not mount my mobile phone using mtp:/. Switching back to LTS-4.4.110 and everything is fine.
Created attachment 110188 [details] udevadm udevadmin monitor -p
I got this in Slackware64-current(15.0) KDE4.14.XX I read this thread and saw gentoo and slackware and it made me think that it might be eudev related. Is it so that all of us that has this problem use eudev? There was weltqgel that used systemd but since it was fixed later it might not have been the same problem it could as well have been the gvfs udev problem that appeared almost the same time. The error message, first is original in my native tongue and the second is translated by me. Filen eller katalogen udi=/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:10.0/usb3/3-2/ finns inte. File or catalog udi=/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:10.0/usb3/3-2/ doesn't exist. It does work for me in xfce if i use pcmanfm or in KDE if i use thunar to open the mtp device. I did try and bisect the kernel and got this result. git bisect bad 1455cf8dbfd06aa7651dcfccbadb7a093944ca65 is the first bad commit commit 1455cf8dbfd06aa7651dcfccbadb7a093944ca65 Author: Dmitry Torokhov <dmitry.torokhov@gmail.com> Date: Wed Jul 19 17:24:30 2017 -0700 driver core: emit uevents when device is bound to a driver There are certain touch controllers that may come up in either normal (application) or boot mode, depending on whether firmware/configuration is corrupted when they are powered on. In boot mode the kernel does not create input device instance (because it does not necessarily know the characteristics of the input device in question). Another number of controllers does not store firmware in a non-volatile memory, and they similarly need to have firmware loaded before input device instance is created. There are also other types of devices with similar behavior. There is a desire to be able to trigger firmware loading via udev, but it has to happen only when driver is bound to a physical device (i2c or spi). These udev actions can not use ADD events, as those happen too early, so we are introducing BIND and UNBIND events that are emitted at the right moment. Also, many drivers create additional driver-specific device attributes when binding to the device, to provide userspace with additional controls. The new events allow userspace to adjust these driver-specific attributes without worrying that they are not there yet. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> :040000 040000 fef96678b0a5ea8f89c41f006a3ccd013b4a36f4 34b72074bd6fab60bea1ec8066cf5ae9c600b37c M drivers :040000 040000 5657f6e76558ed4e14f17edabc6c602b93011d6d 1dbac2e41568c1638ea059fc8bc1afe8878353b8 M include :040000 040000 88854205d5255fbec438594cb3539e01c3610f82 54ad1fcb19ca64af9660e170ae0d7af186bd51ad M lib
(In reply to Nille from comment #11) > I got this in Slackware64-current(15.0) KDE4.14.XX > I read this thread and saw gentoo and slackware and it made me think that it > might be eudev related. > Is it so that all of us that has this problem use eudev? I have the same problem on Gentoo and I'm not using eudev. I have udev-236-r1. Kernel 4.15.1, Qt 5.9.4, KDE Frameworks 5.42.0, KDE Apps 17.12.1
(In reply to Nille from comment #11) > I got this in Slackware64-current(15.0) KDE4.14.XX > I read this thread and saw gentoo and slackware and it made me think that it > might be eudev related. > Is it so that all of us that has this problem use eudev? Nope, using Gentoo with systemd-236, kernel 4.14.14, KDE Frameworks 5.42.0 and KDE Apps 17.12.1
Still failing with kernel 4.14.18 and KDE frameworks 5.43.0
Broken with kernel-4.15.4, kde-frameworks-5.43, kdeapps-17.12.2
I can confirm this behaviour. breaks with same error. Broken on Gentoo (gentoo-sources-4.15.4, kde-frameworks/plasma-5.40.0, kde-apps/kde-apps-meta-17.08.3, kde-apps/dolphin-17.08.3, kde-frameworks/kio-5.40.0-r3) Installing and using xfce-base/thunar-1.6.13 is a successful workaround.
I can confirm the error too. Gentoo (gentoo-sources-4.14.29, kde-frameworks/plasma-5.44.0, kde-apps/dolphin-17.12.3, kde-frameworks/kio-5.44.0, media-libs/libmtp-1.1.15, sys-fs/mtpfs-1.1-r3)
Issue still exists with Kde-apps 18.04.0, kde-frameworks 5.45, gentoo-sources-4.14.43
I've fixed for myself. There weren't udev rules for Xiaomi in my Gentoo. Updating /etc/udev/rules.d/51-android.rules [I added 'SUBSYSTEM=="usb", ATTR{idVendor}=="2717", MODE="0666"] and /etc/udev/rules.d/69-libmtp.rules [ATTR{idVendor}=="2717", ATTR{idProduct}=="ff40", SYMLINK+="libmtp-%k", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1"] was enough to resolve problem
I found a different solution. It seems the udev rules for libmtp are broken with linux kernel 4.14+ No /dev/libmtp-* symlink is generated since then The first rule in the rules file (on my gentoo machine this is /lib64/udev/rules/69-libmtp.rules with libmtp 1.1.14 installed) ACTION!="add", GOTO="libmtp_rules_end" It seems that since linux kernel while the udev add action is active not all attributes (e.g. idvendor) are already setup The attributes seems to be all setup up in the bind udev action phase So after I copied the file to /etc/udev/rules and changed the line ACTION!="add", GOTO="libmtp_rules_end" to ACTION!="bind", GOTO="libmtp_rules_end" The symlink gets generated and I can access the storage on my smartphone again with dolphin
So is this an issue with the Kernel, then?
I quess not that is a kernel error. As stated in comment 11 the kernel (4.14+) now sends bind uvents when the driver gets bound to a physical device. It seems that the add uvents are now send earlier then before this change (when the device get plugged in). Before any device specific properties/attributes could be read. Before my change the /dev/libmtp* symlink was created when i ran udevadm test <path to usb device under dev> after the device was plugged in. The question is why can pcmanfm access the mtp device and dolphin (via solid) not. Does Solid depend on the /dev/libmtp* symlink? Or which information are needed to mark an usb device as mtp device by solid? Maybe solid depends on following two udev env variables? ENV{ID_MTP_DEVICE}="1" ENV{ID_MEDIA_PLAYER}="1" Those ENV vars get setup by the libmtp udev rules, which also setup the /dev/libmtp* symlink. Maybe pcmanfm doesn't depend on udev properties to access/mark a device as mtp device. It could directly query libmtp for available devices. And libmtp reports it correctly after the device was plugged in.
(In reply to Stephan Wezel from comment #20) > So after I copied the file to /etc/udev/rules and changed the line > ACTION!="add", GOTO="libmtp_rules_end" > > to > ACTION!="bind", GOTO="libmtp_rules_end" > > The symlink gets generated and I can access the storage on my smartphone > again with dolphin This does not work for me: all I get is a few log messages telling: apr 23 15:14:13 xxxxxx org_kde_powerdevil[19851]: UdevQt: unhandled device action "bind" apr 23 15:14:13 xxxxxx kdeinit5[19762]: UdevQt: unhandled device action "bind" apr 23 15:14:13 xxxxxx upowerd[819]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1
...and no new device notification popup.
(In reply to Paolo Pedroni from comment #23) > This does not work for me: all I get is a few log messages telling: > > apr 23 15:14:13 xxxxxx org_kde_powerdevil[19851]: UdevQt: unhandled device > action "bind" > apr 23 15:14:13 xxxxxx kdeinit5[19762]: UdevQt: unhandled device action > "bind" > apr 23 15:14:13 xxxxxx upowerd[819]: unhandled action 'bind' on > /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1 The warnings are unrelated. Those simply telling that the udev code used by those kde components doesn't support the new udev device action type "bind" (In reply to Paolo Pedroni from comment #24) > ...and no new device notification popup. Ah I had the same problem. After some playing around with the first rule I got it working. Now the first rule looks like this: ACTION!="bind", ACTION!="add" GOTO="libmtp_rules_end" Now the popup shows up again and still I can access the storage on the mtp device. It seems that the "add" ACTION must be still processed by the rules to have the device notification popup working. A second run for the "bind" ACTION is needed so that the newly plugged in device gets properly setup as mtp device (at least for solid)
Stephan's solution in #25 works for me. Kernel 4.16.0+, Qt 5.9.4, Plasma 5.12.3, Frameworks 5.44.0, eudev 3.2.5, libgudev 232
Confirm, Stephan's workaround (post #25) works for me too.
So whose responsibility is it for fixing this? Is this the kernel's problem or ours?
(In reply to Nate Graham from comment #28) > So whose responsibility is it for fixing this? Is this the kernel's problem > or ours? The kernel has a "never break userspace, even if userspace is broken" policy, so if brought to the attention of the kernel developers, there will likely be changes in the kernel. On the other hand, I don't think it is the best approach here - it may take weeks until a solution is found, if at all possible (improving handling of some devices *AND* not breaking userspace), and more weeks until it reaches distributions and users. The culprit is likely the missing handling of the "bind" action in solid/backends/shared/udev*.cpp (UdevQt) (which can likely be done by just emitting deviceChanged), *and* the missing handling of deviceChanged in solid/backends/devices/udev/udevmanager.cpp. The changes in UdevQt are trivial, but the changes in udevmanager are likely more evolved.
Hmm something is strange. The properties reported by udevadm monitor -p when i pluggin the device differs for the add and bind Action. For this test I have reverted my workaround. Here the output for those events UDEV [1721.426090] add /devices/pci0000:00/0000:00:14.0/usb3/3-12 (usb) ACTION=add BUSNUM=003 DEVLINKS=/dev/libmtp-3-12 DEVNAME=/dev/bus/usb/003/010 DEVNUM=010 DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-12 DEVTYPE=usb_device DRIVER=usb ID_BUS=usb ID_FOR_SEAT=usb-pci-0000_00_14_0-usb-0_12 ID_MEDIA_PLAYER=1 ID_MODEL=Xperia_Z3C ID_MODEL_ENC=Xperia\x20Z3C ID_MODEL_FROM_DATABASE=D5803 [Xperia Z3 Compact] (MTP mode) ID_MODEL_ID=01bb ID_MTP_DEVICE=1 ID_PATH=pci-0000:00:14.0-usb-0:12 ID_PATH_TAG=pci-0000_00_14_0-usb-0_12 ID_REVISION=0232 ID_SERIAL=Sony_Xperia_Z3C_YT911AT36D ID_SERIAL_SHORT=YT911AT36D ID_USB_INTERFACES=:ffff00: ID_VENDOR=Sony ID_VENDOR_ENC=Sony ID_VENDOR_FROM_DATABASE=Sony Ericsson Mobile Communications AB ID_VENDOR_ID=0fce MAJOR=189 MINOR=265 PRODUCT=fce/1bb/232 SEQNUM=2495 SUBSYSTEM=usb TAGS=:seat:uaccess: TYPE=0/0/0 USEC_INITIALIZED=1721409960 UDEV [1721.437162] bind /devices/pci0000:00/0000:00:14.0/usb3/3-12 (usb) ACTION=bind BUSNUM=003 DEVNAME=/dev/bus/usb/003/010 DEVNUM=010 DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-12 DEVTYPE=usb_device DRIVER=usb ID_BUS=usb ID_MODEL=Xperia_Z3C ID_MODEL_ENC=Xperia\x20Z3C ID_MODEL_FROM_DATABASE=D5803 [Xperia Z3 Compact] (MTP mode) ID_MODEL_ID=01bb ID_REVISION=0232 ID_SERIAL=Sony_Xperia_Z3C_YT911AT36D ID_SERIAL_SHORT=YT911AT36D ID_USB_INTERFACES=:ffff00: ID_VENDOR=Sony ID_VENDOR_ENC=Sony ID_VENDOR_FROM_DATABASE=Sony Ericsson Mobile Communications AB ID_VENDOR_ID=0fce MAJOR=189 MINOR=265 PRODUCT=fce/1bb/232 SEQNUM=2497 SUBSYSTEM=usb TYPE=0/0/0 USEC_INITIALIZED=1721409960 For the "add" action the DEVLINKS and the ID_MTP_DEVICE and ID_MEDIA_PLAYER are properly setup up But for the "bind" action those properties are missing. It seems that solid reacts on the "bind" action with the same (or similar) logic as the "add" action. Maybe it updates the stored properties for the plugged in device when the "bind" action event occures. Through this update the properties DEVLINKS, ID_MTP_DEVICE and ID_MEDIA_PLAYER gets removed. Otherwise I cannot understand why the "bind" action has an effect on how the newly plugged device is seen by solid Due my workaround those properties are also set for the "bind" action and so any update done to stored properties doesn't change anything. But it is also strange that the symlink (defined in the "add" action) is also not visible. AFAIK udev itself creates such symlinks when a rules specifies "SYMLINK+=" So it seems that udev self might remove the stored information about e.g. ID_MTP_DEVICE and also the symlink when the "bind" action occures when the properties differs from the "add" action It seems to be an udev/eudev bug. It handles the "bind" action as an "add/update" action For udev (under systemd umbrella) I found this bugreport: https://github.com/systemd/systemd/issues/8221
Created attachment 112244 [details] Hacked a patch together to have udev ignore bind/unbind events when handling rules Hacked a patch together to have udev ignore bind/unbind events when handling rules. This also fixes the problem. This change should also fix possible any other broken udev rules which reacts only on "add" ACTION
Thanks Stephan! Patches in Bugzilla tickets tend to get lost, so please submit your patch via Phabricator: http://phabricator.kde.org/ Here's the documentation: https://community.kde.org/Infrastructure/Phabricator
(In reply to Nate Graham from comment #32) > Thanks Stephan! Patches in Bugzilla tickets tend to get lost, so please > submit your patch via Phabricator: http://phabricator.kde.org/ > > Here's the documentation: > https://community.kde.org/Infrastructure/Phabricator The patch is not for a kde-framework component. It is for systemd-udev itself. I post it here mostly so that any other stumpling over this here can use it if wanted
Ah, then I'll just assume you're going to submit it to the right place! :)
For reference, the upstream bug report seems to be: https://github.com/systemd/systemd/issues/8221
Stephan's solution on #25 works.
looks like this bug (upstream) is not making progress.... I'm running kernel 4.18.5, and with the proposed workaround I get the error Could not read. Reason: I/O-Problem See https://bugs.kde.org/show_bug.cgi?id=395130
Fix is still needed in 4.18.10 and #25 solution still works.
This still hasn't been fixed in the Fedora 29 beta. For anyone else having this problem this is the fix: > $dnf install libmtp > $nano /lib/udev/rules.d/69-libmtp.rules And change > ACTION!="add", GOTO="libmtp_rules_end" to > ACTION!="bind", ACTION!="add", GOTO="libmtp_rules_end" And reboot
i released libmtp 1.1.16 with this fix included in its generated udev rules
For Sony Xperia XA2 (running Jolla Sailfish) I had to use the bind/add workaround, plus to add an entry for the device as follows: # SONY Xperia XA2 MTP ATTR{idVendor}=="0fce", ATTR{idProduct}=="0a07", SYMLINK+="libmtp-%k", MODE="660", GROUP="audio", ENV{ID_MTP_DEVICE}="1", ENV{ID_MEDIA_PLAYER}="1" Debian testing is still shipping libmpt 1.1.13, so it didn't get upstream fixes yet.
Confirmed in Fedora 29 stable. libmtp-1.1.16-1.fc29.x86_64 In /lib/udev/rules.d/69-libmtp.rules: ACTION!="add", ACTION!="bind", GOTO="libmtp_rules_end" ENV{MAJOR}!="?*", GOTO="libmtp_rules_end" SUBSYSTEM=="usb", GOTO="libmtp_usb_rules" GOTO="libmtp_rules_end" LABEL="libmtp_usb_rules" Still get the error.
I'm sorry I was wrong, seems to work now. Thanks.
*** Bug 395130 has been marked as a duplicate of this bug. ***
(In reply to Jordan Bradley from comment #39) > This still hasn't been fixed in the Fedora 29 beta. > > For anyone else having this problem this is the fix: > > > $dnf install libmtp > > $nano /lib/udev/rules.d/69-libmtp.rules > > And change > > > ACTION!="add", GOTO="libmtp_rules_end" > > to > > > ACTION!="bind", ACTION!="add", GOTO="libmtp_rules_end" > > And reboot
This worked for me > ACTION!="add", GOTO="libmtp_rules_end" to > ACTION!="bind", ACTION!="add", GOTO="libmtp_rules_end"