October 8, 200817 yr Hello to all non-RAIDers. I am testing / evaluating unRAID 4.3.3 on the following hardware: Asus A7N8X-E Deluxe motherboard rev 1.01 512MB DDR RAM (two-sticks, dual-channel) Barton CPU (have been running at 1100 - 1830MHz, currently at 1466MHz) AGP video card (I think it's an ATI Radeon VE / Radeon 7000) SII3114 PCI controllers x 3 (currently using two) SATA Drives, WD5000AAKS x 3 PATA Drives, Maxtor 6Y120P0 x 1 I have disabled all unused features in the BIOS, and am using the onboard GbT NIC (Marvell Yukon 88E8001). Testing was going pretty well until I started using a parity drive while two drives were on the same controller. Parity will build and test with zero errors using any combination of two drives, but if they are on the same controller, the parity builds ok, but the check will be constantly counting errors (will finish with over 500,000 errors). This has happened with two drives on pci-000:01:06.0 (top slot / PCI1), as well as two drives on pci-000:01:08.0 (middle slot / PCI3). These two tests used two different controllers, with only one drive common between them (switched one from 06 to 08 and re-tested). All of these drives have tested ok as parity for the the 120G PATA drive, as well as parity for another 500G drive on a separate controller. Has anyone seen this before? I not quite sure where to go from here (other than continuing to swap cards, slots, drives, etc). Martin
October 8, 200817 yr Hello to all non-RAIDers. I am testing / evaluating unRAID 4.3.3 on the following hardware: Asus A7N8X-E Deluxe motherboard rev 1.01 512MB DDR RAM (two-sticks, dual-channel) Barton CPU (have been running at 1100 - 1830MHz, currently at 1466MHz) AGP video card (I think it's an ATI Radeon VE / Radeon 7000) SII3114 PCI controllers x 3 (currently using two) SATA Drives, WD5000AAKS x 3 PATA Drives, Maxtor 6Y120P0 x 1 I have disabled all unused features in the BIOS, and am using the onboard GbT NIC (Marvell Yukon 88E8001). Testing was going pretty well until I started using a parity drive while two drives were on the same controller. Parity will build and test with zero errors using any combination of two drives, but if they are on the same controller, the parity builds ok, but the check will be constantly counting errors (will finish with over 500,000 errors). This has happened with two drives on pci-000:01:06.0 (top slot / PCI1), as well as two drives on pci-000:01:08.0 (middle slot / PCI3). These two tests used two different controllers, with only one drive common between them (switched one from 06 to 08 and re-tested). All of these drives have tested ok as parity for the the 120G PATA drive, as well as parity for another 500G drive on a separate controller. Has anyone seen this before? I not quite sure where to go from here (other than continuing to swap cards, slots, drives, etc). Martin Last person with parity errors like that found it was the motherboard. After lots of tests and hair-loss, they replaced the motherboard used the old motherboard as a wheel-chock for their car... Since the motherboard could be stressed when loaded with a lot of buss traffic, make sure you have all the screws in place mounting the motherboard to the chassis. A missing ground might make it more susceptible to noise. After that, I'd start with a memory test, run it for several cycles... then swap out the power supply, then swap disk controllers & cables. Joe L. It could be power supply, memory, memory-voltage, memory-speed settings, cables....motherboard, or controller. I doubt the keyboard is the cause, so you can probably keep it.
October 8, 200817 yr Author Thanks for the tips Joe. I am using all of the screw mounts (some of which are plastic stand-offs due to case design), and the power supply has been swapped with a spiffy new Corsair VX550. I have also run Memtest86+ for about 8+ hrs (can't remember how many test cycles) with no problems. Do you think that bus traffic / noise would be better running three drives (120G on PATA channel, 500G on PCI1, 500G on PCI3) vs just two drives on a single controller?
October 8, 200817 yr I don't see any issues in the syslog. I do have to say that I am personally heavily biased against any motherboard based on nForce chipsets less than 5, and you have an nForce2-based board. The only ones that I have heard of as being reliable are the Asus A8N series boards, which have an nForce 4 chipset. My horrible experiences were with an nForce 4 Ultra, and when researching it, found numerous reports of the same troubles on the Internet, some of which were also reported to be in the nForce2 and nForce3 series, all of which were apparently fixed in the nForce5 series. I could certainly be wrong here, but I can tell you, if it's your motherboard, you will be pulling hair and beating your head on the wall until you replace that board. The data corruption issues were more likely to occur with heavy bus use, such as in an unRAID situation, with multiple hard drives and the network chipset contending for the bus, less likely in normal desktop and gaming use.
October 8, 200817 yr Author Awwwwwww shucks. That doesn't sound very good at all. Are there any tests that can be run to possibly isolate the problem?
October 8, 200817 yr Not really when it comes to some problems, like motherboards. It's more a case of, when you have eliminated everything else... You have tested the memory, swapped controllers, and the PSU seems good, although even the best and newest could have been tossed too hard by a shipper. A bad cable is a definite possibility, and cable problems show up in the syslog. Check a syslog after you have seen errors, and look for drive-related errors that are not actually hard drive related, but are communications related, such as timeouts, BadCRC, device errors, etc. True drive errors are things like media errors, seek errors, and sector errors. If the errors do not go away by replacing the cable, then there seems only one choice left. Also make sure temps seem good, especially the motherboard chipsets. Symptoms don't seem consistent with CPU or drives getting too hot...
October 8, 200817 yr Author I can produce the errors are any time, and I can also 'fix' them by relocating one drive to another controller. I can't see how the errors could be power or cable related. I do know that stranger things have happened. I suppose I could test the scenario by rotating ports and cables around... but I'm very sure the problem will remain. I've attached a syslog after about 10 seconds of parity check.
October 8, 200817 yr Author Aside from the parity errors, I find these in the syslog: emhttp: shcmd (13): killall -w smbd nmbd ... emhttp: shcmd (14): /usr/sbin/hdparm -S242 /dev/sdc >/dev/null emhttp: shcmd (15): /usr/sbin/hdparm -S242 /dev/sdb >/dev/null emhttp: shcmd (16): sync ... emhttp: shcmd (17): umount /mnt/user emhttp: shcmd (18): rmdir /mnt/user emhttp: shcmd (19): umount /mnt/disk1
October 8, 200817 yr Author The drive temps are hovering around 39-40C. They were higher, but I rigged a fan to give them a breeze. A more permanent solution will be in place once I get the hardware reliable and purchase a license. I can check cpu temps and voltages in the BIOS. I don't recall exactly, but I did check them once the new power supply was in and nothing seemed unusual at that time.
October 8, 200817 yr Are there any tests that can be run to possibly isolate the problem? Someone was having intermittant issue like this. (and worse). When they opened the case and put a fan blowing on the motherboard, it cooled the chipset and some of the issues were diminished (but not 100%). Suggestion and easiest to try.. Change the cable. I recently had intermittant drive dropouts. I changed everything in the path. The last thng to change was cable and that fixed it.
October 8, 200817 yr Author Will do WeeboTech, but like I said my problems are not intermittent. I'll revisit the cooling, and do a good ole merry-go-around with cables and such, check temps & volts in the BIOS. Also, I'm going to enable the onboard SATA controller and test that as well. The only thing in that list the seems interesting is the onboard controller test as it has two ports and I have yet to test it. Thanks for the info an suggestions. Keep 'em coming if you can!
October 9, 200817 yr Aside from the parity errors, I find these in the syslog: emhttp: shcmd (13): killall -w smbd nmbd ... emhttp: shcmd (14): /usr/sbin/hdparm -S242 /dev/sdc >/dev/null emhttp: shcmd (15): /usr/sbin/hdparm -S242 /dev/sdb >/dev/null emhttp: shcmd (16): sync ... emhttp: shcmd (17): umount /mnt/user emhttp: shcmd (18): rmdir /mnt/user emhttp: shcmd (19): umount /mnt/disk1 Those aren't errors, they are very normal operations. Actually, there are no drive or other hardware errors listed. Parity errors are not really errors in the same sense. They are an indication that the re-calculation of parity was non-zero, indicating that one or more of the parity bits is wrong. The parity check corrects these as it finds them. Could you repeat that 10 second test one more time and post the resultant syslog, so we can see if they are the very same parity errors appearing, or instead seem random.
October 9, 200817 yr Author Sorry RobJ, no-can-do ... I'm rebuilding parity with the same two drives using the onboard SII-3112 controller. Give me another 96 minutes and then we'll see. Good point though, I wasn't sure how the parity was handled during a check.
October 9, 200817 yr Author Ahhhhhhhh-HA! Parity has just finished building and I started the parity check. I'm 1.5% in and NO ERRORS YET! ... 130mins to go. So this could mean there is something off with the SII-3114 controllers, or the way they communicate with the PCI bus, or ....
October 10, 200817 yr Author After getting a postive result from two drives connected to the onboard 3112 controller, I did the following tests: Two disks on different controllers. - Parity on 3114, PCI3, Con3 - Disk1 on 3112, Port1 = parity OK - Parity on 3114, PCI1, Con3 - Disk1 on 3112, Port1 = parity OK - Parity on 3114, PCI3, Con3 - Disk1 on 3114, PCI1, Con3 = parity OK Two disks on same 3114 controller. - Parity on 3114, PCI3, Con3 - Disk1 on 3114, PCI3, Con4 = parity OK - Parity on 3114, PCI1, Con3 - Disk1 on 3114, PCI1, Con4 = parity OK - Parity on 3114, PCI5, Con3 - Disk1 on 3114, PCI5, Con4 = parity OK - Parity on 3114, PCI1, Con2 - Disk1 on 3114, PCI1, Con1 = parity OK - Parity on 3114, PCI3, Con2 - Disk1 on 3114, PCI3, Con1 = parity OK - Parity on 3114, PCI5, Con2 - Disk1 on 3114, PCI5, Con1 = parity OK Now this parity-set was built on the 3112 controller, and this is the first time that I've had good parity results from two drives on one controller. This leads me to think that the problem was during the write process while both drives were connected to the 3114 controllers. Any tips on where to go from here? My thoughts are to regenerate the parity while connected to one of the 3114 controllers (again), but that is a 3hr process.
October 10, 200817 yr Any tips on where to go from here? My thoughts are to regenerate the parity while connected to one of the 3114 controllers (again), but that is a 3hr process. Considering you have all good tests so far, the logical test path I see is to go back to what failed once before. It may be the controller or it may be the drive and all the writes being done re-allocated sectors.
October 10, 200817 yr Author Good point. I just rebuilt the parity completed a successful parity check with two drives on 3114/PCI5. Will continue testing.
Archived
This topic is now archived and is closed to further replies.