linux
linux copied to clipboard
raspberrypi
Unusual Uasp file
Describe the bug
Hello there
Is it possible please to add to the file: https://github.com/raspberrypi/linux/blob/rpi-5.15.y/drivers/usb/storage/unusual_uas.h
Some usb 3.0 chipsets/controllers more??
The Jmicron Jms578
The Asmedia Asm1153E
The Asmedia Asm235CM
And The Initio Inic3639
Thanks in advance
Steps to reproduce the behaviour
.
Device (s)
Raspberry Pi 4 Mod. B
System
Raspbian Buster latest version
Logs
No response
Additional context
No response
lsusb would give the vendor and device IDs, but that doesn't tell us which quirks are needed for each one.
No - that's a device id for an ASMedia Technology ASM1051E SATA 6Gb/s bridge. Quirks are things like US_FL_NO_REPORT_OPCODES and US_FL_IGNORE_UAS.
Why do you think the controllers you listed need to be added to unusual_uas.h? What have you been doing to set the quirk(s) up to now?
The jms567 that is included in the unusual_uas file works good with quirks enabled and both mechanical and ssds have great performance
Im using both mechanical and ssds with that controller's most of them perform somehow ok with quirks enabled and ssds but with mechanical disks their performance is very bad with quirks or not there is no difference
If you cannot add them all at least add the Asmedia Asm1153E And the Initio inic3639
What I'm hearing is "I have several devices that use a number of SATA bridges. One of them works well, the others don't. The one that works well is included in unusual_uas.h, the others aren't, so please add the others to it to fix them."
What have I got wrong, or missed out?
If you cannot add any device,can you at least tell me how to add it my self manual to the file in my os directly??
That's a kernel header file - you'll have to recompile the kernel. There are instructions for kernel building here: https://www.raspberrypi.com/documentation/computers/linux_kernel.html#building
You didn't answer my earlier question:
What have you been doing to set the quirk(s) up to now?
I set them from the cmdline.txt file By put the device id
Eg: usb-storage.quirks=174c:55aa:u
OK, we're getting somewhere, the :u at the end translates to US_FL_IGNORE_UAS.
Have you done something similar with all the other devices? If so, tell me what the quirks=... entries were.
OP has a post on the forum saying disabling UAS didn't help for those adapters. unusual_uas.h doesn't do anything that can't be done via usb-storage.quirks in cmdline.txt.
Only the device id is changing in the other devices The :u remains the same,are there other commands than :u to put in the end?
Do you want the other devices ids?
Do you want the other devices ids?
Yes, of course.
What do you have to say about "OP has a post on the forum saying disabling UAS didn't help for those adapters"?
@trejan is correct in saying that unusual_uas.h doesn't do anything you can't do with quirks on the command line - it's just a convenience.
I asked there also maybe someone knew something.
Jms578: usb-storage.quirks=152d:0578:u
Inic3639: usb-storage.quirks=13FD:3960:u
Or usb-storage.quirks=8888:7777:u
Asm1153E: usb-storage.quirks=174c:55aa:u
Asm235cm: usb-storage.quirks=174c:55aa :u
Im not 100,% for the initio controller i have to take a look at it later.
are there other flags than :u to put in the end to help with the issue??
Ok, Phil redirected me here from the discussion in #5246. In summary, I also have a JMS578 device that required disabling UAS to work properly. I did so with a quirk override in cmdline.txt, same as the OP here, and wanted to contribute that back to the kernel - particularly because I saw there was a quirks entry for this device already, but it didn't seem to be doing its job.
Phil helped me identify that we just need to include US_FL_IGNORE_UAS in the flags set for this device's quirks entry. I can do that with a simple PR. However, the fact that the original contributor of the quirks entry didn't set this flag suggests he didn't have the same issues we're having. Which would mean not everyone with this device requires disabling UAS.
So the question is, do we want to set this flag in the kernel, even if it could degrade performance for some people? Do we prioritise the device working correctly in all cases, or performing best for those who can take advantage of UAS?
Given general Linux philosophy I'd assume the former, but wanted to put this up for discussion here before making a PR.
Only sata 2 chipsets without uasp support work correct with mechanical hdds 95% of the chipsets that i tried with uasp support they work very slow with mechanical drives with huge delay in read/write operations even with uasp disabled,only the jms566/567 worked correct with uasp disabled.