I am running Unraid 4.4.2, on a Asus p5nsli motherboard, and after an hour or so it stops responding. I can not acess the shares, and I can not acess the gui.

Any idea where I should start to look at for a potential problem?

It will be either the unRAID server, or the networking, or the PC you are using to access it.

 

Start by looking at one of them.

 

To provide any more guidance would have required you to give more detail.

 

Your best bet is to provide a copy of your syslig for analysis.  If you can log onto the system console, you can copy it to the flash drive and then attach it to your next post.  If not, let us know what you can access now, if anything... reboot, and capture a syslog when you first reboot, and then a half hour later.

 

Or, run a

tail -f /var/log/syslog

in a telnet or console window and wait till the server stops responding once more, then post the tail end (or take picture of the screen error when is stops responding)

 

Instructions for capturing a syslog are in the wiki under "Troubleshooting"

 

Joe L. 

Ok, well if this helps, I did a motherboard swap this weekend from an old archaic P4 board with no pcie's, 2 slow sata's, and no gigabit network to this asus board. Prior to that, the server never responded this way, so the only thing that has changed is the board possibly unraid sitting on it.

 

That being said, I am running a 5 disk array without parity, and I am getting rediculously slow write speeds to both user shares and to a disk itself, somewhere in the neighborhood of 11-13mb/s. reads are about 20.

How can that be, when things like Ubuntu Server are running north of 60?

Ok, well if this helps, I did a motherboard swap this weekend from an old archaic P4 board with no pcie's, 2 slow sata's, and no gigabit network to this asus board. Prior to that, the server never responded this way, so the only thing that has changed is the board possibly unraid sitting on it.

Or the LAN connector, or the cable... (as it might have an intermittent at the connector as you moved it)

That being said, I am running a 5 disk array without parity, and I am getting rediculously slow write speeds to both user shares and to a disk itself, somewhere in the neighborhood of 11-13mb/s. reads are about 20.

How can that be, when things like Ubuntu Server are running north of 60?

No  matter what, any given disk must spin its platter a full revolution between the "read" of the existing contents of a sector and the "write" of its updated contents if you are using parity.  You will find your performance is about average.   Basic physics will dictate that a 7200 RPM non-green drive will be faster to get the same sector around to write it after reading it than a 5400 RPM drive.   Take the speed of the non-protected ubuntu drive and divide by 4 or 5 and you'll get the approximate unRAID equivalent.

 

However, you said you are not using parity, so you might have anything else wrong.  It could easily be a bad LAN cable... Your old MB only needed limited connectivity... are you CERTAIN you have a gigabit LAN connection?

 

Trading from a user-share is slower than from a disk share... more overhead involved...

 

But AS I SAID EARLIER,  without a syslog... you are on your own for analysis.  If you want help, provide the background info others would need.  Now that we know that nothing in your server can be relied upon, and all the cabling is newly connected, everything is a possibility.

 

Your problem could be incorrect voltage, timing, or clock speed settings on your memory strips (they MUST be set for your specific brand/model of memory. Some BIOS try to do it automatically, some get it right, some do not.), or a bad connection, or almost anything else.

 

Joe L.

here is my syslog..

I am certian I have a gigabit connection. I have swapped out cables, with no change. I use Cat6 cable from monoprice. the only thing between my desktop and the server is a dlink gigabit switch, model DGS-2205. I am able to transfer at very very fast speeds to my laptop plugged into the same cable that the unraid box uses, so I know that isnt the issue.

 

The hardware all came out of what used to be my wife's desktop, and it would transfer pc to pc just fine, at speeds approaching 80MB/s.

It is not a cable problem, looks more like a motherboard problem, sorry.  I recommend upgrading to the latest kernel, with better support for your nForce 570 board.  You can also try a couple of the Boot Codes, swncq and noapic, but I'm not confident they will help.

 

IRQ 21 fired, wrongly, and that is bad.  IRQ 21 was assigned to the first 2 SATA ports on the motherboard.  The kernel then disabled the interrupt, which effectively disables your first 2 drives, Disk 1 (sda) and Disk 3 (sdb).  What compounded the problem then, is that the one drive on your SiI3114 card then had trouble too, as if it was tied to those first 2 drives, but should not have had any connection at all.  The drives sda and sdb are onboard, using sata_nv with IRQ 21 and SWNCQ.  Drive sdf is on the card, using sata_sil with IRQ 17 with no NCQ support at all.  Since all 3 drives had trouble essentially simultaneously, it is almost as if sdf tried to fire its interrupt (IRQ 17), but missed and fired IRQ 21 instead, so that caused the disabling of IRQ 21, plus sdf did not get a response on its interrupt, because it called the wrong one.  That's just too crazy though, would mean something seriously wrong, such as bad memory or a bad program bug or a bad motherboard, perhaps bad BIOS.

 

I would run a very long memory test, to rule memory out.  I would then upgrade to v4.5-beta6, for better motherboard support.  And if it still fails similarly, then I would move on to a new motherboard.  Might try looking into a BIOS update too, if there is one.

 

Before you ask, desktop usage is somewhat different than file server usage, stresses different subsystems.

 

By the way, with the newer unRAID version, your NTP support will start working too.

 

Edit:  I got rather speculative above, don't like doing that.  I should have stuck to reporting the bad behavior, without speculating wildly on the cause.

Well, I ran the memcheck all afternoon, and I believe it went through it 3 times.. hasnt found an error in the memory yet..

So I updated to 4.5 beta 6, and I will keep you guys posted to see how it goes.