June 8, 201016 yr Hi All, I am running unRaid 4.5.4 and I was moving files to server and it 'hung' would not respond to anything. On first reboot - Drive12 was showing as Blue. I simply rebooted the server for a second time. It is now doing a parity check. I am running the command. 'tail -f /var/log/syslog' as I was trying to see why system was crashing. The following message now keeps looping. Jun 8 20:23:43 Tower kernel: ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Jun 8 20:23:43 Tower kernel: ata6.00: configured for UDMA/33 Jun 8 20:23:43 Tower kernel: ata6: EH complete Jun 8 20:23:44 Tower kernel: ata6.00: exception Emask 0x50 SAct 0x0 SErr 0x280900 action 0x6 frozen Jun 8 20:23:44 Tower kernel: ata6.00: irq_stat 0x08000000, interface fatal error Jun 8 20:23:44 Tower kernel: ata6: SError: { UnrecovData HostInt 10B8B BadCRC } Jun 8 20:23:44 Tower kernel: ata6.00: failed command: READ DMA EXT Jun 8 20:23:44 Tower kernel: ata6.00: cmd 25/00:d0:c7:0a:bc/00:03:00:00:00/e0 tag 0 dma 499712 in Jun 8 20:23:44 Tower kernel: res 51/84:bf:d8:0b:bc/00:02:00:00:00/e0 Emask 0x50 (ATA bus error) Jun 8 20:23:44 Tower kernel: ata6.00: status: { DRDY ERR } Jun 8 20:23:44 Tower kernel: ata6.00: error: { ICRC ABRT } Jun 8 20:23:44 Tower kernel: ata6: hard resetting link Which Drive is this that is causing issues? I believe it is Disk_12? Should I let Parity check finish? What should I kick myself for doing wrong? syslog-2010-06-08.zip Disk_12.txt
June 9, 201016 yr Author Parity stopped building and Disk12 is now showing as Red. Do I just replace this drive or is Parity invalid now?
June 9, 201016 yr Parity stopped building and Disk12 is now showing as Red. Do I just replace this drive or is Parity invalid now? Don't do ANYTHING yet... I just opened up the syslog to examine it. I've not yet had the chance, but wanted to post first to keep you from doing something that would make recovery impossible. The one error you posted was a CRC error. That usually indicates the cable between the disk and the controller is the issue. It could be as simple as re-seating it and then letting the drive be re-constructed. If the drive is now "red" it indicates a "write" to it failed so it is now out-of date. Parity is correct however, so the only way to get the file you were writing will be to let it re-construct the contents. Do not do anything... not until I make the next post. Your parity is probably perfectly fine. In fact, you can see if you can browse to the contents of the disk with the red indicator. (disk12) If you can see the contents then it is because it is being simulated by reading parity and all the other data disks on your server. Joe L.
June 9, 201016 yr Author Greatly appreciated not in a huge hurry. Why can't computers learn to break in the winter time when there is less stuff to do. Thanks for the tip on checking Drive12 everything shows up so Parity is good. I will check in the morning for any steps to take.
June 9, 201016 yr The first error was here: Jun 8 15:57:07 Tower kernel: ata17.00: exception Emask 0x50 SAct 0x0 SErr 0x280900 action 0x6 Jun 8 15:57:07 Tower kernel: ata17.00: BMDMA stat 0x26 Jun 8 15:57:07 Tower kernel: ata17: SError: { UnrecovData HostInt 10B8B BadCRC } Jun 8 15:57:07 Tower kernel: ata17.00: failed command: READ DMA Jun 8 15:57:07 Tower kernel: ata17.00: cmd c8/00:00:4f:85:96/00:00:00:00:00/e1 tag 0 dma 131072 in Jun 8 15:57:07 Tower kernel: res 51/84:00:4f:85:96/00:00:00:00:00/e1 Emask 0x70 (host bus error) Jun 8 15:57:07 Tower kernel: ata17.00: status: { DRDY ERR } Jun 8 15:57:07 Tower kernel: ata17.00: error: { ICRC ABRT } Jun 8 15:57:07 Tower kernel: ata17: hard resetting link Jun 8 15:57:08 Tower kernel: ata17: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jun 8 15:57:08 Tower kernel: ata17.00: configured for UDMA/133 Jun 8 15:57:08 Tower kernel: ata17: EH complete Jun 8 15:57:09 Tower kernel: ata17.00: exception Emask 0x10 SAct 0x0 SErr 0x280100 action 0x6 Jun 8 15:57:09 Tower kernel: ata17.00: BMDMA stat 0x26 Jun 8 15:57:09 Tower kernel: ata17: SError: { UnrecovData 10B8B BadCRC } Jun 8 15:57:09 Tower kernel: ata17.00: failed command: READ DMA EXT Jun 8 15:57:09 Tower kernel: ata17.00: cmd 25/00:00:af:80:97/00:04:01:00:00/e0 tag 0 dma 524288 in Jun 8 15:57:09 Tower kernel: res 51/84:5f:af:80:97/84:00:00:00:00/e0 Emask 0x30 (host bus error) Jun 8 15:57:09 Tower kernel: ata17.00: status: { DRDY ERR } Jun 8 15:57:09 Tower kernel: ata17.00: error: { ICRC ABRT } Jun 8 15:57:09 Tower kernel: ata17: hard resetting link Jun 8 15:57:10 Tower kernel: ata17: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jun 8 15:57:10 Tower kernel: ata17.00: configured for UDMA/133 Jun 8 15:57:10 Tower kernel: ata17: EH complete ata17 is "sd 17:0:0:0" and assigned /dev/sdr Jun 8 16:25:31 Tower kernel: ata17.00: error: { ICRC ABRT } Jun 8 16:25:31 Tower kernel: ata17: hard resetting link Jun 8 16:25:32 Tower kernel: ata17: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Jun 8 16:25:32 Tower kernel: ata17.00: configured for UDMA/33 Jun 8 16:25:32 Tower kernel: sd 17:0:0:0: [sdr] Result: hostbyte=0x00 driverbyte=0x08 Jun 8 16:25:32 Tower kernel: sd 17:0:0:0: [sdr] Sense Key : 0xb [current] [descriptor] Jun 8 16:25:32 Tower kernel: Descriptor sense data with sense descriptors (in hex): Jun 8 16:25:32 Tower kernel: 72 0b 47 00 00 00 00 0c 00 0a 80 00 00 00 00 00 Jun 8 16:25:32 Tower kernel: 00 50 c2 b7 Jun 8 16:25:32 Tower kernel: sd 17:0:0:0: [sdr] ASC=0x47 ASCQ=0x0 Jun 8 16:25:32 Tower kernel: sd 17:0:0:0: [sdr] CDB: cdb[0]=0x28: 28 00 04 50 c2 b7 00 04 00 00 Jun 8 16:25:32 Tower kernel: end_request: I/O error, dev sdr, sector 72401591 The read errors seem to be on disk0 (your parity drive) Jun 8 16:25:32 Tower kernel: md: disk0 read error Jun 8 16:25:32 Tower kernel: ata17: EH complete Jun 8 16:25:32 Tower kernel: handle_stripe read error: 72401528/0, count: 1 Jun 8 16:25:32 Tower kernel: md: disk0 read error Jun 8 16:25:32 Tower kernel: handle_stripe read error: 72401536/0, count: 1 Jun 8 16:25:32 Tower kernel: md: disk0 read error Jun 8 16:25:32 Tower kernel: handle_stripe read error: 72401544/0, count: 1 Jun 8 16:25:32 Tower kernel: md: disk0 read error Jun 8 16:25:32 Tower kernel: handle_stripe read error: 72401552/0, count: 1 Jun 8 16:25:32 Tower kernel: md: disk0 read error Jun 8 16:25:32 Tower kernel: handle_stripe read error: 72401560/0, count: 1 Jun 8 16:25:32 Tower kernel: md: disk0 read error Jun 8 16:25:32 Tower kernel: handle_stripe read error: 72401568/0, count: 1 Jun 8 16:25:32 Tower kernel: md: disk0 read error Jun 8 16:25:32 Tower kernel: handle_stripe read error: 72401576/0, count: 1 Jun 8 16:25:32 Tower kernel: md: disk0 read error Ok, it looks like you have two different issues. One involving disk12, the other your parity disk. I strongly suspect that when you replaced disk12 you dislodged the cable to the parity disk. So.... Stop the array Power down Check the cabling on BOTH disk12 and the parity drive. Power back up. We need to let unRAID reconstruct disk12. But first, let's get a smart report on both it and on eht parity drive to establish the cabling to them is functional once you re-seated them. Then, To get the array to think disk12 is new so it will again re-construct onto it: Stop the array On the "Devices" page, un-assign disk12 Go back to the main page, press "Start" to start the array without disk12 assigned. This will cause it to forget the model/serial number of disk12. The contents of disk12 will be simulated by parit and all the other data disks. Stop the array once more. On the "Devices" page, re-assign disk12. On the main page, press "Start" to begin the re-construction of disk12 onto itself. Post to get advice if anything is different than what I've described. Joe L.
June 10, 201016 yr Author Here are the smart reports from Disk12 and Parity I have not completed the second part of removing Disk12 and then re-adding it letting unRaid rebuild on itself, I will wait to confirm smart reports look ok or if needed replace drive. Thanks in advance. Disk12.txt Smart_Check_Parity.txt
June 10, 201016 yr Author Disk12 is now rebuilding data after following your process Joe thank you very much.
Archived
This topic is now archived and is closed to further replies.