I'm probably adding too much detail, but wanted to make sure I'm covering all the bases..

 

Have a 4 disk system running version 4.5.6 / pro key.  I recently purchased 2 additional WD Green 1 TB EADS drives and attempted to add them to my array.  I ran preclear successfully on each one, formatted them successfully, added them to the array and then did a parity check - all was fine.  I then tried writing a new 4 GB file to my Media share - it immediately hung and I had to forcibly reboot it to get it to work again.  After rebooting and stopping the new parity check, I tried writing directly to the disk4 and disk 5 shares - again it would go as far as creating the folder structure and the file, but then hang (web page no longer responds, doesn't accept keyboard input) after about 10 sec.  

 

Looking closer into the issue I discovered even though these are EADS drives, they have that dang Advanced Format Technology - so I added a jumper on pins 7&8, removed them from the array, did a initconfig to reset the configuration and rebuild the parity drive, and then re-ran the preclear script on both drives (this time with the jumper attached).  Again everything completed successfully, and I only added one to that array this time.  Before attempting to copy anything to it, I used Midnight Commander to copy a 4 gb file from another drive over to the new disk - no problems.  However as soon as I tried copying data through Unraid, either to the User share or the disk share, it again hangs after creating the new file and the server is again unresponsive.  After reboot I tried FTPing a 200 MB file over, again it hung.

 

I have 2 GB of ram that has passed hours of Memtests, and 6 onboard sata ports (now fully populated).  The motherboard (Abit AT8 32x) has 2 sata controllers, but this is the first time I've used the ports that are controlled by the 2nd controller.  However since both the preclear and copying via MC work fine, I'm inclined to think the issue isn't there.  I assume the 550watt power supply is also adequate because I don't have any problems until I try to write via Unraid - Parity check runs fine with 5 or 6 drives in the array.

 

Any thoughts of what I should try next?  I am able to copy small files to the new drives successfully through Unraid - for example 62 meg of doc files (129 files total) copied without hanging the system.  Am I hitting some memory barrier when I copying larger files?  I am using UnMenu with email and powerdown packages.

syslog-2010-07-25.txt

What is your exact motherboard model as it looks like there is no Abit AB8 32x - is it AN8 32x (nVidia) or AT8 32x (ATI)?

 

Have you updated the BIOS to the latest one (even BETA if available)?

Sorry, AT8 32x (I updated my original post). 

 

I have the latest bios, which is from 2006.  Most of the hardware in this server is recycled from my previous desktop system. 

My unRAID has done the same for a couple months... i've posted on here and no one helped.

 

I have 12 drives, and 4 of them tend to hang when I try to transfer data to them. Small files transfer fine, but if I try to transfer 10GB+ files it will usually error.. this rules out hardware. The drives themselves are fine, and the error always happens immediately or at the same % of the transfer (AKA if it errored at 63%, and I retry it will error at 63% again). The unRAID server just becomes unresponsive causing the transfer to error, as soon as the transfer is cancelled the server is fine. No errors in syslog, I believe its a issue with transfering files to unRAID from a 64-bit OS.

 

Friend has the same issue and is also transferring from Win7 64-bit. There is definitely an issue with unRAID, but everytime you come on these forums and point fingers at unRAID people just blame your server. So I don't see a solution until Limetech figures out they have an issue. I'm hoping this is fixed in the new beta.

Actually I think I fixed it.  Since the problem occurred immediately after enabling my 2nd sata controller in the BIOS, I looked closer at what else might be sharing IRQs or other resources with that controller.  Judging from the bios, the onboard NIC is managed by the same PCI controller - so I disabled the onboard and dropped in a Intel Pro 1000 nic that was lying around in the office (PCIx card in a PCI slot).  Disabling the onboard changed the PCI Ids on the drives attached to that 2nd controller so Unraid showed the disks as missing, but that was easily resolved.  It picked up the new nic with no issue and so far, every copy test I've tried to either user or disk shares has worked flawlessly.

 

Keeping my fingers crossed...

Tyrindor,

 

Do your lockups occur with both the user and disk shares?  I had problems in the past writing to disk shares, but since I always used user shares, I wasn't too concerned.  Once I added these 2 new drives and couldn't write large files to either type of share, it kinda defeated the purpose of running the server...

 

The 4 drives you have problems with, are they all connected to the same controller?

 

I'm running 32 bit Win7 on all the machines that write large files.

My unRAID has done the same for a couple months... i've posted on here and no one helped.

 

I have 12 drives, and 4 of them tend to hang when I try to transfer data to them. Small files transfer fine, but if I try to transfer 10GB+ files it will usually error.. this rules out hardware.

This in no way rules out hardware, in fact it kind of points to a hardware problem.  The poster above points out what his problem was and how he fixed it.  He probably could have assigned a IRQ manually and maybe fixed it instead of putting in a PCI NIC.

 

The drives themselves are fine, and the error always happens immediately or at the same % of the transfer (AKA if it errored at 63%, and I retry it will error at 63% again). The unRAID server just becomes unresponsive causing the transfer to error, as soon as the transfer is cancelled the server is fine. No errors in syslog, I believe its a issue with transfering files to unRAID from a 64-bit OS.

The only way you can say that it is unRAID is if you take a 32-but OS (windows 7) and do the file transfers again.  There could be a conflict what the above poster had or it could be an issue with the version of samba that unRAID uses.  If you can figure out which that would be very helpful and you could email limetech about it.

 

Friend has the same issue and is also transferring from Win7 64-bit. There is definitely an issue with unRAID, but everytime you come on these forums and point fingers at unRAID people just blame your server. So I don't see a solution until Limetech figures out they have an issue. I'm hoping this is fixed in the new beta.

unRAID has no control over IRQ's, and that type of issue is hard to find. The only thing I would see as a problem with unRAID is the version of samba that is used, but again, it makes no sense as ALL but 4 of your disks are working fine.  Sounds like something else is going on, maybe the controller that the disks are attached to, or something else...