Hi all

 

I had a drive failure earlier this week that triggered a faulty parity check (it returned a bunch of errors). After checking the SMART report of that drive, I decided to replace it with a new 3TB WD Red. So I swapped the drive, and had it do a two-run preclear and allowed the array to run unprotected. For some reason though, about 18 hours into the preclear my array failed again now giving an error on my drive in slot 4. I'm pretty confident that drive is fine, I'm not seeing any bad SMART information either. I did a reboot since everything got stuck which 'resolved' the issue and the drive went back to a green ball. So I started reconstructing the data on the new drive, which was fine, until an hour later at which point the NEW drive red-balled.

 

I couldn't attach the diagnostic reports due to the file size. So here's the report from two days ago (before I swapped the drive), and here's the most recent report (where the reconstruction failed).

 

Could anyone shed some light on this? Many thanks in advance!

You're having issues with 4 devices: disks 3 and 4 and both cache SSDs, looks like they're all on the same Marvell controller, could be a bad controller, needs re-seating or the Marvell virtualization issue, if you don't use virtualization disable IOMMU in the bios.

You're having issues with 4 devices: disks 3 and 4 and both cache SSDs, looks like they're all on the same Marvell controller, could be a bad controller, needs re-seating or the Marvell virtualization issue, if you don't use virtualization disable IOMMU in the bios.

Thanks for getting back to me so quickly. That's interesting, UnRaid reports IOMMU as being disabled (HVM is on though), so it must be a controller issue then? Unfortunately, I cannot reseat the controller into another slot since I only have one PCI-E port available on my mainboard. Is there anything else I can try?

 

Thanks!

 

EDIT: This is the card: http://www.digitus.info/en/products/accessories/interface-cards/pc-interface-cards/sata-ide/sata-iii-pci-express-card-4-port-ds-30104-1/#!prettyPhoto[set]/0/

You can try re-seating it in the same slot to make sure it's snug, if you still have issues try a different controller.

I find I often have to bend the brackets on expansion cards a tiny amount to make them fit squarely. Sometimes, as you tighten the screw it actually levers the card slightly out of its slot. It's probably because I buy cheap cases!

So I tried reseating the card, making sure it is absolutely seated correctly, checked all cables, etc. No joy. I ordered a new card and replaced it earlier today. I decided to put the old disk in as well since it was the card that was faulty, not the disk, so Unraid was prompting me to rebuild my new 3TB drive (which is fine, whatever).

 

Though, I'm seeing really poor performance during this reconstruction. It's currently fluctuating around 10-15MBps, far from the performance I'm used to. I attached the diagnostics report, could someone take a look at let me know if anything is out of the ordinary?

 

Thanks in advance!

ziggy_unraid-diagnostics-20160826-1918.zip

Nothing obvious, you do have a disk with a SMART failing now attribute, but it's unassigned, and some cache filesystem corruption, probably caused by the other controller, neither would affect rebuild speed, don't see any other issues.

Thanks for assessing! The same thing as described in my original post just happened again with the new controller, I attached the syslog. I'm thinking motherboard?

ziggy_unraid-diagnostics-20160826-1958.zip

Are you sure virtualization is disable in the bios?

Are you sure virtualization is disable in the bios?

Unraid is reporting HVM is available, IOMMU unavailable: https://gyazo.com/1626e5f789939d68ddee96d9b83d08c5 . I can't find any mention of IOMMU in the BIOS, the closest thing to virtualisation I could find was SVM. It's weird that this issue started occurring all of the sudden. The previous card has been feeding 4 of my drives for nearly a year now. I should have mentioned that the replacement card is the exact same model as before.

Well, in that case maybe a bad board.

Well, in that case maybe a bad board.

Disabling SVM seems to have disabled virtualisation altogether. I ordered a new board and will replace if the issue happens again overnight. Will report back.

 

In the meantime, any other suggestions?

Can't think of anything else, maybe someone will have another idea.

So I just replaced the board, but my network connectivity is acting up so I can't reach the web interface... For some reason I am unable to communicate to other devices (both in and externally), and my Unraid box is also unreachable. I tried enabling DHCP to get a lease, that didn't give me anything to I reverted back to my manual IP.

 

This is what my /boot/config/network.cfg looks like: https://gyazo.com/afff79e05f947bc4dd05a715dc15959d . I'd post a syslog but can't really figure out how to do so without network access.

 

Also, this might be irrelevant for the issue, but I keep getting these kind of errors (or whatever they are) in the CLI: https://gyazo.com/7f33807dea27c49b666d462b5338115c . They seem to happen randomly and interup my flow when typing a command.

 

 

EDIT: this is the new board: http://www.gigabyte.com/products/product-page.aspx?pid=4591#ov

Try renaming network.cfg, a new one will be created with default settings.

 

The other errors indicate files system corruption on disk3, you need to run xfs_repair.

Try renaming network.cfg, a new one will be created with default settings.

 

The other errors indicate files system corruption on disk3, you need to run xfs_repair.

Renaming it and rebooting did not create a new network.cfg. It did however try to get a lease when booting, without success.

Do you have another NIC on the board?

Do you have another NIC on the board?

No sir, not right now. I used to have one in there though so there MIGHT be some traces still there.

Deleting network.cfg would take care of that, looks like you have a network issue.

Deleting network.cfg would take care of that, looks like you have a network issue.

I'm positive it's not a physical issue. DHCP works fine on a desktop I connect via the very same cable I'm using to test right now.

If you have one use another NIC, but you need to disable the onboard one in the bios.

If you have one use another NIC, but you need to disable the onboard one in the bios.

I tried exactly that, same result. I've been staring at this problem for a couple of hours already, I really have no clue what is causing this. Is it possible that the onboard NIC is powered by unsupported firmware?

If it was that the other one would work, assuming you disabled the onboard.

If it was that the other one would work, assuming you disabled the onboard.

I don't know what to tell ya. I put in a PCI NIC and disabled the onboard one. That said, maybe it'll work with the newly generated network.cfg . I'll try that now.

Still not getting a lease. It's also not creating a new network.cfg for me to try a manual IP.