On Wed, Feb 28, 2024 at 08:55:27AM -0700, Keith Busch wrote:
> On Wed, Feb 28, 2024 at 10:46:39AM -0500, Alan Stern wrote:
> > On Wed, Feb 28, 2024 at 01:22:12PM +0100, Harald Dunkel wrote:
> > > [1400821.811585] ------------[ cut here ]------------
> > > [1400821.811594] WARNING: CPU: 0 PID: 614303 at block/blk-lib.c:50 __blkdev_issue_discard+0x14b/0x180
> > > [1400821.811868] CPU: 0 PID: 614303 Comm: blkdiscard Tainted: P OE 6.1.0-18-amd64 #1 Debian 6.1.76-1
> > > [1400821.811875] Hardware name: Gigabyte Technology Co., Ltd. Z790 GAMING X/Z790 GAMING X, BIOS F9b 11/10/2023
> > > [1400821.811878] RIP: 0010:__blkdev_issue_discard+0x14b/0x180
> > > I tried a discard on a Samsung PM981 1TB SSD (m.2) using a JMicron USB adaptor.
> > >
> > > udev rule:
> > >
> > > ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0583", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
> > >
> > > Probably I was too optimistic.
> >
> > Notice that the USB layer does not show up at all in the stack dump
> > above, but the block layer figures prominently. This strongly suggests
> > that the bug lies in the block layer.
> >
> > CC'ing the appropriate mailing list and maintainer.
>
> In the code comments above the WARN, this condition indicates "the
> discard granularity isn't set by buggy device driver". The block layer
> needs this set if your driver also sets the max_discard_sectors limit.
The usb-storage and uas drivers do not set any of these; however, the
SCSI sd driver does. Maybe that's where the problem lies. Adding more
CC's.
Alan Stern
