From: bugzilla-daemon@kernel.org
To: linux-scsi@vger.kernel.org
Subject: [Bug 219652] New: READ CAPACITY(16) not used on large USB-attached drive in recent kernels
Date: Thu, 02 Jan 2025 00:57:26 +0000 [thread overview]
Message-ID: <bug-219652-11613@https.bugzilla.kernel.org/> (raw)
https://bugzilla.kernel.org/show_bug.cgi?id=219652
Bug ID: 219652
Summary: READ CAPACITY(16) not used on large USB-attached drive
in recent kernels
Product: IO/Storage
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: SCSI
Assignee: linux-scsi@vger.kernel.org
Reporter: bugs-a21@moonlit-rail.com
CC: stern@rowland.harvard.edu
Regression: Yes
Created attachment 307435
--> https://bugzilla.kernel.org/attachment.cgi?id=307435&action=edit
diff without stamps of the usbmon output, good (-) to bad (+)
Upgrading from old mainline LTS kernel 6.6 to current LTS kernel 6.12, a large
3.00TB SATA drive connected via USB through an "Initio Corporation INIC-1610P
SATA bridge" (id 13fd:1e40) is falsely reported as a 2.00TiB capacity drive.
According to the dmesg output, the newer kernel fails to identify the need to
call read_capacity_16(), resulting in a 32-bit size calculation.
I had reported this initially to the linux-usb mailing list. Alan Stern
(CC'ed) wrote back, suggesting I redirect to linux-scsi, and include some
usbmon traces. To upload the traces, I'm opening this on bugzilla.
A few notes:
* The USB-to-SATA bridge (via lsusb) is:
ID 13fd:1e40 Initio Corporation INIC-1610P SATA bridge
* When booting into kernel 6.12.7, the external drive capacity
is mis-reported. Booting /back/ into 6.6.68, the capacity
continues to be mis-reported. One must now yank the USB
cable (or power-cycle) to get the correct size detection again.
Here is a diff of the dmesg output when plugging in the drive.
From (-) is kernel 6.1.122
To (+) is kernel 6.12.7:
scsi host12: usb-storage 1-13:1.0
scsi 12:0:0:0: Direct-Access TOSHIBA DT01ACA300 3.00 PQ: 0 ANSI: 4
sd 12:0:0:0: Attached scsi generic sg1 type 0
-sd 12:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
-sd 12:0:0:0: [sdb] 5860533167 512-byte logical blocks: (3.00 TB/2.73 TiB)
+sd 12:0:0:0: [sdb] 4294967295 512-byte logical blocks: (2.20 TB/2.00 TiB)
sd 12:0:0:0: [sdb] Write Protect is off
sd 12:0:0:0: [sdb] Mode Sense: 23 00 00 00
sd 12:0:0:0: [sdb] No Caching mode page found
sd 12:0:0:0: [sdb] Assuming drive cache: write through
-sd 12:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
- sdb: sdb1
sd 12:0:0:0: [sdb] Attached SCSI disk
I am attaching a diff of the usbmon output for the earlier kernel (good) and
current kernel (bad), in case the sequence of commands sent to/from the bridge
shows whatever it is that puts the bridge into a low-capacity state. As I
think I can only attach one file to this posting, I'll make separate
attachments for the good and bad usbmon listings.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are the assignee for the bug.
next reply other threads:[~2025-01-02 0:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-02 0:57 bugzilla-daemon [this message]
2025-01-02 0:58 ` [Bug 219652] READ CAPACITY(16) not used on large USB-attached drive in recent kernels bugzilla-daemon
2025-01-02 0:59 ` bugzilla-daemon
2025-01-02 5:22 ` bugzilla-daemon
2025-01-02 5:26 ` bugzilla-daemon
2025-01-02 15:38 ` bugzilla-daemon
2025-01-02 23:07 ` bugzilla-daemon
2025-01-03 0:53 ` [Bug 219652] New: " Mike Christie
2025-01-03 0:53 ` [Bug 219652] " bugzilla-daemon
2025-01-03 2:02 ` bugzilla-daemon
2025-01-03 2:26 ` bugzilla-daemon
2025-01-03 3:01 ` bugzilla-daemon
2025-01-03 3:30 ` bugzilla-daemon
2025-01-04 3:50 ` Mike Christie
2025-01-03 3:37 ` bugzilla-daemon
2025-01-04 3:50 ` bugzilla-daemon
2025-01-06 20:33 ` bugzilla-daemon
2025-01-06 21:08 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-219652-11613@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.