Bug 983813 - USB Drive not able to be accessed on F19, ok on F18
USB Drive not able to be accessed on F19, ok on F18
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-11 22:34 EDT by Darren Steven
Modified: 2013-10-08 12:56 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-08 12:56:24 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)
dmesg from upstream bugreport (32.48 KB, text/plain)
2013-07-26 05:55 EDT, Tomáš Bžatek
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 65785 None None None Never
Launchpad 1161985 None None None Never

  None (edit)
Description Darren Steven 2013-07-11 22:34:22 EDT
Description of problem:

I have 3 USB HDD, with WD scorpion, via a USB SATA bridge, with LUKS. On F18, these devices are recognised, and mounted in kde. In F19, the dmesg shows teh device detected, but hen there are messages about ATA PACKET DEVICE IDENTIFY TIMEOUTS. The drive light is flashing while this happens. Drives re-tested on F18, and accessible.


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

F19, latest updates


How reproducible:
100% on this host. many reports on other OS of similar issues with udisks2 suspected as culprit

Steps to Reproduce:
1. Install clean F19 x86_64
2. Plug USB drive
3. Observe drive detected in dmesg, then errors accessing

Actual results:
Drive identification fails

Expected results:
Drive identified, LUKS password requested etc

Additional info:

See https://bugs.launchpad.net/ubuntu/+source/libatasmart/+bug/1161985
Also various othe OS with similar problems

journalctl
Jul 12 12:27:08 dwsav.b-elab.com kernel: scsi 10:0:0:0: Direct-Access     WDC WD16 00BEVT-22ZCT0         PQ: 0 ANSI: 0
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: Attached scsi generic sg6 type 0
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] 312581808 512-byte logical blocks: (160 GB/149 GiB)
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] Write Protect is off
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] Mode Sense: 03 00 00 00
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] No Caching mode page present
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] Assuming drive cache: write through
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] No Caching mode page present
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] Assuming drive cache: write through
Jul 12 12:27:08 dwsav.b-elab.com kernel:  sdf: sdf1
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] No Caching mode page present
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] Assuming drive cache: write through
Jul 12 12:27:08 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] Attached SCSI disk
Jul 12 12:27:15 dwsav.b-elab.com kernel: usb 1-1.3: reset high-speed USB device number 5 using ehci-pci
Jul 12 12:27:15 dwsav.b-elab.com udisksd[1501]: Error probing device: Error sending ATA command IDENTIFY DEVICE to /dev/sdf: Unexpected sense data returned:
Jul 12 12:27:38 dwsav.b-elab.com systemd-udevd[251]: worker [3495] /devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/host10/target10:0:0/10:0:0:0/block/sdf/sdf1 timeout; k
Jul 12 12:27:38 dwsav.b-elab.com systemd-udevd[251]: seq 2350 '/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3/1-1.3:1.0/host10/target10:0:0/10:0:0:0/block/sdf/sdf1' killed
Jul 12 12:28:23 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] Unhandled sense code
Jul 12 12:28:23 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf]  
Jul 12 12:28:23 dwsav.b-elab.com systemd-udevd[251]: worker [3495] terminated by signal 9 (Killed)
Jul 12 12:28:23 dwsav.b-elab.com kernel: Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
Jul 12 12:28:23 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf]  
Jul 12 12:28:23 dwsav.b-elab.com kernel: Sense Key : Hardware Error [current] 
Jul 12 12:28:23 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf]  
Jul 12 12:28:23 dwsav.b-elab.com kernel: Add. Sense: No additional sense information
Jul 12 12:28:23 dwsav.b-elab.com kernel: sd 10:0:0:0: [sdf] CDB: 
Jul 12 12:28:23 dwsav.b-elab.com kernel: Read(10): 28 00 12 a1 8a af 00 00 08 00
Jul 12 12:28:23 dwsav.b-elab.com kernel: end_request: I/O error, dev sdf, sector 312576687
Jul 12 12:28:23 dwsav.b-elab.com kernel: quiet_error: 571 callbacks suppressed
Jul 12 12:28:23 dwsav.b-elab.com kernel: Buffer I/O error on device sdf1, logical block 156288312
Jul 12 12:28:23 dwsav.b-elab.com kernel: Buffer I/O error on device sdf1, logical block 156288313
Jul 12 12:28:23 dwsav.b-elab.com kernel: Buffer I/O error on device sdf1, logical block 156288314
Jul 12 12:28:23 dwsav.b-elab.com kernel: Buffer I/O error on device sdf1, logical block 156288315
Comment 1 Darren Steven 2013-07-22 23:38:23 EDT
OK, after googling a bit, this error appears for many users, on many distributions. One common factor is the SATA bridge in use:

Jul 12 10:22:40 dwsav.b-elab.com kernel: usb 2-1.8: Product: USB 2.0  SATA BRIDGE   
Jul 12 10:22:40 dwsav.b-elab.com kernel: usb 2-1.8: Manufacturer: Super Top   
Jul 12 10:22:40 dwsav.b-elab.com kernel: usb 2-1.8: SerialNumber: M6116018VF16

Directly plugging the drive into the host SATA ports, and all is well.

I suspect that something like libatasmart (although I disabled it for this usb device) or another thing that probes the device directly is upsetting it.
Comment 2 Tomáš Bžatek 2013-07-25 05:24:14 EDT
Upstream bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=64750
Comment 3 Tomáš Bžatek 2013-07-25 05:35:15 EDT
(In reply to Tomáš Bžatek from comment #2)
> Upstream bugreport: https://bugs.freedesktop.org/show_bug.cgi?id=64750

Correction, the actual bugreport is https://bugs.freedesktop.org/show_bug.cgi?id=65785
Comment 4 Tomáš Bžatek 2013-07-26 05:55:19 EDT
Created attachment 778724 [details]
dmesg from upstream bugreport

Reassigning to kernel and attaching dmesg excerpt from the upstream bugreport. Hopefully the errors reported are related to each other.
Comment 5 Josh Boyer 2013-09-18 16:53:02 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 6 Josh Boyer 2013-10-08 12:56:24 EDT
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.

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