On Wed, Jan 17, 2024 at 04:56:46PM +0100, Bruno Haible wrote: > Alan Stern wrote: > > > > Slowing down all RTL9120 already in the market with this quirk is in my > > > > humble opinion not a realistic solutio. > > > > > > What else do you propose, for those of us who buy this hardware (€ 50, > > > it wasn't a cheap one), connect it directly to a computer (through the > > > vendor-provided cable, to an USB-C 3.2 Gen.2 connector, as in my case), > > > and then experience 1-2 crashes per day under Linux? > > > > The proposal is that you keep on doing what you've been doing: Set the > > UAS quirk. Then your system will work, and others who don't have the > > same problem will get to keep the advantage of quicker transfers with > > the uas driver. > > There's obviously a speed vs. reliability tradeoff here. > > On the speed side: Do you know the speed difference between an external > SSD with uas driver vs. an external SSD with usb-storage driver? I don't know, offhand. People have posted on the mailing list numbers they got through testing. uas was considerably faster than usb-storage (IIRC, more than a factor of two). > On the reliability side: It makes the difference between a usable and > an unusable computer. I don't understand why you seem to prefer that > I have, by default, a fast but unusable computer rather than a reliable, > even if speed-limited, computer. Isn't it the opposite throughout the > industry? (For example, the CPU clock is not overclocked _by_default_. > An admin can overclock it, but the default is to be reliable.) I suspect the two situations aren't truly comparable. > You say "Set the UAS quirk", as if it was something completely immediate > to do. > > - As a tech-savvy person (and former Linux kernel developer), it took > me 3 days of investigations, web searches, and reading of kernel > command-line documentation, in order to get at the solution. > > - For a non-tech-savvy person, it's basically impossible to arrive > at the solution you propose. They would have summarized their experience > as "Linux is not made for the desktop, let me choose another OS". It works both ways. Consider a non-tech-savvy person who buys one of these expensive adapters, expecting that it will improve performance considerably, and then is disappointed to find out that it doesn't (because of the new quirk). They would summarize their experience in the same way. Also, consider the problem that would be faced by people who are already using their USB-SSD bridge devices at high speed with no trouble. They would suddenly experience a decrease in speed after performing a kernel update, and that would be considered a regression. Regressions are not allowed in Linux kernel development. > Isn't there a more intelligent solution to this problem? For example, the > uas_eh_abort_handler could, instead of just logging the problem, tell a > system daemon that the configuration of the particular device is problematic, > and that system daemon would change the grub.cfg (or some other file that > stores kernel command-line parameters), so that the quirk gets activated > automatically at the next reboot. I'm not aware of anyone who has ever set up a system that uses runtime feedback from the kernel to automatically make adjustments to critical configuration files like grub.cfg (other than installation managers such as anaconda). However, please feel free to create such a system on your own and popularize it. Part of the difficulty is that the kernel generally does not have enough information to tell what the cause of a particular problem is. For instance, even though it might know that a USB transfer is getting errors and the device is not plugged into a powered hub, it's not at all clear that switching drivers might fix the problem. Alan Stern
