as soon as a parity check starts, I see these error in the log:

Jul 6 13:37:07 unraid kernel: md: recovery thread: check P Q ...

Jul 6 13:37:45 unraid kernel: ata2.00: exception Emask 0x50 SAct 0x7ff00001 SErr 0x4890800 action 0xe frozen

Jul 6 13:37:45 unraid kernel: ata2.00: irq_stat 0x04400040, connection status changed

Jul 6 13:37:45 unraid kernel: ata2: SError: { HostInt PHYRdyChg 10B8B LinkSeq DevExch }

Jul 6 13:37:45 unraid kernel: ata2.00: failed command: READ FPDMA QUEUED

Jul 6 13:37:45 unraid kernel: ata2.00: cmd 60/40:00:40:b5:9b/01:00:00:00:00/40 tag 0 ncq dma 163840 in

Jul 6 13:37:45 unraid kernel: res 40/00:01:04:06:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)

Jul 6 13:37:45 unraid kernel: ata2.00: status: { DRDY }

Jul 6 13:37:45 unraid kernel: ata2.00: failed command: READ FPDMA QUEUED

Jul 6 13:37:45 unraid kernel: ata2.00: cmd 60/00:a0:80:96:9b/04:00:00:00:00/40 tag 20 ncq dma 524288 in

Jul 6 13:37:45 unraid kernel: res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x50 (ATA bus error)

....

Jul 6 13:37:45 unraid kernel: ata2: hard resetting link

Jul 6 13:37:45 unraid kernel: ata3.00: exception Emask 0x50 SAct 0x400007ff SErr 0x4890800 action 0xe frozen

Jul 6 13:37:45 unraid kernel: ata3.00: irq_stat 0x04400040, connection status changed

Jul 6 13:37:45 unraid kernel: ata3: SError: { HostInt PHYRdyChg 10B8B LinkSeq DevExch }

Jul 6 13:37:45 unraid kernel: ata3.00: failed command: READ FPDMA QUEUED

Jul 6 13:37:45 unraid kernel: ata3.00: cmd 60/00:00:80:9a:9b/04:00:00:00:00/40 tag 0 ncq dma 524288 in

Jul 6 13:37:45 unraid kernel: res 40/00:01:30:02:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)

Jul 6 13:37:45 unraid kernel: ata3.00: status: { DRDY }

Jul 6 13:37:45 unraid kernel: ata3.00: failed command: READ FPDMA QUEUED

I tried this also in maintenance mode, same result.

after immediately cancelling the parity check, I see this:

Jul 6 13:37:51 unraid kernel: mdcmd (37): nocheck cancel

Jul 6 13:37:51 unraid kernel: ata3: link is slow to respond, please be patient (ready=0)

Jul 6 13:37:51 unraid kernel: ata2: link is slow to respond, please be patient (ready=0)

Jul 6 13:37:55 unraid kernel: ata2: hard resetting link

Jul 6 13:37:55 unraid kernel: ata3: hard resetting link

Jul 6 13:38:00 unraid kernel: ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Jul 6 13:38:00 unraid kernel: ata2.00: configured for UDMA/133

Jul 6 13:38:00 unraid kernel: ata2: EH complete

Jul 6 13:38:01 unraid kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Jul 6 13:38:01 unraid kernel: ata3.00: configured for UDMA/133

Jul 6 13:38:01 unraid kernel: ata3: EH complete

Jul 6 13:38:02 unraid kernel: ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Jul 6 13:38:02 unraid kernel: ata6.00: configured for UDMA/133

Jul 6 13:38:03 unraid sSMTP[15179]: Creating SSL connection to host

Jul 6 13:38:03 unraid sSMTP[15179]: SSL connection using TLS_AES_256_GCM_SHA384

Jul 6 13:38:05 unraid kernel: md: recovery thread: exit status: -4

any idea, what could be wrong?

unraid-diagnostics-20260706-1338.zip

D

That typically indicates an issue either with the cabling to the drive or a power issue rather than anything wrong with the dtive itself.

Errors come from disks 7 and 8, do they share anything in common, like a power splitter? If not, replace the cables for both.

I changed both power supplies for disk 7 and 8. it happened again. only a little later. are still the same disks affected? any other theories?

unraid-diagnostics-20260706-2131.zip

Disks 4 and 7 currently.

disk 7 and 4 are connected to the same power supply after the reconfiguration. But not to the same controller.

I will try another power supply. this is really strange and hard to debug.