After a recent OS upgrade (to current Tumbleweed, Linux Kernel 4.16.0 from April 4th), when reading from a faulty hard disk or from damaged/scratched DVDs, I don't get anymore read errors in the software, but instead the buffer in the affected sectors is all Zeroes. In dmesg I see that there are medium errors reported, à la

[10767.201905] ata6.00: exception Emask 0x0 SAct 0x2000000 SErr 0x0 action 0x0
[10767.201912] ata6.00: irq_stat 0x40000008
[10767.201918] ata6.00: failed command: READ FPDMA QUEUED
[10767.201926] ata6.00: cmd 60/08:c8:b8:9b:1e/00:00:2b:01:00/40 tag 25 ncq dma 4096 in
                        res 41/40:08:b8:9b:1e/00:00:2b:01:00/00 Emask 0x409 (media error) <F>
[10767.201930] ata6.00: status: { DRDY ERR }
[10767.201933] ata6.00: error: { UNC }
[10767.204339] ata6.00: configured for UDMA/133
[10767.204354] sd 5:0:0:0: [sde] tag#25 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[10767.204357] sd 5:0:0:0: [sde] tag#25 Sense Key : Medium Error [current]   
[10767.204359] sd 5:0:0:0: [sde] tag#25 Add. Sense: Unrecovered read error - auto reallocate failed
[10767.204362] sd 5:0:0:0: [sde] tag#25 CDB: Read(16) 88 00 00 00 00 01 2b 1e 9b b8 00 00 00 08 00 00
[10767.204394] ata6: EH complete

Other than the message in the log (and the longer access time), there is no indication that something went wrong. Does an AHCI/ATA option exist to enable such a behavior? It is quite unsuspected and mightily unwelcome, as I don’t want to check for errors in the log, but rather have the copy fail at the point where it occurs (otherwise, tools like ddrescue don’t make sense either, as they also don’t detect read errors anymore)

Are there boot options? Compile options?

Update: a recent System Upgrade (SuSE tumbleweed) to a new kernel solved the problem.

  • Wow. If this is a recent upgrade, do you still have the "good" kernel accessible in the boot menu? And if so what is it? Not sure what to suggest to rule out that you're getting a successful retry that returns all zeros, sorry. – sourcejedi Apr 24 '18 at 21:51
  • might be possible to dig into it with blktrace, in that it shows scsi commands, so it should show the failing scsi command, and then tell you what happened after. I.e. if there's no retry at the scsi ("pc") level, but you get a non-error response at the higher level ("fs"), something's weird! This assumes that you can identify the failing request in blktrace output. Afraid I can't remember exactly how and the docs aren't very friendly on that point; you might have to be a bit smart. – sourcejedi Apr 24 '18 at 22:00
  • if you're up for building kernels and bisecting, that should tell you who to blame, after about 15 builds. To be clear, I'm agreeing that what you're accusing would be a bug, if it applies generally. (If it's more hardware-specific, it might be the hardware that is buggy). – sourcejedi Apr 24 '18 at 22:13
  • 1
    In the 4.14 kernel, it works still as expected. In the dmesg output, right before EH complete, it prints "I/O error, dev sde, sector 3457005544" and "Buffer I/O error on dev sde, logical block 432125693, async page read".... So yes, this must be directly in the kernel... very strange. I’ll try bisecting... but it will take some time. – Ro-ee Apr 24 '18 at 23:25
  • looking at AHCI following v4.14, I think there's a second LPM change in v4.16 which is potentially enabled by default (on laptops). Are you on a laptop? github.com/torvalds/linux/commit/… If this possibility applies, it should show as a difference between your kernels in the output of cat /sys/class/scsi_host/host*/link_power_management_policy. And you can probably disable the effect for testing purposes by booting with the kernel option ahci.mobile_lpm_policy=1. – sourcejedi Apr 25 '18 at 9:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.