On Tue, 8 May 2012, Jesse Feddema wrote: > Thanks a billion, the device is now actually working :). However, it > still generates quite a mess of errors in my dmesg, and seems slower > than it should be. The following logs show what happens when I > connect, mount, dd 1000 blocks from /dev/zero to a file on the device, > unmount, and then disconnect the device under the 3.4.0-rc6 kernel > patched with the patch you sent: > > ===== dmesg output ===== ... > [ 2233.576445] sd 17:0:0:0: [sdb] Unhandled error code > [ 2233.576455] sd 17:0:0:0: [sdb] Result: hostbyte=DID_ERROR > driverbyte=DRIVER_OK > [ 2233.576465] sd 17:0:0:0: [sdb] CDB: Write(10): 2a 00 00 05 f8 f8 00 00 f0 00 > [ 2233.576486] end_request: I/O error, dev sdb, sector 391416 > [ 2233.802570] sd 17:0:0:0: [sdb] Unhandled error code > [ 2233.802580] sd 17:0:0:0: [sdb] Result: hostbyte=DID_ERROR > driverbyte=DRIVER_OK > [ 2233.802589] sd 17:0:0:0: [sdb] CDB: Write(10): 2a 00 00 05 f9 e8 00 00 f0 00 > [ 2233.802610] end_request: I/O error, dev sdb, sector 391656 > [ 2234.611422] sd 17:0:0:0: [sdb] Unhandled error code > [ 2234.611432] sd 17:0:0:0: [sdb] Result: hostbyte=DID_ERROR > driverbyte=DRIVER_OK > [ 2234.611441] sd 17:0:0:0: [sdb] CDB: Write(10): 2a 00 00 05 fa d8 00 00 f0 00 > [ 2234.611462] end_request: I/O error, dev sdb, sector 391896 > [ 2234.841645] sd 17:0:0:0: [sdb] Unhandled error code > [ 2234.841654] sd 17:0:0:0: [sdb] Result: hostbyte=DID_ERROR > driverbyte=DRIVER_OK > [ 2234.841664] sd 17:0:0:0: [sdb] CDB: Write(10): 2a 00 00 05 fb c8 00 00 f0 00 > [ 2234.841687] end_request: I/O error, dev sdb, sector 392136 > [ 2244.533180] usb 2-1.1: USB disconnect, device number 15 > ===== end of dmesg output ===== > > I've also seen similar errors for reading, I think I can log them if > you like. The output of lsusb -vvv hasn't changed. The usbmon output > is available at http://pastebin.com/JSVAHDr1 (sorry for the size, but > smaller dd's didn't seem to trigger errors). I hope there's an easy > fix to these errors. If not, I think I can live with them :). Thanks > again for what you did already! This looks like another bug in the device; it can't transfer as much data in a single command as the computer requests. By default Linux sends or receives 120 KB at a time, but the device indicated that it wasn't able to handle more than 56 KB. The following patch adds a workaround for that problem; use it in place of the earlier patch. Alan Stern Index: usb-3.4/drivers/usb/storage/unusual_devs.h =================================================================== --- usb-3.4.orig/drivers/usb/storage/unusual_devs.h +++ usb-3.4/drivers/usb/storage/unusual_devs.h @@ -1885,6 +1885,13 @@ UNUSUAL_DEV( 0x1652, 0x6600, 0x0201, 0x USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_IGNORE_RESIDUE ), +/* Reported by Jesse Feddema <jdfeddema@xxxxxxxxx> */ +UNUSUAL_DEV( 0x177f, 0x0400, 0x0000, 0x0000, + "Yarvik", + "PMP400", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_BULK_IGNORE_TAG | US_FL_MAX_SECTORS_64 ), + /* Reported by Hans de Goede <hdegoede@xxxxxxxxxx> * These Appotech controllers are found in Picture Frames, they provide a * (buggy) emulation of a cdrom drive which contains the windows software -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
