Bug 261409 - [umass] Prolific PL2773 2nd device size query fails
Summary: [umass] Prolific PL2773 2nd device size query fails
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 12.2-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-22 19:45 UTC by freebsd
Modified: 2022-01-25 07:47 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description freebsd 2022-01-22 19:45:31 UTC
FreeBSD 12.2-RELEASE-p11 75566f060d4(HEAD) TRUENAS

umass0 on uhub2
umass0: <Prolific Technology Inc. USB-SATA Bridge, class 0/0, rev 3.00/1.00, addr 1> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x8000
umass0:6:0: Attached to scbus6
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0: <ST8000VN 0022-2EL112 SC61> Fixed Direct Access SCSI device
da0: 400.000MB/s transfers
da0: 7630885MB (15628053168 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
da1 at umass-sim0 bus 0 scbus6 target 0 lun 1
da1: <ST8000VN 0022-2EL112 SC61> Fixed Direct Access SCSI device
da1: 400.000MB/s transfers
da1: Attempt to query device size failed: ILLEGAL REQUEST, Invalid command operation code
da1: quirks=0x2<NO_6_BYTE>

# usbconfig -d 1.2 dump_device_desc
ugen1.2: <Prolific Technology Inc. USB-SATA Bridge> at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (24mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0300 
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0009 
  idVendor = 0x067b 
  idProduct = 0x2773 
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  <retrieving string failed>
  iProduct = 0x0002  <retrieving string failed>
  iSerialNumber = 0x0003  <retrieving string failed>
  bNumConfigurations = 0x0001

Device is a two bay USB-SATA dock.
Device tested ok on Manjaro and Windows.
Comment 1 Hans Petter Selasky freebsd_committer 2022-01-23 15:00:36 UTC
This is likely at the SCSI layer and not USB. Maybe you simply need to rescan.
Comment 2 freebsd 2022-01-23 16:10:17 UTC
(In reply to Hans Petter Selasky from comment #1)

Rescan, like this?

# geom disk list da1  
Geom name: da1
Providers:
1. Name: da1
   Mediasize: 0 (0B)
   Sectorsize: 512
   Mode: r0w0e0
   descr: ST8000VN 0022-2EL112
   ident: (null)
   rotationrate: unknown
   fwsectors: 0
   fwheads: 0

# camcontrol devlist  
<ST8000NM0055-1RM112 SN05>         at scbus0 target 0 lun 0 (pass0,ada0)
<ST8000NM0055-1RM112 SN05>         at scbus1 target 0 lun 0 (pass1,ada1)
<ST8000NM0055-1RM112 SN05>         at scbus2 target 0 lun 0 (pass2,ada2)
<ST8000NM0055-1RM112 SN05>         at scbus3 target 0 lun 0 (pass3,ada3)
<ST8000VN 0022-2EL112 SC61>        at scbus6 target 0 lun 0 (da0,pass4)
<ST8000VN 0022-2EL112 SC61>        at scbus6 target 0 lun 1 (da1,pass5)
# camcontrol rescan 6:0:1              
Re-scan of 6:0:1 was successful
# geom disk list da1     
Geom name: da1
Providers:
1. Name: da1
   Mediasize: 0 (0B)
   Sectorsize: 512
   Mode: r0w0e0
   descr: ST8000VN 0022-2EL112
   ident: (null)
   rotationrate: unknown
   fwsectors: 0
   fwheads: 0

#
Comment 3 Hans Petter Selasky freebsd_committer 2022-01-23 21:30:58 UTC
Looks like it doesn't help.

But the first disk, da0, works - right?

--HPS
Comment 4 freebsd 2022-01-23 21:41:39 UTC
(In reply to Hans Petter Selasky from comment #3)

Correct, da0 works, I've created a zfs pool on it.
Comment 5 Gary Jennejohn 2022-01-24 09:00:51 UTC
Don't know whether this will help, but I found this in comment 5 in
https://bugzilla.kernel.org/show_bug.cgi?id=43279 from 2012:

"At least for the 2xSATA you need to enable SCSI MULTILUN device probing to access both devices."
Comment 6 freebsd 2022-01-25 07:47:11 UTC
(In reply to Gary Jennejohn from comment #5)

Not familiar with kernel to say for sure but to me it looks like both luns are detected and in the process of being probed from the log.

Both drives being the same type I'd assume they would both be probed the same way which makes the "Invalid command operation code" a bit odd though.