WH16NS40 hardware timeout mid-rip on both USB and SATA - laser/servo wear?

[OmegaBiscuit]

Drive: LG/Hitachi-LG WH16NS40, cross-flashed to LibreDrive-enabled firmware, currently running firmware 1.02
Setup: ARM (Automatic Ripping Machine) on Debian, drive on a QNAP QXP-800eS-A1164 HBA (ASM1164, native AHCI/SATA) in a DupliM 7-bay enclosure, previously on USB
Drive history: Bought new in August 2024, sat mostly unused, only started seeing real use in the past month after setting up ARM

Symptom, phase 1 — read timeouts during rips:

The drive reads cleanly through the first 4-5 titles of a multi-title Blu-ray disc, then fails after roughly 35-55 minutes of sustained reading with:

Code: Select all

Scsi error - HARDWARE ERROR:TIMEOUT ON LOGICAL UNIT
Scsi error - HARDWARE ERROR:LOGICAL UNIT HAS NOT SELF-CONFIGURED YET

What I've ruled out on this phase:

This was originally on USB, and I suspected a bridge chip or cabling issue, so I tested extensively:

• Two different USB enclosures (different brands, different bridge chipsets)
• Two different cables
• Two different USB ports/controllers on the host (a standard USB-A port and a USB4 port)

The failure reproduced identically regardless of which of these changed, so the fault followed the drive, not the connection.

To eliminate USB entirely, I moved the drive to native SATA via a PCIe HBA (ASMedia ASM1164, native AHCI, not SAS/STP). The drive still failed the same way on native SATA. This rules out USB bridge chips, cables, enclosures, and ports as the cause.

I also had a specific UHD disc fail 3 separate times at the identical byte offset (63660029952) with MEDIUM ERROR:L-EC UNCORRECTABLE ERROR on this drive. I suspected a disc defect at first, but I've since successfully ripped that same disc, along with another disc that failed on this drive, on a different drive (a Pioneer BDR-209, cross-flashed to BDR-211M firmware) with no issues. So the discs themselves are fine, this points at the WH16NS40.

Symptom, phase 2 — full link dropout while idle:

More recently, the drive escalated from read timeouts to dropping off the SATA bus completely, and this happened while the drive was idle with no disc loaded, not mid-rip. dmesg shows the kernel's ATA error handler trying progressively slower link speeds to recover it:

Code: Select all

ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata4: hard resetting link
ata4.00: qc timeout after 15000 msecs (cmd 0xef)
ata4.00: failed to set xfermode (err_mask=0x4)
ata4.00: limiting speed to UDMA/133:PIO3

This repeated, stepping down UDMA/133 → PIO3 → PIO2 → PIO1, every attempt timing out, until the kernel gave up completely:

Code: Select all

ata4.00: qc timeout after 15000 msecs (cmd 0xef)
ata4.00: disable device

At that point the drive was fully unresponsive, not just erroring on reads. "lsscsi" still listed it (stale kernel state), but a direct SCSI inquiry confirmed it was actually gone:

Code: Select all

$ sudo sg_inq /dev/sr3
sg_inq failed: Transport error

I power cycled the DupliM enclosure to try to recover it. The drive came back immediately, cleanly re-identified at the same firmware (1.02), and MakeMKV sees it again with no errors:

Code: Select all

ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata4.00: ATAPI: HL-DT-ST BD-RE  WH16NS40, 1.02, max UDMA/133
ata4.00: configured for UDMA/133

Full picture:

1. Drive works fine for a while, then throws read timeouts under sustained use (~35-60 min into a rip)
2. At some later point, even idle and empty, the kernel's own recovery attempts get triggered and fail (link resets at decreasing speeds, all timing out)
3. Kernel gives up and disables the device entirely, unresponsive to even basic SCSI inquiry
4. A full power cycle of the enclosure fully recovers it, correct firmware ID, no corruption, MakeMKV sees it fine again

The idle dropout makes me less confident this is purely heat/sustained-load related, though it's possible the controller was left in a bad state from earlier timeouts and only fully locked up later. Either way, the drive isn't dead: it reliably re-identifies at the same firmware with no corruption after nothing more than a power cycle.

Question:

Has anyone seen this failure pattern on a WH16NS40 before, read timeouts progressing to a full unresponsive lockup that only clears with a power cycle? Is this recoverable (firmware reflash, laser adjustment, etc.) or does it point to a specific failing component? Any diagnostics worth running before I write this drive off?

Happy to provide full dmesg output, MakeMKV debug logs, or anything else useful.

Note: I had Claude (AI) help me write up this post, I have ADHD and writing things out clearly is a struggle for me. All the technical details and troubleshooting are my own.