September 12, 200916 yr Alright... it's not the network. I put the file on a USB external drive. I ran md5sum on the file once it was copied to the device. It was good. I mounted it to my unRAID box and cp'd it, and the md5 failed. Time to pull Disk 2 I guess. The diagnosis continues. Any other thoughts as I go?
September 12, 200916 yr At this point I would be suspecting the cables, (but you're not getting DMA errors), heat issues, board(chipset configurations), CPU. When I would test out CPU configurations for overclock issues, I would use prime95 to test it out with the torture test.
September 12, 200916 yr WeeboTech, I'm trying your suggestion for no PCI cards in a moment (just building parity, will then shut down and remove the cards). If that fails, I'm planning to add 1.5 Gb/sec jumpers to the drives and test again. If that fails, I'll ... bug you like crazy for help haha
September 12, 200916 yr Unbelievable... It looks like it's the PCI bus. Remove the cards, and what do we get? root@unRAID:/mnt/user/tmp2# md5sum testfile6.zip 9c3b3eb65e00c18cffb058a91c0903e7 testfile6.zip Okay... so... after I went through all the flustration of figuring it must be the on-board SATA, it turns out it's in fact the PCI or thereabouts. So... both of my 2-port PCI cards are Silicon Image cards. Of course, the cards work in the system... so... what could be the issue here? Glad to see a good MD5 for once!! I'll run the file once more just in case it was a fluke (after all, the earlier 500 MB file was fine too). Robbie
September 12, 200916 yr A thought: I'm going to try the jumper to 1.5 Gb/sec... my curiousity makes me wonder, could these cards do poorly with auto-negotiating... Any thoughts on that? Am I drawing at straws?
September 12, 200916 yr A thought: I'm going to try the jumper to 1.5 Gb/sec... my curiousity makes me wonder, could these cards do poorly with auto-negotiating... Any thoughts on that? Am I drawing at straws? It's possible.. and worth a try. Somewhere in the back of my mind I'm hearing a hint of I've heard of people having issues with early PCI based Silicon Image cards. Unbelievable... It looks like it's the PCI bus. Remove the cards, and what do we get? So... both of my 2-port PCI cards are Silicon Image cards. Of course, the cards work in the system... so... what could be the issue here? It may not be the bus, it could be the driver and/or a FIFO on the card itself. I've uploaded mprime for linux here. http://code.google.com/p/unraid-powercontrol/downloads/list You can use this to double check the cpu and memory interface.
September 12, 200916 yr Somewhere in the back of my mind I'm hearing a hint of I've heard of people having issues with early PCI based Silicon Image cards. Hmmm.... could that be all it is? BOTH my cards are cheap Silicon Image boards. I'd plug in my 3ware, but one of you mentioned it won't work. I haven't tried. Either way, all my boards only have 2 ports each. I don't have one of those sexy 34-port super mega boards Robbie
September 12, 200916 yr Do a test with just parity and one data drive on the motherboard ports. Do the mprime torture test.
September 12, 200916 yr With just the parity drive and data drive on the mobo, everything was fine (md5 matched). I put back the pci card and put the 1.5 Gbit jumper on the drive and readded it to the array, but it again failed md5. Could be my controller chipset then eh? For the pci cards... Robbie
September 12, 200916 yr At this point I might check /proc/interrupts and see if I can move the PCI boards around to an isolated IRQ. Review the Manual to see which slots are shared with what. I don't think this is really the issue, but it is what I would do. Disable everything on the motherboard I could, P-ATA, Serial, Sound, isolate PCI cards to their own IRQ and see what happens.
September 12, 200916 yr I'm pretty sure I disabled everything unneeded in bios ... but I'll have to move things around, hook up a monitor and double check. Well, hopefully the documentation of this problem will help someone down the road.... but I wish I could just ... you know... work. Thanks for your help!! Robbie
September 13, 200916 yr So, everything 'unnecessary' is off in my bios... but I do see this in cat /proc/interrupts : CPU0 0: 29 IO-APIC-edge timer 1: 8 IO-APIC-edge i8042 8: 19 IO-APIC-edge rtc 9: 0 IO-APIC-fasteoi acpi 14: 35 IO-APIC-edge ide0 15: 0 IO-APIC-edge ide1 16: 0 IO-APIC-fasteoi uhci_hcd:usb2, uhci_hcd:usb5 18: 15978 IO-APIC-fasteoi uhci_hcd:usb4, ata_piix 19: 0 IO-APIC-fasteoi uhci_hcd:usb3 20: 0 IO-APIC-fasteoi sata_sil 22: 452798 IO-APIC-fasteoi sata_sil, eth0 23: 432 IO-APIC-fasteoi ehci_hcd:usb1 NMI: 0 Non-maskable interrupts LOC: 18822 Local timer interrupts RES: 0 Rescheduling interrupts CAL: 0 function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts SPU: 0 Spurious interrupts ERR: 0 MIS: 0 Now, one of the silicon cards is indeed on the same irq as the network adapter... but then I'd think, it would work if I moved the drives onto the other card (because it is not shared with the ethernet)... but that gave the same errors. Robbie
September 13, 200916 yr Now, one of the silicon cards is indeed on the same irq as the network adapter... but then I'd think, it would work if I moved the drives onto the other card (because it is not shared with the ethernet)... but that gave the same errors. Can you post a recent syslog?
September 13, 200916 yr Can you post a recent syslog? Sure can! Attached. I just finished flashing my pci sata controller card's rom to the latest "non-raid" version, but still no luck. That did nothing. Robbie
September 13, 200916 yr I know you do not like to use beta software, but for a quick test, and since it is a different linux kernel, could you try upgrading to the current 4.5beta6 release. You can rename your existing bzroot and bzimage on the flash drive to bzimage.442 and bzroot.442 and then copy the bzroot and bzimage from the un-zipped 4.5b6 version to the flash drive. If it makes it all better, then the newer kernel plays better with your hardware... if not, just rename the two files back to their original names and reboot once more and you'll be back on the 4.4.2 release you are now. You can even put a few more lines in the syslinux.cfg and be able to boot on either the old or new versions, defaulting to the one named bzroot and bzimage. (it is what I usually do) If nothing else, it will help to eliminate one more possible cause (although software does not usually have anything to do with random errors, it might use different timing, etc... worth a shot in my mind) My current syslinux.cfg looks like this... I have many prior versions on my flash drive and can boot into any if I'm trying to help somebody and need to duplicate an issue. [pre] default menu.c32^M menu title Lime Technology LLC^M prompt 0^M timeout 100^M label unRAID OS vga^M menu default^M kernel bzimage^M append initrd=bzroot rootdelay=10 vga=extended^M label unRAID OS, no VGA^M kernel bzimage^M append initrd=bzroot rootdelay=10^M label unRAID 4.5beta5 OS^M kernel bzimage.455^M append initrd=bzroot.455 rootdelay=10 vga=extended^M label unRAID 4.5beta4 OS^M kernel bzimage.454^M append initrd=bzroot.454 rootdelay=10 vga=extended^M label unRAID 4.5beta2 OS^M kernel bzimage.452^M append initrd=bzroot.452 rootdelay=10 vga=extended^M label unRAID 4.4.2 OS^M kernel bzimage.442^M append initrd=bzroot.442 rootdelay=10 vga=extended^M label unRAID 4.4 OS, no VGA^M kernel bzimage.44^M append initrd=bzroot.44 rootdelay=10^M label Old433unRaid^M kernel bzimage.433^M append initrd=bzroot.433 rootdelay=10 vga=extended^M label Memtest86+^M kernel memtest^M [/pre] Joe L.
September 13, 200916 yr Welcome back, Joe. Well, I can certainly try the beta. Any issues that will risk my data? That's my only concern... what if I lose data... But obviously, if I'm getting bad parity with the stable version... well, going beta is no worse. Any eta when "beta" will become stable? Thanks!! I'm gonna have to give up on this for tonight (it's just been too much for one day), and am visiting family tomorrow... I'll put in more time tomorrow morning if I can (before we leave) and hopefully will be able to get things figured. Thanks for the help!! Robbie
September 13, 200916 yr Welcome back, Joe. Well, I can certainly try the beta. Any issues that will risk my data? That's my only concern... what if I lose data... But obviously, if I'm getting bad parity with the stable version... well, going beta is no worse. Any eta when "beta" will become stable? Thanks!! I'm gonna have to give up on this for tonight (it's just been too much for one day), and am visiting family tomorrow... I'll put in more time tomorrow morning if I can (before we leave) and hopefully will be able to get things figured. Thanks for the help!! Robbie No, no danger to your data. The "beta" features are with active-directory support for corporate LAN use, and with increasing the max number of disks in the possible array to 20 from 16. The remaining features are all the same... there is a newer version of SAMBA, and a newer linux kernel (both the stable versions). The "beta" fixes a few bugs with your version (I don't think logrotate works properly in your older version...) and nntp (I think it is started before the network is established in your older version, so unless you save a change on the admin screen, it does not get a good initial time from an nntp server on bootup) The latest version changes what split level of 0 means for user-shares... Release notes are all summarized here: http://lime-technology.com/wiki/index.php/Release_Notes#Changes_from_4.4.2_to_4.5-beta2 None of the changes will affect your data. Joe L.
September 13, 200916 yr Sold I'll try it out and let you know if it changes things as far as my parity goes Thanks Joe!! Robbie
September 13, 200916 yr Hey Joe, no go. Running beta 6 and still bad parity on the pci-connected drives. Using a Sil3112 with latest firmware. Thanks for trying. Any other ideas, or should I just write it off as being incompatible PCI cards and go out and buy a particular one? Robbie
September 13, 200916 yr Sold I'll try it out and let you know if it changes things as far as my parity goes Thanks Joe!! Robbie Time to get some sleep... You can revert to 4.4.2 if nothing changes... or stay on 4.5beta6 if it magically fixes everything (I doubt it will, but it would be nice) . Entirely up to you. But you will rule it out as a cause... I know all about needing to spend time with family... you are not alone... I'll be around the house most of tomorrow, except for a few hours in the early evening so I can respond to questions... (taking wife to another dance... but this time I'm just an attendee) Joe L.
September 13, 200916 yr Hey Joe, no go. Running beta 6 and still bad parity on the pci-connected drives. Using a Sil3112 with latest firmware. Thanks for trying. Any other ideas, or should I just write it off as being incompatible PCI cards and go out and buy a particular one? Robbie What card(s) are you running? I'm running a generic Roswill 4-port card with a Sil3114 chipset from newegg, http://www.newegg.com/Product/Product.aspx?Item=N82E16816132013&Tpk=RC-209 prior to that I was using no-name card I got at the local computer store for about $15 that used an Sil3512 chipset. http://www.microbarn.com/details.aspx?rid=100856&source=pricewatch It is labeled as model CON-SATAR What are you using? I did nothing to the firmware on either card.
September 13, 200916 yr Oh yeah... my array is currently reporting: Parity CHECK in progress, 41.4% complete, est. finish in 602.2 minutes. Errs=0 It is running at just under 17,000 KB/s... for now. I don't expect it will really take 10 more hours. Edit: it took about 5 more hours... Joe L.
September 13, 200916 yr Hey Joe, I have the two PCI cards... The first is the one I used during the install - Sil3512 ECTU128. The second, I picked up because of the parity issues, as you know - Sil3112 ACT144 So, if you were using the same chip and had no problems, it might point more to the PCI on the board than the cards themselves... that doesn't make me smile too much haha. Let me know your thoughts. I'm pretty sure this is the only mobo I have in stock (other than already in use, of course) that boots from USB...
September 13, 200916 yr ... my comment just there made me think... I'll boot up an Ubuntu live CD and write to the drive on the PCI BUS and check the md5. If it's fine, we'll know it's something in the kernel of unRAID. Robbie
September 13, 200916 yr Well, that proved it. The problem is not unRAID's fault -- it is hardware. I booted Ubuntu 8.04 live (100% bypassing unRAID, but using the same hardware), mounted the drive connected to my PCI card (Sil3112), cp'd the file, and the MD5 failed. At this point, I'm assuming it's the motherboard's PCI bus, as unRAID's compatibility chart shows Silicon Image chips as being perfectly compatible, plus I'm getting the same problem with two different cards (the other is an Sil3512, which Joe reported worked fine on his system) Any other thoughts?
Archived
This topic is now archived and is closed to further replies.