July 17, 201015 yr Hello, I've spent a bunch of time trying to read through other posts to solve my issue. The issue I'm having is that my server seems to be working perfectly except it hangs whenever I run a parity check. It gets roughly 0.2% finished and then completely hangs. I can't ssh into it, hooking up a monitor to it does no good. And even if I have a monitor and keyboard hooked up in the beginning, they are unresponsive once the parity check locks up unRAID. I've read through this post several times: - http://lime-technology.com/forum/index.php?topic=6950.0 This person seemed to be having the exact same problem I am. So here are the things I've gathered which may make this process easier. Here's my hardware configuration: Mother Board: ASUS P5K-E LGA 775 Intel P35 ATX Intel Motherboard CPU: Intel Core 2 Duo E4600 Allendale 2.4GHz LGA 775 65W Dual-Core Processor BX80557E4600 GPU: SAPPHIRE 100208L Radeon HD 2600XT 256MB 128-bit GDDR3 PCI Express x16 HDCP Ready CrossFireX Support Video Card Memory: Crucial Ballistix 2GB (2 x 1GB) 240-Pin DDR2 SDRAM DDR2 800 (PC2 6400) Dual Channel Kit Desktop Memory Model BL2KIT12864AA804 Power Supply: OCZ StealthXStream OCZ600SXS 600W ATX12V / EPS12V SLI Ready Active PFC Power Supply HardDrives: 6 Seagate Barracuda 7200.11 ST31000340AS 1TB 7200 RPM SATA 3.0Gb/s 3.5 Hard Drives HardDrive: 1 Western Digital Caviar Green WD20EARS 2TB SATA 3.0Gb/s 3.5 Hard Drive SATA Controller: VIA VT6421A IDE & SATA RAID PCI Controller Card I have attached my syslog of when the server crashed while running a parity check. Unforunately, nothing looks useful to my untrained eyes which is why I need some help from the experts. The only other thing I can note is that I installed the sata controller about probably 4 months ago when I bought the WD Caviar Green drive for my parity drive. The parity check ran successfully at the time, so I figured the sata controller was fine. However, after about a month or so I was no longer able to run the check without locking up the server completely, but I can't find any evidence that the sata controller is the problem. I did however have everything up and running without the sata controller for probably a year without any parity check problems. Thanks for help. Appreciate it! syslog.last.txt.zip
July 18, 201015 yr I have attached my syslog of when the server crashed while running a parity check. Unforunately, nothing looks useful to my untrained eyes which is why I need some help from the experts. you have plenty of SATA error on disk @ ATA3 channel, you might want to (a) Run SMART test on this disk (b) replace cable to this disk © try to reassign this disk to different port Jul 17 13:31:54 Dwight kernel: ata3: SATA max UDMA/133 port i16@0xec00 bmdma 0xe400 irq 17 Jul 17 13:31:54 Dwight kernel: ata3.00: ATA-8: WDC WD20EARS-00S8B1, 80.00A80, max UDMA/133 Jul 17 13:31:54 Dwight kernel: ata3.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 0/32) Jul 17 13:31:54 Dwight kernel: ata3.00: configured for UDMA/133 Jul 17 13:33:21 Dwight kernel: mdcmd (35): check CORRECT Jul 17 13:33:21 Dwight kernel: md: recovery thread woken up ... Jul 17 13:33:21 Dwight kernel: md: recovery thread checking parity... Jul 17 13:33:21 Dwight kernel: md: using 1152k window, over a total of 1953514552 blocks. Jul 17 13:33:23 Dwight kernel: ata3.00: exception Emask 0x12 SAct 0x0 SErr 0x1000500 action 0x6 Jul 17 13:33:23 Dwight kernel: ata3.00: BMDMA stat 0x5 Jul 17 13:33:23 Dwight kernel: ata3: SError: { UnrecovData Proto TrStaTrns } Jul 17 13:33:23 Dwight kernel: ata3.00: failed command: READ DMA EXT Jul 17 13:33:23 Dwight kernel: ata3.00: cmd 25/00:00:3f:87:00/00:04:00:00:00/e0 tag 0 dma 524288 in Jul 17 13:33:23 Dwight kernel: res 51/84:ef:3f:87:00/84:02:00:00:00/e0 Emask 0x12 (ATA bus error) Jul 17 13:33:23 Dwight kernel: ata3.00: status: { DRDY ERR } Jul 17 13:33:23 Dwight kernel: ata3.00: error: { ICRC ABRT } Jul 17 13:33:23 Dwight kernel: ata3: hard resetting link Jul 17 13:33:23 Dwight kernel: ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Jul 17 13:33:23 Dwight kernel: ata3.00: configured for UDMA/133 Jul 17 13:33:23 Dwight kernel: ata3: EH complete Jul 17 13:33:23 Dwight kernel: ata3.00: exception Emask 0x12 SAct 0x0 SErr 0x1000500 action 0x6 Jul 17 13:33:23 Dwight kernel: ata3.00: BMDMA stat 0x5 Jul 17 13:33:23 Dwight kernel: ata3: SError: { UnrecovData Proto TrStaTrns } Jul 17 13:33:23 Dwight kernel: ata3.00: failed command: READ DMA EXT Jul 17 13:33:23 Dwight kernel: ata3.00: cmd 25/00:00:3f:90:00/00:04:00:00:00/e0 tag 0 dma 524288 in Jul 17 13:33:23 Dwight kernel: res 51/84:5f:3f:90:00/84:02:00:00:00/e0 Emask 0x12 (ATA bus error) [many following.......]
July 18, 201015 yr See also. http://linux.derkeiler.com/Mailing-Lists/Ubuntu/2010-01/msg00854.html In fact the hybrid via card was the first thing I suspected and it seems to lead to either the drive or the controller having issues. Try some of the boot time options(because a hard lock is a hardware compatibility issue) or try a different controller. There are PCIe x1 SATA controllers that can be purchased from newegg or monoprice for a small cost.
July 18, 201015 yr Author I ran the MemTest for 9 hrs and here are the stats: - WallTime: 8:52:20 - Cached: 2047M - RsvdMem: 572K - MemMap: e820-Std - Cache: on - ECC: off - Test: Std - Pass: 19 - Errors: 5632 - ECC Errs: 0 Then there are hundreds of red errors listed below it. I would save this out but I don't know how. Does this still point at a bad drive or sata controller? Thanks again for all the help.
July 19, 201015 yr No. That points to bad memory or wrong settings in BIOS for the memory. You can not troubleshoot any other part of the system until you correct the memory issues.
July 19, 201015 yr I ran the MemTest for 9 hrs and here are the stats: - WallTime: 8:52:20 - Cached: 2047M - RsvdMem: 572K - MemMap: e820-Std - Cache: on - ECC: off - Test: Std - Pass: 19 - Errors: 5632 - ECC Errs: 0 Then there are hundreds of red errors listed below it. I would save this out but I don't know how. Does this still point at a bad drive or sata controller? Thanks again for all the help. If those numbers are correct, i am surprised that your system doesn't crash and still able to run. Whole unRAID is running on RAM file system (aka in memory) so you need to correct any memory problem before proceed to next step. if you are not able to id which bank has problem, then try to unplug one at a time and re-run memtest until you see no error.
Archived
This topic is now archived and is closed to further replies.