"SilverStone TS16" external SSD enclosing needs an UAS quirk

"SilverStone TS16" external SSD enclosing needs an UAS quirk

[Bruno Haible]

TL;DR
-----
In my experience, the "SilverStone TS16" external SSD enclosing
needs an UAS quirk
  usb-storage.quirks=0bda:9210:u
as part of the kernel command line. I hope you can add it
to the file linux/drivers/usb/storage/unusual_uas.h .

Long story
----------

In August 2023 I bought a new PC (Fujitsu ESPRIMO G7012A),
attached an SSD through an external SSD enclosing of type
"SilverStone TS16" [1], and used this SSD for the root and
data partitions of a Linux (Ubuntu 22.04, Linux 5.15.0-ubuntu)
installation.
The system crashed about 1 or 2 times per day, on average,
but especially upon intensive data I/O from this SSD
(namely, when working with a 50 GB VirtualBox image file).

When it crashed, I saw this in the kernel log:
--------------------------------------------------------------------------------
[58783.826555] sd 3:0:0:0: [sdb] tag#13 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD 
[58783.826561] sd 3:0:0:0: [sdb] tag#13 CDB: Read(10) 28 00 a7 a4 21 00 00 00 80 00
[58783.826565] sd 3:0:0:0: [sdb] tag#10 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD OUT 
[58783.826567] sd 3:0:0:0: [sdb] tag#10 CDB: Write(10) 2a 00 56 fd d6 28 00 00 28 00
[58783.826669] sd 3:0:0:0: [sdb] tag#8 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT 
[58783.826670] sd 3:0:0:0: [sdb] tag#8 CDB: Write(10) 2a 00 5c 7c 75 c0 00 00 88 00
[58783.874555] sd 3:0:0:0: [sdb] tag#3 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT 
[58783.874560] sd 3:0:0:0: [sdb] tag#3 CDB: Write(10) 2a 00 23 62 1d 68 00 00 20 00
[58783.874658] sd 3:0:0:0: [sdb] tag#2 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT 
[58783.874660] sd 3:0:0:0: [sdb] tag#2 CDB: Write(10) 2a 00 24 7c 12 90 00 00 08 00
[58783.874738] sd 3:0:0:0: [sdb] tag#1 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD OUT 
[58783.874740] sd 3:0:0:0: [sdb] tag#1 CDB: Write(10) 2a 00 24 7e 38 98 00 00 08 00
[58784.302551] sd 3:0:0:0: [sdb] tag#0 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT 
[58784.302561] sd 3:0:0:0: [sdb] tag#0 CDB: Write(10) 2a 00 be 9c 85 20 00 00 08 00
[58785.682531] sd 3:0:0:0: [sdb] tag#17 uas_eh_abort_handler 0 uas-tag 14 inflight: CMD OUT 
[58785.682537] sd 3:0:0:0: [sdb] tag#17 CDB: Write(10) 2a 00 17 c2 82 70 00 00 08 00
[58785.682634] sd 3:0:0:0: [sdb] tag#16 uas_eh_abort_handler 0 uas-tag 13 inflight: CMD OUT 
[58785.682636] sd 3:0:0:0: [sdb] tag#16 CDB: Write(10) 2a 00 17 c2 81 b8 00 00 08 00
[58785.682710] sd 3:0:0:0: [sdb] tag#15 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT 
[58785.682711] sd 3:0:0:0: [sdb] tag#15 CDB: Write(10) 2a 00 17 c2 7b 98 00 00 08 00
[58785.682787] sd 3:0:0:0: [sdb] tag#14 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT 
[58785.682789] sd 3:0:0:0: [sdb] tag#14 CDB: Write(10) 2a 00 17 c2 7a e0 00 00 08 00
[58785.682864] sd 3:0:0:0: [sdb] tag#12 uas_eh_abort_handler 0 uas-tag 12 inflight: CMD OUT 
[58785.682865] sd 3:0:0:0: [sdb] tag#12 CDB: Write(10) 2a 00 17 c2 7f e8 00 00 08 00
[58785.682942] sd 3:0:0:0: [sdb] tag#11 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT 
[58785.682944] sd 3:0:0:0: [sdb] tag#11 CDB: Write(10) 2a 00 17 c2 74 00 00 00 08 00
[58805.074324] sd 3:0:0:0: [sdb] tag#18 uas_eh_abort_handler 0 uas-tag 15 inflight: CMD IN 
[58805.074329] sd 3:0:0:0: [sdb] tag#18 CDB: Read(10) 28 00 be 8f 72 80 00 00 20 00
[58813.770230] sd 3:0:0:0: [sdb] tag#9 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD 
[58813.770235] sd 3:0:0:0: [sdb] tag#9 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
[58813.794245] scsi host3: uas_eh_device_reset_handler start
[58819.134207] xhci_hcd 0000:04:00.4: Timeout while waiting for setup device command
[58824.514145] xhci_hcd 0000:04:00.4: Timeout while waiting for setup device command
[58824.726112] usb 4-2.1: device not accepting address 3, error -62
[58830.146082] xhci_hcd 0000:04:00.4: Timeout while waiting for setup device command
[58835.518040] xhci_hcd 0000:04:00.4: Timeout while waiting for setup device command
[58835.726001] usb 4-2.1: device not accepting address 3, error -62
[58836.070158] usb 4-2.1: Device not responding to setup address.
[58836.286161] usb 4-2.1: Device not responding to setup address.
[58836.493991] usb 4-2.1: device not accepting address 3, error -71
[58836.842156] usb 4-2.1: Device not responding to setup address.
[58837.058154] usb 4-2.1: Device not responding to setup address.
[58837.265983] usb 4-2.1: device not accepting address 3, error -71
[58837.266075] scsi host3: uas_eh_device_reset_handler FAILED err -19
[58837.266082] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266084] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266085] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266087] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266088] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266089] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266090] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266091] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266092] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266093] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266094] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266095] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266096] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266098] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266099] sd 3:0:0:0: Device offlined - not ready after error recovery
[58837.266109] sd 3:0:0:0: [sdb] tag#9 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=83s
[58837.266112] sd 3:0:0:0: [sdb] tag#9 CDB: Synchronize Cache(10) 35 00 00 00 00 00 00 00 00 00
[58837.266112] usb 4-2.1: USB disconnect, device number 3
[58837.266117] blk_update_request: I/O error, dev sdb, sector 2523966464 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
[58837.266130] Aborting journal on device sdb7-8.
[58837.266132] sd 3:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=63s
[58837.266135] sd 3:0:0:0: [sdb] tag#18 CDB: Read(10) 28 00 be 8f 72 80 00 00 20 00
[58837.266136] blk_update_request: I/O error, dev sdb, sector 3197072000 op 0x0:(READ) flags 0x0 phys_seg 4 prio class 0
[58837.266145] sd 3:0:0:0: [sdb] tag#11 FAILED Result: hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=81s
[58837.266147] sd 3:0:0:0: [sdb] tag#11 CDB: Write(10) 2a 00 17 c2 74 00 00 00 08 00
[58837.266148] blk_update_request: I/O error, dev sdb, sector 398619648 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0
--------------------------------------------------------------------------------

This pointed to the UAS driver. Wikipedia [2] says:
  "The kernel has a built-in blacklist for devices with "quirks" defined
   in unusual_uas.h.[20] Temporary additional quirks can be added via procfs
   or kernel command line (usb-storage.quirks).[21]"

So, that's what I did: I added an option
  usb-storage.quirks=0bda:9210:u
to the kernel command line in /boot/grub/grub.cfg — and thus reached
an uptime of 90 days. The effect of this change in the 'lshw' output
was to replace the lines
                         capabilities: usb-3.20 scsi
                         configuration: driver=uas maxpower=896mA speed=10000Mbit/s
with the lines
                         capabilities: usb-3.20 scsi emulated scsi-host
                         configuration: driver=usb-storage maxpower=896mA speed=10000Mbit/s

When I rebooted after 90 days, Ubuntu's automatic upgrades had erased my
modifications to /boot/grub/grub.cfg, and as a consequence the crashes
started to occur again.


Do you need more info from me, in order to add an entry to
linux/drivers/usb/storage/unusual_uas.h ?


[1] https://www.amazon.com/-/en/dp/B09KMPYD9C/ref=sr_1_1
[2] https://en.wikipedia.org/wiki/USB_Attached_SCSI

Re: "SilverStone TS16" external SSD enclosing needs an UAS quirk

[Greg KH]

On Tue, Jan 16, 2024 at 12:35:46AM +0100, Bruno Haible wrote:
> TL;DR
> -----
> In my experience, the "SilverStone TS16" external SSD enclosing
> needs an UAS quirk
>   usb-storage.quirks=0bda:9210:u
> as part of the kernel command line. I hope you can add it
> to the file linux/drivers/usb/storage/unusual_uas.h .

Can you create a patch for this so that you get credit for the making
the fix?

thanks,

greg k-h

Re: "SilverStone TS16" external SSD enclosing needs an UAS quirk

[Lars Melin]

On 2024-01-16 21:13, Greg KH wrote:
> On Tue, Jan 16, 2024 at 12:35:46AM +0100, Bruno Haible wrote:
>> TL;DR
>> -----
>> In my experience, the "SilverStone TS16" external SSD enclosing
>> needs an UAS quirk
>>    usb-storage.quirks=0bda:9210:u
>> as part of the kernel command line. I hope you can add it
>> to the file linux/drivers/usb/storage/unusual_uas.h .
> 
> Can you create a patch for this so that you get credit for the making
> the fix?
> 
> thanks,
> 
> greg k-h

Replying to this since I did not get the original post.
0bda:9210 is a Realtek USB 3 to pcie chip used by umpteen
enclosure manufacturers.
I have got one from Orico and it works ok under both linux and MSWin but 
it can be a bit finicky if it doesn't get enough power, it may for 
instance work well with an earlier (slower) type of NVME SSD but not 
with a later faster type unless you provide external power to it (usb 
hub + power adapter).

Slowing down all RTL9120 already in the market with this quirk is in my 
humble opinion not a realistic solutio.

tnx

/Lars

Re: "SilverStone TS16" external SSD enclosing needs an UAS quirk

[Bruno Haible]

Lars Melin wrote:
> 0bda:9210 is a Realtek USB 3 to pcie chip used by umpteen
> enclosure manufacturers.

SilverStone TS16 is not the only one that makes problems. There's also
  - Sabrent NVMe M.2 enclosure (Model EC-SNVE) [1]
  - UnionSine Dual Protocol M2 NVMe to USB 3.1 [2]

> I have got one from Orico and it works ok under both linux and MSWin but 
> it can be a bit finicky if it doesn't get enough power, it may for 
> instance work well with an earlier (slower) type of NVME SSD but not 
> with a later faster type unless you provide external power to it (usb 
> hub + power adapter).

So, the Orico one has problems as well. Do these problems disappear when,
instead of changing the way it's connected to the computer, you add this
quirk?

> 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?

Bruno

[1] https://ubuntuforums.org/showthread.php?t=2466059
[2] https://forum.level1techs.com/t/nvme-to-usb-3-1-enclosure-buggy-in-linux-rtl9210b-chipset/199752

[PATCH] uas: Disable UAS driver for Realtek RTL9210 M.2 NVME Adapters

[Bruno Haible]

Various products that make use of the Realtek RTL9210 M.2 NVME Adapter:
  - SilverStone TS16
  - Sabrent NVMe M.2 enclosure (Model EC-SNVE)
  - UnionSine Dual Protocol M2 NVMe to USB 3.1
malfunction when the UAS driver is used. At least for the
SilverStone TS16, it works fine when the usb-storage driver is used.

In my case, the SilverStone TS16 is identified by this output of
"lsusb -v":
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.20
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         9
  idVendor           0x0bda Realtek Semiconductor Corp.
  idProduct          0x9210 RTL9210 M.2 NVME Adapter
  bcdDevice           20.01
  iManufacturer           1 Realtek
  iProduct                2 USB 3.1 Storage Device
  iSerial                 3 221010010470

Signed-off-by: Bruno Haible <bruno@clisp.org>
Link: https://lore.kernel.org/linux-usb/2270283.o7ts2hSHzF@nimes/
---
 drivers/usb/storage/unusual_uas.h | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h
index 1f8c9b16a0fb..5287c7a446f1 100644
--- a/drivers/usb/storage/unusual_uas.h
+++ b/drivers/usb/storage/unusual_uas.h
@@ -83,6 +83,13 @@ UNUSUAL_DEV(0x0bc2, 0x331a, 0x0000, 0x9999,
 		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
 		US_FL_NO_REPORT_LUNS),
 
+/* Reported-by: Bruno Haible <bruno@clisp.org> */
+UNUSUAL_DEV(0x0bda, 0x9210, 0x0000, 0x9999,
+		"Realtek",
+		"USB 3.1 Storage Device",
+		USB_SC_DEVICE, USB_PR_DEVICE, NULL,
+		US_FL_IGNORE_UAS),
+
 /* Reported-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> */
 UNUSUAL_DEV(0x13fd, 0x3940, 0x0000, 0x9999,
 		"Initio Corporation",
-- 
2.34.1

Re: "SilverStone TS16" external SSD enclosing needs an UAS quirk

[Alan Stern]

On Wed, Jan 17, 2024 at 08:59:29AM +0100, Bruno Haible wrote:
> Lars Melin wrote:
> > 0bda:9210 is a Realtek USB 3 to pcie chip used by umpteen
> > enclosure manufacturers.
> 
> SilverStone TS16 is not the only one that makes problems. There's also
>   - Sabrent NVMe M.2 enclosure (Model EC-SNVE) [1]
>   - UnionSine Dual Protocol M2 NVMe to USB 3.1 [2]
> 
> > I have got one from Orico and it works ok under both linux and MSWin but 
> > it can be a bit finicky if it doesn't get enough power, it may for 
> > instance work well with an earlier (slower) type of NVME SSD but not 
> > with a later faster type unless you provide external power to it (usb 
> > hub + power adapter).
> 
> So, the Orico one has problems as well. Do these problems disappear when,
> instead of changing the way it's connected to the computer, you add this
> quirk?
> 
> > 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.

Alan Stern

Re: "SilverStone TS16" external SSD enclosing needs an UAS quirk

[Bruno Haible]

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?

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.)

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".

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.

Bruno

Re: "SilverStone TS16" external SSD enclosing needs an UAS quirk

[Lars Melin]

On 2024-01-17 14:59, Bruno Haible wrote:
> Lars Melin wrote:
>> 0bda:9210 is a Realtek USB 3 to pcie chip used by umpteen
>> enclosure manufacturers.
> 
> SilverStone TS16 is not the only one that makes problems. There's also
>    - Sabrent NVMe M.2 enclosure (Model EC-SNVE) [1]
>    - UnionSine Dual Protocol M2 NVMe to USB 3.1 [2]
> 
>> I have got one from Orico and it works ok under both linux and MSWin but
>> it can be a bit finicky if it doesn't get enough power, it may for
>> instance work well with an earlier (slower) type of NVME SSD but not
>> with a later faster type unless you provide external power to it (usb
>> hub + power adapter).
> 
> So, the Orico one has problems as well. Do these problems disappear when,
> instead of changing the way it's connected to the computer, you add this
> quirk?

I can not check that now, the SSD that misbehaved if not connected via a 
powered USB Type C hub is not available to me now. I don't even know if 
I  would still have that particular problem now after having updated the 
firmware in the rtl9210 controller today.
It is very likely that the powered hub masked the real problem of an 
early and buggy firmware.

>> 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?

I propose that those who have a uas problem add a local quirk in their 
system.
If you google 0bda:9210 then you will find lot of people who have 
disconnect or no connect problem with their enclosure but you will also 
find lot of people who say that their enclosure works without any 
problems. They, and I, don't want your quirk in our systems..

Another option for you is to ask your mfgr for a firmware upgrade or
to search for and find one on the net (as I did).
The release notes especially mention fixes compatibility problems withr 
Samsung 980 pro and WD Black.

/Lars


> Bruno
> 
> [1] https://ubuntuforums.org/showthread.php?t=2466059
> [2] https://forum.level1techs.com/t/nvme-to-usb-3-1-enclosure-buggy-in-linux-rtl9210b-chipset/199752
> 
> 
> 

Re: "SilverStone TS16" external SSD enclosing needs an UAS quirk

[Alan Stern]

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