July 17, 200619 yr I was copying something over to the unRaid, went away and came back to find a "network drive disconnected" error. I have the unRaid and other PC running off a UPS, so I don't think it was a power issue, but I couldn't "see" the unRaid although the power light was on, and it wouldn't accept any keyboard commands. So I hard rebooted, and it started doing a parity check. However, about 15 - 30 minutes into the parity check it seemed to hang again: browser manager wasn't returning anything and it wasn't accepting any keyboard commands. On my box, there's a red light which indicates disk activity, and I believe it indicates activity on the parity disk, which is hooked up to the motherboard IDE channel. What happens is that the red light flashes for those 15-30 minutes, and once it stops, it seems the unRaid has stopped responding. I hard rebooted again and this time while it was doing the parity check I used the browser manager to stop the check and then shut down the array before powering off. When I restarted, the array seemed to be fine (all disks reported as OK), but now I want to do another parity check. My question is whether the parity check should involve constant parity drive access (which I would expect) or whether the parity drive access pauses sometimes for long spells (in which case I've just been too impatient).
July 17, 200619 yr I would say do a parity check and go to work or bed and check it in the afternoon or morning. I believe a parity check can take a few hours depending on the size of your drives. As for blinking lights I've never paid close attention to mine.
July 17, 200619 yr sonofdbn, Before starting the parity check, you should open a telnet window with the server and request the display of the syslog (tail -f /var/log/syslog) so that you can see what is causing it to hang if it hangs again. This way you will have a log of what has happened and can send it to Tom to get a reading on what is taking place. Just a thought. Regards, TCIII
July 17, 200619 yr sonofdbn, Before starting the parity check, you should open a telnet window with the server and request the display of the syslog (tail -f /var/log/syslog) so that you can see what is causing it to hang if it hangs again. This way you will have a log of what has happened and can send it to Tom to get a reading on what is taking place. Just a thought. Regards, TCIII If ever a server requires a "hard reboot" this is good advice to open a telnet window and monitor things, especially if you can repeat the action you thought might have caused the "hang". Regarding parity disk activity: duing parity sync/check, the parity disk will be constantly accessed; there should be no extended pauses.
July 18, 200619 yr Author Thanks very much for the suggestions. The syslog is below. When I restarted the unRaid started doing a parity check before I made the telnet connection. I think that's where the "nocheck" comes from. Then I started the parity check. ======================================================================= Tower login: root Linux 2.4.29. root@Tower:~# root@Tower:~# tail -f /var/log/syslog Jul 18 08:26:01 Tower kernel: reiserfs: checking transaction log (device md(9,11 )) ... Jul 18 08:26:01 Tower kernel: for (md(9,11)) Jul 18 08:26:01 Tower kernel: md(9,11):Using r5 hash to sort names Jul 18 08:26:01 Tower kernel: md(9,11):can't shrink filesystem on-line Jul 18 08:26:05 Tower kernel: spurious 8259A interrupt: IRQ15. Jul 18 08:27:02 Tower kernel: get_token: status Jul 18 08:27:08 Tower kernel: get_token: nocheck Jul 18 08:27:08 Tower kernel: md: writing superblock to device sda2 Jul 18 08:27:08 Tower kernel: md: recovery thread sync completion status: -4 Jul 18 08:27:08 Tower kernel: get_token: status Jul 18 08:28:30 Tower kernel: get_token: check Jul 18 08:28:30 Tower kernel: md: recovery thread checking parity... Jul 18 08:28:30 Tower kernel: md: writing superblock to device sda2 Jul 18 08:28:32 Tower kernel: get_token: status Jul 18 08:41:22 Tower kernel: hdj: dma_timer_expiry: dma status == 0x61 Jul 18 08:41:32 Tower kernel: hdj: error waiting for DMA Jul 18 08:41:32 Tower kernel: hdj: dma timeout retry: status=0x51 { DriveReady S eekComplete Error } Jul 18 08:41:32 Tower kernel: hdj: dma timeout retry: error=0x40 { Uncorrectable Error }, LBAsect=18713848, high=1, low=1936632, sector=18713728 Jul 18 08:41:32 Tower kernel: end_request: I/O error, dev 38:41 (hdj), sector 18 713728 Jul 18 08:41:32 Tower kernel: md5: read error! Jul 18 08:41:32 Tower kernel: end_read_request 18713728/5, count: 2, uptodate 0. Jul 18 08:41:32 Tower kernel: blk: queue c032692c, I/O limit 4095Mb (mask 0xffff ffff) Connection to host lost. Press any key to continue... ========================================================== Looks like a problem with hdj and/or DMA. Any suggestions would be appreciated.
July 18, 200619 yr According to this excerpt from the "go" script, that disk is on the first promise controller (closest to the CPU on the recommended intel motherboard): [pre] # Following assumes a 12-disk system (2 promise ide controllers)^M # Disks 0..3 (motherboard Pri/Sec) hdparm -c1d1a0m8A1W1u1 /dev/hda hdparm -c1d1a0m8A1W1u1 /dev/hdb hdparm -c1d1a0m8A1W1u1 /dev/hdc hdparm -c1d1a0m8A1W1u1 /dev/hdd # Disks 4..7 (pci slot closest to CPU) hdparm -c1d1a0m8A1W1u1 /dev/hdi hdparm -c1d1a0m8A1W1u1 /dev/hdj hdparm -c1d1a0m8A1W1u1 /dev/hdk hdparm -c1d1a0m8A1W1u1 /dev/hdl # Disks 8..11 (pci slot further from CPU) hdparm -c1d1a0m8A1W1u1 /dev/hde hdparm -c1d1a0m8A1W1u1 /dev/hdf hdparm -c1d1a0m8A1W1u1 /dev/hdg hdparm -c1d1a0m8A1W1u1 /dev/hdh [/pre] Is that disk different than any of the others? or on a longer drive cable? I first would try a different cable on that disk, then, try moving it to a different controller, or different power supply if you have two in the case, or could just try moving it to a different slot (if you have removable trays) you might also try the folowing command after logging in using telnet) and post the output: hdparm -i /dev/hdj You might also be able to alter the hdparm command for that drive in the "go" script to use a different (slower) udma mode and then use the drive without the errors but Tom might have to advise you what options you could try. Joe L.
July 21, 200619 yr Author Here's the hdparm output: =============================================== Tower login: root Linux 2.4.29. root@Tower:~# hdparm -i /dev/hdj /dev/hdj: Model=WDC WD1600JB-00EVA0, FwRev=15.05R15, SerialNo=WD-WMAEK2136271 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq } RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=8 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=no WriteCache=enabled Drive conforms to: device does not report version: * signifies the current active mode ============================================= Perhaps I should add that this is not a new disk; it has about 147GB of data on it, and hasn't given any problems so far. If it IS a DMA problem, it's a new one. I'm hoping it's just a cable that came loose or something like that. Unfortunately it's not in a tray. I'll have to open up the machine, I think.
July 21, 200619 yr See my post in the other thread you opened about the power supply. It might just be the root cause of the problems if you have all the drives on a single 12 volt source. Joe L.
July 29, 200619 yr Author Finally got a chance to open up the box, but now I suspect the disk is dying. I verified that I had used separate power supply connectors: I had used the connections which were second closest to the thick cable and the one furthest away. The drives are pretty evenly distributed between the two. I fiddled with the wires to make sure they were properly seated and then restarted the machine only to find that somehow the BIOS settings had been lost and unRaid wasn't booting. Got that sorted out and tried running a parity check again, but got the same error. So I swopped the IDE cable for another one, and moved one power connector from the position second closest to the thick cable to the closest one. But on rebooting, I got the same error again. On comparing the three logs I now have (original one posted above and the two new ones), I found that the error was always in the same spot. All the logs have this equivalent line: Jul 18 08:41:32 Tower kernel: hdj: dma timeout retry: error=0x40 { Uncorrectable Error }, LBAsect=18713848, high=1, low=1936632, sector=18713728 I'm guessing that it's a problem with the hard disk itself. It's a WD and I haven't bought one of those for years, so it's an old disk. Does anyone have any other theories?
July 30, 200619 yr sonofdbn - Does sound like that disk has a bad sector, but I'm still interested in the original error in the first post to this thread. If you encountered a disk error during operation, system should not have gone off-line like you described - of course could be two completely different problems. I can't match up your email address with any order so I don't know what you purchased. What version UnRaid s/w are you running? What is your system config (ie, number of disks, directly connected or using mobile racks (which ones), power supply(s))? If you prefer, email me to discuss.
August 5, 200619 yr Author Sorry I couldn't respond earlier - was away on a business trip. I'm running 1.050930. I have 12 hard disks and am using the "starter pack". The power supply is an Antec Neo HE 500. All the hard disks are connected directly except for one, which sits in an "ICY Dock" (?) mobile rack which I had lying around. I think it's the same as the one sold with the unRaid tower; at least it looks very similar. The mobile rack sits on the middle connector of the IDE cable which is attached to IDE2 on the Promise card closest to the CPU, which I think makes it hdl (and Disk 7 in the default configuration). So it's on the same Promise controller as my problem hard disk, hdj. Got another strange message when I booted up today, telling me that D0 and D1 on the Promise card were running on a 40-wire cable (which it visibly is not) and therefore the UDMA would be set lower, and sure enough my hdj is now on udma2. (This is the new cable which I swopped in while trying to fix hdj.) A controller card problem? Let me know if you need any more information. I'm not in hurry at the moment, so I can leave things as they are for a while, but I'm hoping to replace hdj with a new hard disk next weekend.
August 27, 200619 yr Author Sorry for the delay in responding - was away on a business trip. Anyway, I've now swapped out the rack which held hdl, and now, using just metal brackets, the UDMA problem is gone. But the original parity check hanging problem is still there. (edit: corrected hard disk reference)
August 27, 200619 yr Author I tried copying some files off hdj, but while some were OK, I kept on getting a "network name no longer available" message in Windows, although the Unraid server and name still seemed to be there when I re-accessed it. Here's the log, in case it's useful. **************************************** Tower login: root Linux 2.4.29. root@Tower:~# tail -f /var/log/syslog Aug 27 13:32:48 Tower smbd[847]: [2006/08/27 13:32:48, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:32:48 Tower smbd[847]: sys_path_to_bdev() failed for path [.]! Aug 27 13:33:48 Tower smbd[847]: [2006/08/27 13:33:48, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:33:48 Tower smbd[847]: sys_path_to_bdev() failed for path [.]! Aug 27 13:33:48 Tower smbd[847]: [2006/08/27 13:33:48, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:33:48 Tower smbd[847]: sys_path_to_bdev() failed for path [.]! Aug 27 13:33:57 Tower smbd[847]: [2006/08/27 13:33:57, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:33:57 Tower smbd[847]: sys_path_to_bdev() failed for path [.]! Aug 27 13:33:57 Tower smbd[847]: [2006/08/27 13:33:57, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:33:57 Tower smbd[847]: sys_path_to_bdev() failed for path [.]! Aug 27 13:36:11 Tower smbd[849]: [2006/08/27 13:36:11, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:36:11 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:36:11 Tower smbd[849]: [2006/08/27 13:36:11, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:36:11 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:36:11 Tower smbd[849]: [2006/08/27 13:36:11, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:36:11 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:36:11 Tower smbd[849]: [2006/08/27 13:36:11, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:36:11 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:36:11 Tower smbd[849]: [2006/08/27 13:36:11, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:36:11 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:36:11 Tower smbd[849]: [2006/08/27 13:36:11, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:36:11 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:36:11 Tower smbd[849]: [2006/08/27 13:36:11, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:36:11 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:36:11 Tower smbd[849]: [2006/08/27 13:36:11, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:36:11 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:38:18 Tower smbd[849]: [2006/08/27 13:38:18, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:38:18 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:38:18 Tower smbd[849]: [2006/08/27 13:38:18, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:38:18 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:38:20 Tower smbd[849]: [2006/08/27 13:38:20, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:38:20 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! Aug 27 13:38:20 Tower smbd[849]: [2006/08/27 13:38:20, 0] lib/sysquotas.c:sys_ge t_quota(386) Aug 27 13:38:20 Tower smbd[849]: sys_path_to_bdev() failed for path [.]! **************************************************
September 9, 200619 yr Author I finally bought a new and larger hard disk and replaced my problem hdj drive and upgraded the software to 2.060706. "Recreated" the data and the parity check now is fine.
September 9, 200619 yr Glad that your issue worked out... I am still having my issues and I don't know what the hell is causing the issues.... I wish it was a bad hard drive, but I seriously have no clue whatis wrong my array!! Hopefully Tom will jump on this weekend and give me some ideas!!!
Archived
This topic is now archived and is closed to further replies.