I'm having various errors since upgrading to 6.3.3

 

Upgrade went ok until normal monthly parity check happened on first of month. Parity check failed, Disk 5 had Red X, and Disk 4 sowed as being unmountable. Tried various things to fix with no luck.

Tried rebuilding parity on Disk 5 but parity check only running at 3KB/sec. Would have taken years to finish.

Tried XFS-repair on Disk 4, but still was unmountable.

Swapped cables for disk 5, no help.

Tried different port on sata card, no help.

 

Was finally able to return the array to "normal" by doing the following steps.

 

1. Replaced Disk 5 with new unformatted drive and rebuilt parity. (Disk 4 was still showing as unmountable during parity rebuild, but parity rebuild completed and returned Disk 5 to Green.

2. Started array in maintenance mode and ran XFS_repair with Lv option to correct corrupted file system on Disk 4. That succeeded as well after the parity rebuild completed.

     

At that point, array looked good with parity valid, and all data intact.

 

Checked original Disk 5 with SMART and other tools and can find no hardware problems with the drive, so it looks like something got corrupted on that drive as well as Disk 4.

 

Now however, trying to run final parity check, and throughput severely degraded again and gets slower as parity check progresses. Drive 5 is definitely getting errors and constant retrys are happening. However, at this point it is a new drive, new data cable, and different port on sata card.

 

Log shows following errors.

Apr 4 15:01:08 Tower kernel: ata10.00: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
Apr 4 15:01:08 Tower kernel: ata10.00: irq_stat 0x80400000, PHY RDY changed
Apr 4 15:01:08 Tower kernel: ata10: SError: { PHYRdyChg }
Apr 4 15:01:08 Tower kernel: ata10.00: failed command: READ DMA EXT
Apr 4 15:01:08 Tower kernel: ata10.00: cmd 25/00:40:20:f8:00/00:05:01:00:00/e0 tag 9 dma 688128 in
Apr 4 15:01:08 Tower kernel: res 80/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x12 (ATA bus error)
Apr 4 15:01:08 Tower kernel: ata10.00: status: { Busy }
Apr 4 15:01:08 Tower kernel: ata10: hard resetting link
Apr 4 15:01:08 Tower kernel: ata10: SATA link down (SStatus 0 SControl 310)
Apr 4 15:01:12 Tower kernel: ata10: hard resetting link
Apr 4 15:01:13 Tower kernel: ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 310)
Apr 4 15:01:13 Tower kernel: ata10.00: configured for UDMA/33
Apr 4 15:01:13 Tower kernel: ata10: EH complete
Apr 4 15:01:15 Tower kernel: ata10.00: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen
Apr 4 15:01:15 Tower kernel: ata10.00: irq_stat 0x80400000, PHY RDY changed
Apr 4 15:01:15 Tower kernel: ata10: SError: { PHYRdyChg }
Apr 4 15:01:15 Tower kernel: ata10.00: failed command: READ DMA EXT
Apr 4 15:01:15 Tower kernel: ata10.00: cmd 25/00:40:90:c8:09/00:05:01:00:00/e0 tag 1 dma 688128 in
Apr 4 15:01:15 Tower kernel: res 80/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x12 (ATA bus error)
Apr 4 15:01:15 Tower kernel: ata10.00: status: { Busy }
Apr 4 15:01:15 Tower kernel: ata10: hard resetting link
Apr 4 15:01:16 Tower kernel: ata10: SATA link down (SStatus 0 SControl 310)
Apr 4 15:01:20 Tower kernel: ata10: hard resetting link
Apr 4 15:01:20 Tower kernel: ata10: SATA link up 6.0 Gbps (SStatus 133 SControl 310)
Apr 4 15:01:20 Tower kernel: ata10.00: configured for UDMA/33
Apr 4 15:01:20 Tower kernel: ata10: EH complete
Apr 4 15:01:20 Tower kernel: mdcmd (74): nocheck 
Apr 4 15:01:20 Tower kernel: md: md_do_sync: got signal, exit...
Apr 4 15:01:20 Tower kernel: md: recovery thread: completion status: -4
Apr 4 15:02:02 Tower sSMTP[6470]: Creating SSL connection to host
Apr 4 15:02:02 Tower sSMTP[6470]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256

 

Diagnostics are attached. Errors are still on ATA10 (Disk5), but since it's a different disk, cable, and port I am not sure where to look from here.

 

Any help is appreciated.

 

Thanks.

 

tower-diagnostics-20170404-1504.zip

Have the issues been limited to devices on the Marvell controller? These have known problems with unRAID v6, especially with VT-D enable.

Both Disk 4 and Disk 5 are connected to the Marvell controller. I have had the controller for awhile though, and they are just happening now. Can a new kernel or Unraid release cause the issues to appear with the Marvell controller?

Yes, it happens frequently, any small change, hardware or software, can trigger the issues.

Ok. Thank You. I will look to replace the controller with something not based on Marvell.

You can also try disabling vt-d (if not needed), looking for a bios update and/or using the controller in a different pcie slot if available.