Bug 944830

Summary: Very slow USB recognition
Product: [openSUSE] openSUSE Distribution Reporter: Ion Michaelides <ionmich>
Component: KernelAssignee: E-mail List <kernel-maintainers>
Status: RESOLVED NORESPONSE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: forgotten_628ByENQqP, ionmich, oneukum, opensuse.lietuviu.kalba, tiwai, zaitor
Version: Leap 42.1   
Target Milestone: ---   
Hardware: 64bit   
OS: openSUSE 42.1   
See Also: http://bugzilla.suse.com/show_bug.cgi?id=945094
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Commands executed as requested

Description Ion Michaelides 2015-09-08 12:55:26 UTC
Kingston USB3/2 stick not immediately recognized by openSUSE 13.2 64bit KDE running on desktop box OR on netbook. Steps taken to diagnose.

1. I booted a live Tumbleweed 64bit KDE DVD which I had downloaded about a month ago and have not bothered to use. This was on my 64bit daily used desktop box. Result-USB stick was incredibly slow to be recognized by Device Notifier or "fdisk -l".

2. I booted a live 13.2 32bit KDE DVD on the same desktop box. Result-USB stick was incredibly slow to be recognized by Device Notifier or "fdisk -l".

3. I booted my backup server which uses 13.1 32bit console-only installation. Result-USB stick was immediately recognized by "fdisk -l".

4. I booted a live 13.1 32bit KDE DVD on my 64bit daily used desktop box. Result-USB stick was immediately recognized by Device Notifier and "fdisk -l".

5. I booted a live 13.1 64bit KDE DVD on my 64bit daily used desktop box. Result (and I was surprised)-USB stick was immediately recognized by Device Notifier and "fdisk -l".

Conclusion - Problem lies with 13.2 not with Kingston.
Comment 1 Takashi Iwai 2015-09-08 13:13:41 UTC
Is this the result with the latest openSUSE-13.2 update kernel?  I guess the result is same because Tumbleweed has the same issue, but just to be sure.

If yes, try the latest Tumbleweed kernel (on top of the current user-space as is), also just to make sure.

And if this also fails, please give the output of dmesg after plugging the problematic USB stick, attach to Bugzilla.
Comment 2 Jiri Slaby 2015-11-20 12:27:01 UTC
Closing due to lack of response.
Comment 3 Forgotten User 628ByENQqP 2015-11-30 22:51:52 UTC
I'm experiencing this exact same thing with openSUSE 13.2 and Leap 42.1 and a Kingston DataTraveler USB3/2 64GB xfs formated, is very annoying, I'm not fancy of using Tumbleweed now on my work machines (both home laptop and office PC are used for work) so I can't install the latest kernel, just the latest kernel the standard distro (13.2/42.1) can provide

As of the dmesg output, here it is for openSUSE Leap:

[522494.739839] usb 2-2: new SuperSpeed USB device number 2 using xhci_hcd
[522494.854738] usb 2-2: New USB device found, idVendor=0951, idProduct=1666
[522494.854747] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[522494.854751] usb 2-2: Product: DataTraveler 3.0
[522494.854755] usb 2-2: Manufacturer: Kingston
[522494.854759] usb 2-2: SerialNumber: 08606E6D40B6BF21C7044440
[522495.072000] usb-storage 2-2:1.0: USB Mass Storage device detected
[522495.072272] scsi host4: usb-storage 2-2:1.0
[522495.072919] usbcore: registered new interface driver usb-storage
[522495.081172] usbcore: registered new interface driver uas
[522496.140659] scsi 4:0:0:0: Direct-Access     Kingston DataTraveler 3.0 PMAP PQ: 0 ANSI: 6
[522496.141099] sd 4:0:0:0: Attached scsi generic sg1 type 0
[522497.816205] sd 4:0:0:0: [sdb] 122915328 512-byte logical blocks: (62.9 GB/58.6 GiB)
[522497.816722] sd 4:0:0:0: [sdb] Write Protect is off
[522497.816725] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00
[522497.817274] sd 4:0:0:0: [sdb] No Caching mode page found
[522497.817278] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[522497.845210]  sdb: sdb1
[522497.846432] sd 4:0:0:0: [sdb] Attached SCSI removable disk
[522558.442312] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd
[522565.435859] XFS (sdb1): Mounting V4 Filesystem
[522566.117878] XFS (sdb1): Ending clean mount
Comment 4 Oliver Neukum 2015-12-01 09:20:06 UTC
(In reply to Raul Gomez from comment #3)
>
> [522497.817278] sd 4:0:0:0: [sdb] Assuming drive cache: write through
> [522497.845210]  sdb: sdb1
> [522497.846432] sd 4:0:0:0: [sdb] Attached SCSI removable disk
> [522558.442312] usb 2-2: reset SuperSpeed USB device number 2 using xhci_hcd

As you can see by the timing information, the device gets into some kind of error state, leading to a timeout and a subsequent reset. Unfortunately the log doesn't tell us, which command triggers the bad response. There are several candidates. Do you get a similar delay when you use "fdisk -l"?
Comment 5 Forgotten User 628ByENQqP 2015-12-01 18:25:33 UTC
Nope, fdisk -l finishes in 5ms approx.

Is there any work around for this?
Comment 6 Oliver Neukum 2015-12-02 08:16:10 UTC
(In reply to Raul Gomez from comment #5)
> Nope, fdisk -l finishes in 5ms approx.
> 
> Is there any work around for this?

The work around is to avoid the command that the device does not like. For that we need to find out which command is the problem. Could you run a kernel with CONFIF_USB_STORAGE_DEBUG set (e.g. the debug flavor)? It will show the commands going to the device in the log?
Comment 7 Mindaugas Baranauskas 2015-12-02 10:58:44 UTC
Your bug perhaps is dublicate of https://bugzilla.suse.com/show_bug.cgi?id=945094
Comment 8 Oliver Neukum 2015-12-02 11:33:03 UTC
(In reply to Mindaugas Baranauskas from comment #7)
> Your bug perhaps is dublicate of
> https://bugzilla.suse.com/show_bug.cgi?id=945094

Quite possible. Could you try out sg3_utils as used in 945094?
Comment 9 Forgotten User 628ByENQqP 2015-12-03 18:06:33 UTC
Created attachment 658296 [details]
Commands executed as requested

This attachment contains a log of the sg_utils commands requested as they where ran in the Bug 945094

https://bugzilla.suse.com/show_bug.cgi?id=945094
Comment 10 Forgotten User 628ByENQqP 2015-12-03 18:11:42 UTC
(In reply to Oliver Neukum from comment #6)
> (In reply to Raul Gomez from comment #5)
> > Nope, fdisk -l finishes in 5ms approx.
> > 
> > Is there any work around for this?
> 
> The work around is to avoid the command that the device does not like. For
> that we need to find out which command is the problem. Could you run a
> kernel with CONFIF_USB_STORAGE_DEBUG set (e.g. the debug flavor)? It will
> show the commands going to the device in the log?

Haven't had the time to try the debug Kernel, I'm planning to do this today

Thanks!
Comment 11 Oliver Neukum 2016-06-23 14:56:44 UTC
Closing due to lack of tester's response