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