NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/60933: sd_read_capacity 0xffffffff fallback to READ CAPACITY 16 was removed, breaking support for large (>2TiB) disk drives on at least mpt(4)



>Number:         60933
>Category:       kern
>Synopsis:       sd_read_capacity 0xffffffff fallback to READ CAPACITY 16 was removed, breaking support for large (>2TiB) disk drives on at least mpt(4)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 27 20:45:01 +0000 2026
>Originator:     Josh Moyer
>Release:        11.0
>Organization:
NODOMAIN.NET
>Environment:
NetBSD host.domain.tld 11.0 NetBSD 11.0 (GENERIC_KASLR) #0: Thu Jul 30 15:23:12 UTC 2026 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC_KASLR (VMware Workstation Pro 26H1u1 Windows amd64)

>Description:
SCSI drives >2TiB fail to come online.  This is a regression from 10.1 and, so, should probably be pulled-up.

mpt0 at pci0 dev 16 function 0: Symbios Logic 53c1020/53c1030 (rev. 0x01)
mpt0: applying 1030 quirk
mpt0: interrupting at ioapic0 pin 17
scsibus0 at mpt0: 16 targets, 8 luns per target
...
sd1 at scsibus0 target 1 lun 0: <VMware,, VMware Virtual S, 1.0>
disk fixed
sd1(mpt0:0:1:0):  Check condition on CDB: 0x23 00 00 00 00 00 00 00 0c 00
    SENSE KEY:  Illegal request
     ASC/ASCQ:  Invalid Command Operation Code
sd1: drive offline
sd1: sync (6.25ns offset 127), 16-bit (320.000MB/s) transfers, tagged queueing
>How-To-Repeat:
Upgrade a 10.1 VMware VM with a >2TiB SCSI virtual disk mounted on /$mnt to 11.0.

Observed:
sd1(mpt0:0:1:0):  Check condition on CDB: 0x23 00 00 00 00 00 00 00 0c 00
    SENSE KEY:  Illegal request
     ASC/ASCQ:  Invalid Command Operation Code
sd1: drive offline

Expected:
Drive should come online.
>Fix:
Claude generated a code reviewed and tested (by me) patch file for the issue (not attached.)

I would describe the fix as re-implementing the removed fallback to READ CAPACITY 16 when a "sentinel" result of 0xffffffff is encountered.  This fallback is apparently required per SBC-2 (regardless of what is received from INQUIRY) and so is needed even when periph_version >= 5 (SPC-3).  The fix includes a retry-loop prevention mechanism, as well.  (The regression was introduced by the logical block provisioning / UNMAP work in 11.0.)

It also seemed to be describing rv = _4btol(datap->data.addr) + 1; wrapping to 0 on the all 1's sentinel value that is the root-cause, seemingly, since that leads to the READ FORMAT CAPCITIES, which fails on disk devices.

Claude did a better job than I of describing it all, frankly, even if it was not as concise.




Home | Main Index | Thread Index | Old Index