diff options
1 files changed, 0 insertions, 4 deletions
| -rw-r--r-- | src/blog/fix-qc-timeout/index.du | 4 |
diff --git a/src/blog/fix-qc-timeout/index.du b/src/blog/fix-qc-timeout/index.du index 42ee9c1..68e290d 100644 --- a/src/blog/fix-qc-timeout/index.du +++ b/src/blog/fix-qc-timeout/index.du @@ -41,21 +41,17 @@ libata.force=3.01:nodmalog :note ### Update 20 August 2025 -.p About a month ago I stumbled upon this {url mailing list;https://de.comp.hardware.laufwerke.festplatten.narkive.com/F8WstP5i/fix-frage-zu-sata-read-log-0x00-page-0x00-failed-emask-0x40} (Google-powered translation to English {url here;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}). -.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. |