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.
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...
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
Committed to -master, will let it chill in -head and then MFC it to stable/11 and stable/12
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 :).
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?
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.
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.
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.
(In reply to Warner Losh from comment #7) I haven't the revised quirk committed yet? When will it be committed?
(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.
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.
(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.
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.
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
(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.
What's the delay on this? Please MFC to stable/11 and stable/12.
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
(In reply to Mel Pilgrim from comment #16) Merged to 11 and 12..
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.