[Bug 219027] New: The SCSI can't adjust Max xfer length (blocks) with different storage device

[Bug 219027] New: The SCSI can't adjust Max xfer length (blocks) with different storage device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219027

            Bug ID: 219027
           Summary: The SCSI can't adjust Max xfer length (blocks) with
                    different storage device
           Product: SCSI Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: high
          Priority: P3
         Component: Other
          Assignee: scsi_drivers-other@kernel-bugs.osdl.org
          Reporter: 983292588@qq.com
        Regression: No

My storage device CPU has a 64kB (limited by hardware) buffer used to cache
reads/writes which means it can only cache up to 128 blocks(512Byte) of memory.

But the Linux source code says that for USB2.0, the default max_sectors=240
blocks. So the SCSI Write-10 and Read-10 command has a total-blocks field that
can be up to 240 blocks (120KB) for USB2.0. 

When originally testing the product on Windows 11 it never writes more than 128
blocks at a time. However, when tested on Linux it sometimes writes more than
128 blocks(240 blocks as setting above), which causes the usb storage device to
crash. 


Is there a way to tell the Linux host OS not to request more than 128 blocks?

My storage device's firmware has implemented block limit VPD page (page =
0xB0), and it works well on Windows 10/11. I even set the block limit to be 64
blocks, it's OK too. Because before the data transfer, the windows host issue
an SCSI inquiry order with the VPD PAGE CODE = 0xB0, so the device could
transmit the block limits information to the host. And then the windows host
could adjust the amount of data transferred.

However, on Linux or MacOS, the host does not appear to be running the block
limits command. So maybe the host doesn't know what is the block limits. Then
the write/read blocks number beyond the buffer size.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219027] The SCSI can't adjust Max xfer length (blocks) with different storage device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219027

Martin K. Petersen (mkp@mkp.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mkp@mkp.net

--- Comment #1 from Martin K. Petersen (mkp@mkp.net) ---
Due to some legacy devices hanging when probing for non-existent pages the
Linux USB storage driver opts out of consulting the Block Limits VPD.

I suggest you create a udev rule to override
/sys/block/sdN/queue/max_sectors_kb.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219027] The SCSI can't adjust Max xfer length (blocks) with different storage device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219027

--- Comment #2 from LXY (983292588@qq.com) ---
Thanks for your reply.


I've tried creating udev rules and it works. But whenever I use my USB storage
device on a new PC, I find it a little inconvenient to create rules.


So I'm trying to find a way to get Linux PC consulting the Block Limits VPD. Do
you mean that for all Linux USB storage drivers, Linux hosts will not consult
the Block Limits VPD?


I actually have the firmware source code for my USB storage device, and I can
make some changes I want. For example, change the VPD page it supports. Do you
think it will work?


Best wishes.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219027] The SCSI can't adjust Max xfer length (blocks) with different storage device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219027

--- Comment #3 from LXY (983292588@qq.com) ---
(In reply to Martin K. Petersen from comment #1)
> Due to some legacy devices hanging when probing for non-existent pages the
> Linux USB storage driver opts out of consulting the Block Limits VPD.
> 
> I suggest you create a udev rule to override
> /sys/block/sdN/queue/max_sectors_kb.

Thanks for your reply.


I've tried creating udev rules and it works. But whenever I use my USB storage
device on a new PC, I find it a little inconvenient to create rules.


So I'm trying to find a way to get Linux PC consulting the Block Limits VPD. Do
you mean that for all Linux USB storage drivers, Linux hosts will not consult
the Block Limits VPD?


I actually have the firmware source code for my USB storage device, and I can
make some changes I want. For example, change the VPD page it supports. Do you
think it will work?


Best wishes.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219027] The SCSI can't adjust Max xfer length (blocks) with different storage device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219027

imyxh (imyxh@imyxh.net) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |imyxh@imyxh.net

--- Comment #4 from imyxh (imyxh@imyxh.net) ---
I stumbled across the same issue with an oscilloscope I bought and am just
writing to say that I needed to set max_sectors under the scsi subsystem, not
max_sectors_kb under the block subsystem. Even with max_sectors_kb set really
small, I was seeing read(10) commands for 240 blocks on Wireshark.

LXY, you wouldn't happen to be developing firmware for FNIRSI, would you? :)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219027] The SCSI can't adjust Max xfer length (blocks) with different storage device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219027

--- Comment #5 from LXY (983292588@qq.com) ---
(In reply to imyxh from comment #4)
> I stumbled across the same issue with an oscilloscope I bought and am just
> writing to say that I needed to set max_sectors under the scsi subsystem,
> not max_sectors_kb under the block subsystem. Even with max_sectors_kb set
> really small, I was seeing read(10) commands for 240 blocks on Wireshark.
> 
> LXY, you wouldn't happen to be developing firmware for FNIRSI, would you? :)

What a pity. I still haven't found a solution.

And I haven't developed firmware for FNIRSI. I'm developing TI's firmware. Just
for my interests.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219027] The SCSI can't adjust Max xfer length (blocks) with different storage device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219027

--- Comment #6 from imyxh (imyxh@imyxh.net) ---
(In reply to LXY from comment #5)
> What a pity. I still haven't found a solution.

Have you tried simply handling the invalid write/read commands by returning
ILLEGAL REQUEST with INVALID FIELD IN CDB? (I know nothing about SCSI; this is
just as per https://stackoverflow.com/a/33372494)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 219027] The SCSI can't adjust Max xfer length (blocks) with different storage device

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=219027

--- Comment #7 from LXY (983292588@qq.com) ---
(In reply to imyxh from comment #6)
> (In reply to LXY from comment #5)
> > What a pity. I still haven't found a solution.
> 
> Have you tried simply handling the invalid write/read commands by returning
> ILLEGAL REQUEST with INVALID FIELD IN CDB? (I know nothing about SCSI; this
> is just as per https://stackoverflow.com/a/33372494)

Yes, but it doesn't work for my device.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.