This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 991676 - Assigning a device to a USB key takes more than 6 minutes
Assigning a device to a USB key takes more than 6 minutes
Status: CLOSED DUPLICATE of bug 989539
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-03 10:25 EDT by Christian Jodar
Modified: 2013-08-15 08:48 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-15 08:48:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christian Jodar 2013-08-03 10:25:39 EDT
Description of problem:

When connecting a USB key, it doesn't get a device (/dev/sdbX) before many minutes. Until then, it's not possible to mount it manually.

No automount done as well. But it may be related to the same problem.

Version-Release number of selected component (if applicable):

$ uname -a
Linux tianbox 3.10.4-300.fc19.x86_64 #1 SMP Tue Jul 30 11:29:05 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Thank you in advance for any help, as this is quite annoying.

How reproducible:

I tried with different USB keys and I got the same result.

Steps to Reproduce:
1. Plug the USB key
2. Check if there is a device corresponding to it -> No
3. Wait several minutes
4. Check again -> Yes
5. Manual mount required

Actual results:

The process took much longer than expected.

Expected results:

It should be faster. It should also be automatically mounted somewhere on the file system.

Additional info:

It was working fine with F18. I did an upgrade to F19, using fedup. I have this problem since then.

Here is what I see in /var/log/messages when I tested. The key is not accessible until the end of what is shown here.



Aug  4 00:04:40 tianbox kernel: [ 1114.026019] usb 1-4: new high-speed USB device number 4 using ehci-pci
Aug  4 00:04:40 tianbox kernel: [ 1114.143554] usb 1-4: New USB device found, idVendor=054c, idProduct=02a5
Aug  4 00:04:40 tianbox kernel: [ 1114.143557] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug  4 00:04:40 tianbox kernel: [ 1114.143560] usb 1-4: Product: Storage Media
Aug  4 00:04:40 tianbox kernel: [ 1114.143563] usb 1-4: Manufacturer: Sony
Aug  4 00:04:40 tianbox kernel: [ 1114.143565] usb 1-4: SerialNumber: 1A080131B0223
Aug  4 00:04:40 tianbox kernel: [ 1114.145078] usb-storage 1-4:1.0: USB Mass Storage device detected
Aug  4 00:04:40 tianbox kernel: [ 1114.145132] scsi7 : usb-storage 1-4:1.0
Aug  4 00:04:40 tianbox mtp-probe: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-4"
Aug  4 00:04:40 tianbox mtp-probe: bus: 1, device: 4 was not an MTP device
Aug  4 00:04:41 tianbox kernel: [ 1115.148200] scsi 7:0:0:0: Direct-Access     Sony     Storage Media    0100 PQ: 0 ANSI: 
0 CCS
Aug  4 00:04:41 tianbox kernel: [ 1115.148701] sd 7:0:0:0: Attached scsi generic sg2 type 0
Aug  4 00:04:41 tianbox kernel: [ 1115.150689] sd 7:0:0:0: [sdb] 15857664 512-byte logical blocks: (8.11 GB/7.56 GiB)
Aug  4 00:04:41 tianbox kernel: [ 1115.151811] sd 7:0:0:0: [sdb] Write Protect is off
Aug  4 00:04:41 tianbox kernel: [ 1115.152934] sd 7:0:0:0: [sdb] No Caching mode page present
Aug  4 00:04:41 tianbox kernel: [ 1115.152938] sd 7:0:0:0: [sdb] Assuming drive cache: write through
Aug  4 00:05:12 tianbox kernel: [ 1145.829020] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:05:43 tianbox kernel: [ 1176.901023] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:06:14 tianbox kernel: [ 1207.877028] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:06:45 tianbox kernel: [ 1238.853022] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:06:45 tianbox kernel: [ 1238.973581] sd 7:0:0:0: [sdb] No Caching mode page present
Aug  4 00:06:45 tianbox kernel: [ 1238.973585] sd 7:0:0:0: [sdb] Assuming drive cache: write through
Aug  4 00:07:16 tianbox kernel: [ 1269.829019] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:07:46 tianbox kernel: [ 1300.805021] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:08:18 tianbox kernel: [ 1331.909019] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:08:49 tianbox kernel: [ 1362.885022] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:08:49 tianbox kernel: [ 1363.074995]  sdb: sdb1
Aug  4 00:08:49 tianbox kernel: [ 1363.078730] sd 7:0:0:0: [sdb] No Caching mode page present
Aug  4 00:08:49 tianbox kernel: [ 1363.078735] sd 7:0:0:0: [sdb] Assuming drive cache: write through
Aug  4 00:09:19 tianbox systemd-udevd[351]: worker [2787] /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4:1.0/host7/target7:0:0/7:0:0:0/block/sdb timeout; kill it
Aug  4 00:09:19 tianbox systemd-udevd[351]: seq 2027 '/devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4:1.0/host7/target7:0:0/7:0:0:0/block/sdb' killed
Aug  4 00:09:20 tianbox kernel: [ 1393.861024] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:09:49 tianbox systemd-udevd[351]: worker [2788] /devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4:1.0/host7/target7:0:0/7:0:0:0/block/sdb/sdb1 timeout; kill it
Aug  4 00:09:49 tianbox systemd-udevd[351]: seq 2028 '/devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4:1.0/host7/target7:0:0/7:0:0:0/block/sdb/sdb1' killed
Aug  4 00:09:51 tianbox kernel: [ 1424.837022] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:10:16 tianbox dbus-daemon[528]: dbus[528]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
Aug  4 00:10:16 tianbox dbus[528]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'
Aug  4 00:10:16 tianbox systemd[1]: Cannot add dependency job for unit mdmonitor-takeover.service, ignoring: Unit mdmonitor-takeover.service failed to load: No such file or directory. See system logs and 'systemctl status mdmonitor-takeover.service' for details.
Aug  4 00:10:16 tianbox systemd[1]: Starting Fingerprint Authentication Daemon...
Aug  4 00:10:16 tianbox dbus-daemon[528]: dbus[528]: [system] Successfully activated service 'net.reactivated.Fprint'
Aug  4 00:10:16 tianbox dbus[528]: [system] Successfully activated service 'net.reactivated.Fprint'
Aug  4 00:10:16 tianbox systemd[1]: Started Fingerprint Authentication Daemon.
Aug  4 00:10:16 tianbox fprintd[2791]: Launching FprintObject
Aug  4 00:10:16 tianbox fprintd[2791]: ** Message: D-Bus service launched with name: net.reactivated.Fprint
Aug  4 00:10:16 tianbox fprintd[2791]: ** Message: entering main loop
Aug  4 00:10:19 tianbox su: (to tian) tian on none
Aug  4 00:10:21 tianbox kernel: [ 1455.813020] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:10:47 tianbox fprintd[2791]: ** Message: No devices in use, exit
Aug  4 00:10:53 tianbox kernel: [ 1486.917024] usb 1-4: reset high-speed USB device number 4 using ehci-pci
Aug  4 00:10:53 tianbox kernel: [ 1487.033759] sd 7:0:0:0: [sdb] Attached SCSI removable disk
Aug  4 00:10:53 tianbox systemd-udevd[351]: worker [2787] terminated by signal 9 (Killed)
Aug  4 00:10:53 tianbox systemd-udevd[351]: worker [2788] terminated by signal 9 (Killed)
Comment 1 Simone Sclavi 2013-08-11 15:13:44 EDT
I confirm this bug. I've a TOSHIBA External USB 3.0 1TB, it worked perfectly with kernel 3.9.X
After upgrading to kernel 3.10.4 I'm experiencing the same behaviour as reported by Christian. It takes several minutes before the device get recognised and I've to mount it manually.
The bug is still present with kernel 3.10.5-201.
Sorry for my bad English.
Comment 2 Simone Sclavi 2013-08-12 03:44:34 EDT
There's already a patch upstream: https://bugzilla.kernel.org/show_bug.cgi?id=60664
Comment 3 Josh Boyer 2013-08-15 08:48:40 EDT

*** This bug has been marked as a duplicate of bug 989539 ***

Note You need to log in before you can comment on or make changes to this bug.