Bug 234503

Summary: Chipfancier SLC 16GB memstick: ILLEGAL REQUEST asc:21,0 (Logical block address out of range)
Product: Base System Reporter: josef.lar
Component: usbAssignee: Warner Losh <imp>
Status: Closed FIXED    
Severity: Affects Some People CC: cygsrc, gonzo, imp, ports.maintainer
Priority: --- Keywords: feature
Version: 11.2-RELEASEFlags: koobs: mfc-stable12?
koobs: mfc-stable11?
Hardware: Any   
OS: Any   
Attachments:
Description Flags
This patch fixes the problem for me.
none
Patch to broaden quirk coverage to all Chipfancier devices none

Description josef.lar 2018-12-30 15:24:36 UTC
Created attachment 200622 [details]
This patch fixes the problem for me.

Got a very similar issue as in Bug 198647.

dmesg info:

da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <16G SLC CHIPFANCIER 1.00> Removable Direct Access SPC-4 SCSI device
da0: Serial Number 500274313
da0: 40.000MB/s transfers
da0: 15900MB (32564183 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
da0: Delete methods: <NONE(*),ZERO>
(da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 01 f0 e3 d6 00 00 01 00 
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block address out of range)
(da0:umass-sim0:0:0:0): Error 22, Unretryable error

The number of sectors does not match the number I get from Linux, and a similar patch (see the attachment) as the one in bug 198647 fixed the problem for me.
Comment 1 Warner Losh freebsd_committer freebsd_triage 2018-12-31 20:25:01 UTC
This patch looks good to me. It might be nice if we tried to automate this weird quirk...

The CCB decodes to the right thing...
Comment 2 commit-hook freebsd_committer freebsd_triage 2018-12-31 22:20:46 UTC
A commit references this bug:

Author: imp
Date: Mon Dec 31 22:20:30 UTC 2018
New revision: 342657
URL: https://svnweb.freebsd.org/changeset/base/342657

Log:
  Add NO_RC16 quirk for Chipfancier 16GB USB stick...

  Submitted by: osef.lar@gmail.com
  PR: 234503

Changes:
  head/sys/cam/scsi/scsi_da.c
Comment 3 Warner Losh freebsd_committer freebsd_triage 2018-12-31 22:28:01 UTC
Committed to -master, will let it chill in -head and then MFC it to stable/11 and stable/12
Comment 4 josef.lar 2019-01-01 03:58:36 UTC
Thanks! Yes, it will be impossible to test all the hardware in the world to see if this quirk applies so it would really be good to automate it somehow...

The e-mail in the commit msg looks incorrect but this is no big deal for me :).
Comment 5 ports.maintainer 2019-01-24 13:39:01 UTC
I have a Chipfancier 32 GB SLC drive that also exhibits this problem:

umass0 on uhub0
umass0: <32G SLC CHIPFANCIER, class 0/0, rev 3.00/0.01, addr 3> on usbus0
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:9:0: Attached to scbus9
da0 at umass-sim0 bus 0 scbus9 target 0 lun 0
da0: <32G SLC CHIPFANCIER 1.00> Removable Direct Access SPC-4 SCSI device
da0: Serial Number 56922150
da0: 400.000MB/s transfers
da0: 31800MB (65128366 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
(da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 03 e1 c7 ac 00 00 01 00
(da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
(da0:umass-sim0:0:0:0): SCSI status: Check Condition
(da0:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:21,0 (Logical block address out of range)
(da0:umass-sim0:0:0:0): Error 22, Unretryable error
[dozens of repetitions snipped]

I added the quirk to a GENERIC build from releng/11.2 r343111 modified as

{T_DIRECT, SIP_MEDIA_REMOVABLE, "32G SLC", "CHIPFANCIER", "1.00"}

and it fixed the problem for me as well.

Can this quirk be made to cover all of the Chipfancier drives?  I would assume everything in the family is going to have the same bug as, internally, these only differ by the number/capacity of the memory chips.  There are 16, 32, 64, 128, and 256 GB versions of this product.

If there will be an 11.3-R, can this get into stable/11 before then?
Comment 6 ports.maintainer 2019-02-06 10:46:04 UTC
Created attachment 201786 [details]
Patch to broaden quirk coverage to all Chipfancier devices

I was asked to provide a patch to cover all Chipfancier devices.  I've been running this patch in production and it covers the 32 GB Chipfancier devices I have.
Comment 7 Warner Losh freebsd_committer freebsd_triage 2019-02-09 05:18:10 UTC
Any chance that I can get either a Chipfancier device, or a pointer to where to get one? It would be helpful to see a trace of its discovery to see if there'd be a way we can avoid needing this quirk at all...

I'll update the quirk.
Comment 8 ports.maintainer 2019-02-09 17:09:55 UTC
They're available on Amazon, NewEgg, and slcssd.com.  The specific product group is Chipfancier's "Enterprise Level SLC" USB 3.0 drives.

Newegg:
https://www.newegg.com/Product/Product.aspx?item=9SIAERZ6975952
Amazon:
https://www.amazon.com/Enterprise-Level-USB3-0-Positive-high-Speed/dp/B071YRWPPX/
slcssd:
https://www.slcssd.com/product/slc-ssd/?v=7516fd43adaa

I can also send you one myself if cost is a factor. These are not cheap thumbdrives.
Comment 9 ports.maintainer 2019-03-01 22:38:55 UTC
(In reply to Warner Losh from comment #7)

I haven't the revised quirk committed yet?  When will it be committed?
Comment 10 Warner Losh freebsd_committer freebsd_triage 2019-03-01 23:42:39 UTC
(In reply to Mel Pilgrim from comment #9)
I was hoping to get one so I can test it (and a couple of other, more general fixes) before committing the quirk. However, my shipment seems to have been delayed.
Comment 11 Warner Losh freebsd_committer freebsd_triage 2019-03-09 01:10:42 UTC
I have a 16GB and a 128GB stick now to try.
Once I test those, I'll MFC to 12 and 11 and test on my stable/12 VMs that I can pass this device through to.
Comment 12 Warner Losh freebsd_committer freebsd_triage 2019-03-09 04:59:16 UTC
(In reply to josef.lar from comment #4)
> The e-mail in the commit msg looks incorrect but this is no big deal for me :).
I just notice this comment... Uggg. I'll get it right in the MFC. Sorry about that.
Comment 13 Warner Losh freebsd_committer freebsd_triage 2019-03-11 20:30:04 UTC
The 128GB has the same problem as the 16GB driver:

da0: <16G SLC CHIPFANCIER 1.00> Removable Direct Access SPC-4 SCSI device
da0: 15237MB (31205621 512 byte sectors)
da1: <128G SLC CHIPFANCIER 1.00> Removable Direct Access SPC-4 SCSI device
da1: 121896MB (249644974 512 byte sectors)

# camcontrol readcap da0
Last Block: 31205620, Block Length: 512 bytes
# camcontrol readcap da0 -l
Last Block: 31238388, Block Length: 512 bytes

da0 rc10 is correct, rc16 is wrong (attempts to use that size result in reads past end of drive.

# camcontrol readcap da1
Last Block: 249644973, Block Length: 512 bytes
# camcontrol readcap da1 -l
Last Block: 249907117, Block Length: 512 bytes

Though the magnitude is different. 32k vs 256k sectors off.
Comment 14 commit-hook freebsd_committer freebsd_triage 2019-03-11 20:58:16 UTC
A commit references this bug:

Author: imp
Date: Mon Mar 11 20:57:54 UTC 2019
New revision: 345025
URL: https://svnweb.freebsd.org/changeset/base/345025

Log:
  Upgrade Chipfancier SLC quirk to all versions

  The 16GB, 32GB and 128GB versions of this product all have the same
  problem. For some reason, the RC10 size is correct, while the RC16
  size is larger (oddly by the capacity size / 1024 bytes). Using the
  RC16 size results in illegal LBA range errors when geom tastes the
  device. So, expand the quirk to cover all versions of this chip.

  Ideally, we'd get both READ CAPACITY 10 and READ CAPACITY 16 sizes and
  print a warnnig if they differ and use the smaller of the two numbers,
  though that may be problematical as well. Furthermore, SBC-4
  encourages users transition to RC16 only, which suggests that in the
  future RC10 may disappear from some drives. It's unclear how to cope
  with these drives generically.

  PR: 234503
  MFC After: 1 week

Changes:
  head/sys/cam/scsi/scsi_da.c
Comment 15 ports.maintainer 2019-04-02 00:50:49 UTC
(In reply to commit-hook from comment #14)

Reminder that this needs to be merged into stable/11 and stable/12, and the slush for 11.3-R is soonish.
Comment 16 ports.maintainer 2019-04-19 08:49:08 UTC
What's the delay on this? Please MFC to stable/11 and stable/12.
Comment 17 commit-hook freebsd_committer freebsd_triage 2019-04-19 20:24:42 UTC
A commit references this bug:

Author: imp
Date: Fri Apr 19 20:23:39 UTC 2019
New revision: 346415
URL: https://svnweb.freebsd.org/changeset/base/346415

Log:
  MFC: 342657, 345025

  Quirks for Chipfancier chips. Their READ CAPACITY 10 and READ CAPACITY
  16 values differ, and the default of using RC16	gets the improper one.

  PR:		234503

Changes:
_U  stable/11/
  stable/11/sys/cam/scsi/scsi_da.c
Comment 18 Warner Losh freebsd_committer freebsd_triage 2019-04-19 20:25:32 UTC
(In reply to Mel Pilgrim from comment #16)
Merged to 11 and 12..
Comment 19 cygsrc 2019-12-29 11:53:06 UTC
I think this bug is due to the buggy firmware from Innostor, which also causes the Bug 194062.

As far as I know, the firmware team of Innostor has been dissolved. So there is little hope that the bug in the firmware will be fixed.

FYI, ChipFancier has several models of USB sticks. The '*SLC' model uses the IS903 controller; so does the '*MLC' model. The other models of Chipfancier are actually combinations of solid-sate disks and SATA-USB bridge chips (asm1351/asm1153e). So there should be no 'RC16' issue.