It seems to me that the USB device "14cd:6116" shows different
failure modes depending on the bcdDevice number (release number),
the number for my problematic device is "1.50", but others seem to
be also problematic.
Killing all "udisks" processes (all that show up from "ps fax|grep udisk")
helps to be able to mount the disk and use it, but I seems that when
a process "/usr/lib/udisks2/udisksd --no-debug" is running again
(started by some under the hood mechanism that I was not aware
of, when using KDE program gwenview to access the disk), then
the disk is again going into failure mode.
Downgrading the udisks2 package as described above leads to a
situation where even such a "/usr/lib/udisks2/udisksd --no-debug"
process running does not put the disk into failure mode.
I did not test with the regular udisks processes running though,
because I do not know how to restart them properly.
Regards
Simon
below:
* dmesg of the problem with comments
* lsusb -vvv -d 14cd:6116
dmesg, with comments:
Note that I run the module usb_storage with delay_use=5
(sudo modprobe usb_storage delay_use=5), from an earlier attempt to
fix the problem.
plugging, having killed all instances of "udisks" processes prior:
[16596.788460] usb 2-5: new high-speed USB device number 13 using ehci-pci
[16596.921661] usb 2-5: New USB device found, idVendor=14cd, idProduct=6116
[16596.921673] usb 2-5: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[16596.921681] usb 2-5: Product: USB 2.0 SATA BRIDGE
[16596.921687] usb 2-5: Manufacturer: Super Top
[16596.921693] usb 2-5: SerialNumber: M6116018VE15
[16596.922963] ums-cypress 2-5:1.0: USB Mass Storage device detected
[16596.924248] scsi15 : usb-storage 2-5:1.0
[16601.933622] scsi 15:0:0:0: Direct-Access FUJITSU MHV2100BH PL PQ: 0 ANSI: 0
[16601.934260] sd 15:0:0:0: Attached scsi generic sg2 type 0
[16601.942260] sd 15:0:0:0: [sdb] 195371568 512-byte logical blocks: (100 GB/93.1 GiB)
[16601.943869] sd 15:0:0:0: [sdb] Write Protect is off
[16601.943880] sd 15:0:0:0: [sdb] Mode Sense: 03 00 00 00
[16601.944466] sd 15:0:0:0: [sdb] No Caching mode page found
[16601.944470] sd 15:0:0:0: [sdb] Assuming drive cache: write through
[16601.946860] sd 15:0:0:0: [sdb] No Caching mode page found
[16601.946864] sd 15:0:0:0: [sdb] Assuming drive cache: write through
[16602.020545] sdb: sdb1
[16602.022864] sd 15:0:0:0: [sdb] No Caching mode page found
[16602.022869] sd 15:0:0:0: [sdb] Assuming drive cache: write through
[16602.022873] sd 15:0:0:0: [sdb] Attached SCSI disk
since I did kill the "udisks" processes/daemons before, I was now able to mount the
disk manually, an use it
[22828.940082] usb 2-5: reset high-speed USB device number 13 using ehci-pci
I decided to run the KDE program gwenview and have it access the disk.
This put the disk back into a failure mode, as seen below. I checked
and observed that there was again a "udisks" process running,
"/usr/lib/udisks2/udisksd --no-debug" if I remember right.
Hi all,
I seem to also be affected. I know that I used to have no problems with
the enclosure (lsusb details below), but nowadays in Ubuntu I get
the errors.
Searching google for 14cd:6116 gives several error reports from different /launchpad. net/bugs/ 1176355 and /launchpad. net/bugs/ 1082215.
distributions etc., also it looks similar to
launchpad bug https:/
maybe https:/
It seems to me that the USB device "14cd:6116" shows different
failure modes depending on the bcdDevice number (release number),
the number for my problematic device is "1.50", but others seem to
be also problematic.
Killing all "udisks" processes (all that show up from "ps fax|grep udisk") udisks2/ udisksd --no-debug" is running again udisks2/ udisksd --no-debug"
helps to be able to mount the disk and use it, but I seems that when
a process "/usr/lib/
(started by some under the hood mechanism that I was not aware
of, when using KDE program gwenview to access the disk), then
the disk is again going into failure mode.
Downgrading the udisks2 package as described above leads to a
situation where even such a "/usr/lib/
process running does not put the disk into failure mode.
I did not test with the regular udisks processes running though,
because I do not know how to restart them properly.
Regards
Simon
below:
* dmesg of the problem with comments
* lsusb -vvv -d 14cd:6116
dmesg, with comments:
Note that I run the module usb_storage with delay_use=5
(sudo modprobe usb_storage delay_use=5), from an earlier attempt to
fix the problem.
plugging, having killed all instances of "udisks" processes prior:
[16596.788460] usb 2-5: new high-speed USB device number 13 using ehci-pci
[16596.921661] usb 2-5: New USB device found, idVendor=14cd, idProduct=6116
[16596.921673] usb 2-5: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[16596.921681] usb 2-5: Product: USB 2.0 SATA BRIDGE
[16596.921687] usb 2-5: Manufacturer: Super Top
[16596.921693] usb 2-5: SerialNumber: M6116018VE15
[16596.922963] ums-cypress 2-5:1.0: USB Mass Storage device detected
[16596.924248] scsi15 : usb-storage 2-5:1.0
[16601.933622] scsi 15:0:0:0: Direct-Access FUJITSU MHV2100BH PL PQ: 0 ANSI: 0
[16601.934260] sd 15:0:0:0: Attached scsi generic sg2 type 0
[16601.942260] sd 15:0:0:0: [sdb] 195371568 512-byte logical blocks: (100 GB/93.1 GiB)
[16601.943869] sd 15:0:0:0: [sdb] Write Protect is off
[16601.943880] sd 15:0:0:0: [sdb] Mode Sense: 03 00 00 00
[16601.944466] sd 15:0:0:0: [sdb] No Caching mode page found
[16601.944470] sd 15:0:0:0: [sdb] Assuming drive cache: write through
[16601.946860] sd 15:0:0:0: [sdb] No Caching mode page found
[16601.946864] sd 15:0:0:0: [sdb] Assuming drive cache: write through
[16602.020545] sdb: sdb1
[16602.022864] sd 15:0:0:0: [sdb] No Caching mode page found
[16602.022869] sd 15:0:0:0: [sdb] Assuming drive cache: write through
[16602.022873] sd 15:0:0:0: [sdb] Attached SCSI disk
since I did kill the "udisks" processes/daemons before, I was now able to mount the
disk manually, an use it
[22828.940082] usb 2-5: reset high-speed USB device number 13 using ehci-pci
I decided to run the KDE program gwenview and have it access the disk. udisks2/ udisksd --no-debug" if I remember right.
This put the disk back into a failure mode, as seen below. I checked
and observed that there was again a "udisks" process running,
"/usr/lib/
[22885.448597] sd 15:0:0:0: [sdb] Unhandled sense code DRIVER_ SENSE DRIVER_ SENSE DRIVER_ SENSE DRIVER_ SENSE
[22885.448605] sd 15:0:0:0: [sdb]
[22885.448608] Result: hostbyte=DID_OK driverbyte=
[22885.448612] sd 15:0:0:0: [sdb]
[22885.448615] Sense Key : Medium Error [current]
[22885.448621] sd 15:0:0:0: [sdb]
[22885.448625] Add. Sense: Unrecovered read error
[22885.448634] sd 15:0:0:0: [sdb] CDB:
[22885.448636] Read(10): 28 00 09 68 e5 7f 00 00 f0 00
[22885.448650] blk_update_request: 407 callbacks suppressed
[22885.448652] end_request: critical target error, dev sdb, sector 157869439
[22885.448657] quiet_error: 548 callbacks suppressed
[22885.448660] Buffer I/O error on device sdb1, logical block 19733672
[22885.448669] Buffer I/O error on device sdb1, logical block 19733673
[22885.448673] Buffer I/O error on device sdb1, logical block 19733674
[22885.448676] Buffer I/O error on device sdb1, logical block 19733675
[22885.448679] Buffer I/O error on device sdb1, logical block 19733676
[22885.448683] Buffer I/O error on device sdb1, logical block 19733677
[22885.448686] Buffer I/O error on device sdb1, logical block 19733678
[22885.448689] Buffer I/O error on device sdb1, logical block 19733679
[22885.448692] Buffer I/O error on device sdb1, logical block 19733680
[22885.448696] Buffer I/O error on device sdb1, logical block 19733681
[22885.460127] sd 15:0:0:0: [sdb] Unhandled sense code
[22885.460133] sd 15:0:0:0: [sdb]
[22885.460137] Result: hostbyte=DID_OK driverbyte=
[22885.460141] sd 15:0:0:0: [sdb]
[22885.460144] Sense Key : Medium Error [current]
[22885.460149] sd 15:0:0:0: [sdb]
[22885.460153] Add. Sense: Unrecovered read error
[22885.460157] sd 15:0:0:0: [sdb] CDB:
[22885.460159] Read(10): 28 00 09 68 e6 6f 00 00 f0 00
[22885.460175] end_request: critical target error, dev sdb, sector 157869679
[22885.468108] sd 15:0:0:0: [sdb] Unhandled sense code
[22885.468113] sd 15:0:0:0: [sdb]
[22885.468117] Result: hostbyte=DID_OK driverbyte=
[22885.468120] sd 15:0:0:0: [sdb]
[22885.468123] Sense Key : Medium Error [current]
[22885.468128] sd 15:0:0:0: [sdb]
[22885.468132] Add. Sense: Unrecovered read error
[22885.468136] sd 15:0:0:0: [sdb] CDB:
[22885.468138] Read(10): 28 00 09 68 e7 5f 00 00 20 00
[22885.468151] end_request: critical target error, dev sdb, sector 157869919
[22885.475979] sd 15:0:0:0: [sdb] Unhandled sense code
[22885.475985] sd 15:0:0:0: [sdb]
[22885.475988] Result: hostbyte=DID_OK driverbyte=
[22885.475991] sd 15:0:0:0: [sdb]
[22885.475999] Sense Key : Medium Error [current]
[22885.476010] sd 15:0:0:0: [sdb]
[22885.476012] Add. Sense: Unrecovered read error
[22885.476014] sd 15:0:0:0: [sdb] CDB:
[22885.476015] Read(10): 28 00 09 68 e5 7f 00 00 08 00
... and so on and so forth ...
... the communication to the disk at this point is dead, only option is to
unplug the cable...
When I downgraded udisks as described above, using the package from
www.ubuntuupda tes.org/ package/ core/quantal/ main/base/ udisks2
then I did not observe the problem when running gwenview on the disk, udisks2/ udisksd --no-debug" process is running again.
even though a "/usr/lib/
lsusb of the drive enclosure:
Bus 002 Device 014: ID 14cd:6116 Super Top M6116 SATA Bridge tions 1 ionValue 1 orType 4 eNumber 0 eSetting 0 eClass 8 Mass Storage eSubClass 6 SCSI eProtocol 80 Bulk-Only
bDescriptorTyp e 5
bEndpointAddre ss 0x81 EP 1 IN
bmAttributes 2
wMaxPacketSize 0x0200 1x 512 bytes
bDescriptorTyp e 5
bEndpointAddre ss 0x02 EP 2 OUT
bmAttributes 2
wMaxPacketSize 0x0200 1x 512 bytes tions 1
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x14cd Super Top
idProduct 0x6116 M6116 SATA Bridge
bcdDevice 1.50
iManufacturer 1 Super Top
iProduct 3 USB 2.0 SATA BRIDGE
iSerial 2 M6116018VE15
bNumConfigura
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurat
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 2mA
Interface Descriptor:
bLength 9
bDescript
bInterfac
bAlternat
bNumEndpoints 2
bInterfac
bInterfac
bInterfac
iInterface 0
Endpoint Descriptor:
bLength 7
Transfer Type Bulk
Synch Type None
Usage Type Data
bInterval 0
Endpoint Descriptor:
bLength 7
Transfer Type Bulk
Synch Type None
Usage Type Data
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigura
Device Status: 0x0001
Self Powered