Bug 208081 - JMicron 20329 USB to ATA/ATAPI Bridge error
Summary: JMicron 20329 USB to ATA/ATAPI Bridge error
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-17 11:02 UTC by Sylvain Garrigues
Modified: 2016-03-17 12:09 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvain Garrigues 2016-03-17 11:02:24 UTC
Hello,

My USB drive is recognized by FreeBSD but it cannot find partitions on it.

The error message (in /var/log/messages) is:

usbd_set_config_index: could not read device status: USB_ERR_SHORT_XFER
ugen7.2: <JMicron> at usbus7
umass0: <MSC Bulk-Only Transfer> on usbus7
umass0:  SCSI over Bulk-Only; quirks = 0x4080
umass0:5:0: Attached to scbus5
da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
da0: <SAMSUNG HM320JX > Fixed Direct Access SCSI-2 device
da0: Serial Number 32291B141A84
da0: 40.000MB/s transfers
da0: 305245MB (625142448 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

Here are some info:
# usbconfig -u 7 -a 2 dump_device_desc
ugen7.2: <USB to ATAATAPI Bridge JMicron> at usbus7, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (2mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x152d 
  idProduct = 0x2329 
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  <JMicron>
  iProduct = 0x0002  <USB to ATA/ATAPI Bridge>
  iSerialNumber = 0x0005  <32291B141A84>
  bNumConfigurations = 0x0001 


I tried adding some quirks (see patch below) but it doesn't work either.

The drive is recognized under Mac OS or Windows.

Any help?


Index: sys/dev/usb/quirk/usb_quirk.c
===================================================================
--- sys/dev/usb/quirk/usb_quirk.c	(revision 296946)
+++ sys/dev/usb/quirk/usb_quirk.c	(working copy)
@@ -239,6 +239,10 @@
 	USB_QUIRK(IOMEGA, ZIP100, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB,
 	    UQ_MSC_FORCE_PROTO_SCSI,
 	    UQ_MSC_NO_TEST_UNIT_READY), /* XXX ZIP drives can also use ATAPI */
+	USB_QUIRK(JMICRON, JM20329, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB,
+	    UQ_MSC_FORCE_PROTO_SCSI,
+	    UQ_MSC_IGNORE_RESIDUE,
+	    UQ_MSC_NO_SYNC_CACHE),
 	USB_QUIRK(JMICRON, JM20337, 0x0000, 0xffff, UQ_MSC_FORCE_WIRE_BBB,
 	    UQ_MSC_FORCE_PROTO_SCSI,
 	    UQ_MSC_NO_SYNC_CACHE),
Index: sys/dev/usb/usbdevs
===================================================================
--- sys/dev/usb/usbdevs	(revision 296946)
+++ sys/dev/usb/usbdevs	(working copy)
@@ -2527,6 +2527,7 @@
 product JETI SPC1201		0x04b2	FTDI compatible adapter
 
 /* JMicron products */
+product JMICRON JM20329		0x2329	USB to ATA/ATAPI Bridge
 product JMICRON JM20336		0x2336	USB to SATA Bridge
 product JMICRON JM20337		0x2338	USB to ATA/ATAPI Bridge
Comment 1 Hans Petter Selasky freebsd_committer freebsd_triage 2016-03-17 11:18:18 UTC
Hi,

Your driver looks recognized. What does:

gpart show da0

and 

dd if=/dev/da0 of=/dev/null bs=512 count=1

Output?

Might not be an USB problem. Sometimes there is no MBR:

mount -t msdosfs /dev/da0 /mnt

--HPS
Comment 2 Sylvain Garrigues 2016-03-17 11:46:13 UTC
Indeed, the drive is partitioned as GPT, is this a problem with USB drives?

I reformatted it as MBR, I still have the 
# usbd_set_config_index: could not read device status: USB_ERR_SHORT_XFER
line and the following ones, but I can now have
# GEOM: new disk da0
and I can use and mount the disk.

However, I don't understand how the disk can be recognized when it is not listed in sys/dev/usb/usbdevs, but that's my problem :-)

Thanks.
Comment 3 Hans Petter Selasky freebsd_committer freebsd_triage 2016-03-17 12:08:18 UTC
USB disks typically use a GENERIC ID which means they work without listing in usbdevs.

--HPS
Comment 4 Hans Petter Selasky freebsd_committer freebsd_triage 2016-03-17 12:09:31 UTC
The other USB error you list is not dangerous. It just means the USB vendor didn't implement a common USB request to ask for device status.

--HPS