Bug 200679
Summary: | broken TRIM support for JMS578 in uas mode | ||
---|---|---|---|
Product: | Drivers | Reporter: | mailinglists35 |
Component: | USB | Assignee: | Greg Kroah-Hartman (greg) |
Status: | NEW --- | ||
Severity: | normal | CC: | bugzilla, jszigetvari, mirh, pmenzel+bugzilla.kernel.org, rm+bko |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.17.9-200.fc28.x86_64 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
mailinglists35
2018-07-29 14:09:25 UTC
On Sun, Jul 29, 2018 at 02:09:25PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=200679 > > Bug ID: 200679 > Summary: broken TRIM support for JMS578 in uas mode > Product: Drivers > Version: 2.5 > Kernel Version: 4.17.9-200.fc28.x86_64 All USB bugs should be sent to the linux-usb@vger.kernel.org mailing list, and not entered into bugzilla. Please bring this issue up there, if it is still a problem in the latest kernel release. (In reply to Greg Kroah-Hartman from comment #1) > On Sun, Jul 29, 2018 at 02:09:25PM +0000, > bugzilla-daemon@bugzilla.kernel.org wrote: > > https://bugzilla.kernel.org/show_bug.cgi?id=200679 > > > > Bug ID: 200679 > > Summary: broken TRIM support for JMS578 in uas mode > > Product: Drivers > > Version: 2.5 > > Kernel Version: 4.17.9-200.fc28.x86_64 > > > All USB bugs should be sent to the linux-usb@vger.kernel.org mailing > list, and not entered into bugzilla. Please bring this issue up there, > if it is still a problem in the latest kernel release. https://marc.info/?l=linux-usb&m=153295104606185&w=2 Tested with rc6 (I don't see anything related to uas in usb changelog between rc6 and latest rc7) I checked linux-usb@vger.kernel.org, and the discussion was discontinued there. Is TRIM for JMS578 supported by the latest linux kernel? Yes it should https://mvysny.github.io/ssd-usb-enclosure/ *But* this should always have been the case from the get go, the only possibly nefarious variable is the firmware but OP reported to have tried more than one. And of course he said W10 was just fine. https://www.spinics.net/lists/linux-usb/msg172736.html It seems like something in the linux drivers isn't able to configure the right setting. p.s. I wonder if this isn't also the problem experienced in bug 83181? I don't mean to resurrect a long-forgotten bug, but I have a similar problem: (I use the stock Ubuntu 20.04 kernel: 5.11.0-46-generic #51~20.04.1-Ubuntu SMP Fri Jan 7 06:51:40 UTC 2022) I have a slightly different device: 152d:0580 JMicron Technology Corp. / JMicron USA Technology Corp. USB 3.1 Storage Device The enclosure is actually an IcyBox IB-1817M-C31 enclosure- According to the product ID the controller should be a JMS580, which according to the manufacturer supports TRIM. However when I want to use blkdiscard, I am getting the following error: # LANG=en_US blkdiscard -v /dev/sdb blkdiscard: /dev/sdb: BLKDISCARD ioctl failed: Operation not supported And this is the manufacturer's product information sheet for the controller: https://www.jmicron.com/file/download/1021/JMS580_Product+Brief.pdf You are very OT, and you should have opened a new bug. https://www.touslesdrivers.com/index.php?v_page=23&v_code=59438&v_langue=en https://www.station-drivers.com/index.php/en/outils/Drivers/Jmicron/JMS580-Sata-USB-3.1-Controller/Jmicron-JMS580-Sata-USB-3.0-Controller-Firmware-Version-234.01.00.01/lang,en-gb/ If you have problems, I could only recommend to try newer firmware (hoping they are the right ones) To original poster, can you still reproduce this issue with Linux 6.0? If yes, the mailing list thread should be revived. I can reproduce with kernel 5.10.146 and a JMS576: # blkdiscard /dev/sdc3 blkdiscard: /dev/sdc3: BLKDISCARD ioctl failed: Operation not supported However, as detailed in this message: https://www.spinics.net/lists/linux-usb/msg172736.html it can be fixed: # cat /sys/class/scsi_disk/6\:0\:0\:0/provisioning_mode full # lsblk -D /dev/sdc NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sdc 0 0B 0B 0 ├─sdc1 0 0B 0B 0 ├─sdc2 0 0B 0B 0 └─sdc3 0 0B 0B 0 # echo unmap > /sys/class/scsi_disk/6\:0\:0\:0/provisioning_mode # lsblk -D /dev/sdc NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sdc 0 4K 4G 0 ├─sdc1 0 4K 4G 0 ├─sdc2 0 4K 4G 0 └─sdc3 0 4K 4G 0 Except that's not all: # blkdiscard /dev/sdc3 blkdiscard: /dev/sdc3: BLKDISCARD ioctl failed: Remote I/O error Some trial and error results in finding the actual working discard size of 31 MiB (32 fails): # echo $((31*1024*1024)) > /sys/block/sdc/queue/discard_max_bytes # blkdiscard /dev/sdc3 && echo done done Confirmed that /dev/sdc3 now contains zeroes instead of previously written data. Turns out there's an entire wiki article about this: https://wiki.gentoo.org/wiki/Discard_over_USB What is the reason that discard is not just automatically enabled for USB disks? |