feat(blog/fix-qc-timeout): Add update from a mailing list discussion

2 files changed, 26 insertions, 5 deletions

diff --git a/dunbar b/dunbar
-Subproject f6af66a623cb9edef50d260cd77865e422e5206
+Subproject e53da325d843f5b5126316867c804cc7b056eb1
diff --git a/src/blog/fix-qc-timeout/index.du b/src/blog/fix-qc-timeout/index.du
index d36383d..d882d15 100644
--- a/src/blog/fix-qc-timeout/index.du
+++ b/src/blog/fix-qc-timeout/index.du
@@ -2,7 +2,7 @@
 
 'define expected-reading 4 min
 'define created 16 December 2023
-'define edited 16 December 2023
+'define edited 20 August 2025
 [$pagenav]
 
 Depending on your harddrive, you may get a 15 second delay on boot.
@@ -38,6 +38,27 @@ libata.force=3.01:nodmalog
 
 ## Explanation
 
+:note
+### Update 20 August 2025
+
+.p
+About a month ago I stumbled upon this [url https://de.comp.hardware.laufwerke.festplatten.narkive.com/F8WstP5i/fix-frage-zu-sata-read-log-0x00-page-0x00-failed-emask-0x40 mailing list] (Google-powered translation to English [url https://de-comp-hardware-laufwerke-festplatten-narkive-com.translate.goog/F8WstP5i/fix-frage-zu-sata-read-log-0x00-page-0x00-failed-emask-0x40?_x_tr_sl=bg&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp here]).
+
+.p
+A user had the same issue as outlined in this post and were discussing the situation.
+Their problematic SSD was a "TEAM L7 EVO SSD 60GB", which incidentally is the exact model which caused me trouble.
+
+.p
+Since it is the same (and as far as I know, the only) device with this behaviour, I believe it is a hardware bug as a responder suggested:
+
+.quote
+They must have messed up the implementation of the ATA READ LOG DMA EXT command. This causes the firmware to freeze, and after a
+while, the kernel triggers a link reset, which revives it.
+
+.p
+I'm leaving my original explanation, since some of it is still true.
+
+
 .important
 The following is how I understand the issue, but I did not find definitive proof thats exactly what happens.\n
 Take this section with a grain of salt.
@@ -47,14 +68,14 @@ With DMA, the CPU could ask the drive for everythng it wants (not a tiny bit), a
 The benefit is that the CPU can do other work while the transfer is going on, greatly improving efficiency, but the downside is that the harddrive has to support it (have a DMAC chip on it).
 
 Normally it would be useful for the DMAC to keep logs in a special place on the drive.
-This is where the issue comes from: your harddrive supports DMA but does not support logs for it.
+~[This is where the issue comes from: your harddrive supports DMA but does not support logs for it.
 However, the Linux kernel has no good way of knowing that, there is no "property" on the drive which tells us this.
-The only way is to try and read from that log: if it succeeds, then there is support, if it fails, then there isn't.
+The only way is to try and read from that log: if it succeeds, then there is support, if it fails, then there isn't.]~
 
-But what does it mean to fail?
+~[But what does it mean to fail?
 The simplest definition would be for the drive to return an error singal, but in our case, the drive would just not return anything, ignoring our request.
 In that case, how would we know if the drive just doesn't know how to respond (meaning it doesn't support the logs) or if it's just very slow?
-Well, we can't, so we put a time limit, if it doesn't respond in 15 seconds, then it probably doesn't support it.
+Well, we can't, so we put a time limit, if it doesn't respond in 15 seconds, then it probably doesn't support it.]~
 
 That's what the error is saying: `[qc]` is short for [url https://docs.kernel.org/driver-api/libata.html#origins-of-commands "queued command"], it's used to represent a (S)ATA command (hence the `[cmd]` at the end, telling us which command it's referring to).
 So, the kernel is telling us "The hard drive (ATA) command to read (DMA) logs timed out after 15 seconds" (it first says a command timed out, then it says which one).