Hi - I am hoping that someone can help me or point me in the right direction.  I built my unRAID server in May and it has been rock solid until this last week.  It has crashed twice in the last 5 days with a kernel panic and requires a restart and then does a parity check. 

 

Details on my build here:

http://lime-technology.com/forum/index.php?topic=3817.0

 

Attached are my current syslog from when the server came back up after the last crash and a picture of the console.  I have lots of DVD content that I am transcoding.  I originally ripped my DVDs to my server in VIDEO_TS format but I decided to transcode with x264 in a mkv container instead.  So, for 2 weeks solid I ran 4 windows PCs  and a windows VM on the unRAID server all reading the VIDEO_TS structure off a SMB share and writing via SMB to another share with the transcoded MKV files.  No issues or problems for those 2 weeks, unRAID was stable and had about 10% CPU free on the server itself.  This was taking way too long, my PCs are all at least 2 years old, so I built a new PC a week ago.  So what is different for the last week is that I replaced the slowest PC with the new one with a Core I7 CPU to transcode faster.  I also changed that all 4 PCs are writing the mkv files into the same folder on the share, before this week each one was writing into a different folder but still on the same share.  I don't see why either of those two changes (new faster PC or writing to the same folder) would cause unRAID to kernel panic but that is the only thing I have changed in the past week.  The last HW change was I added two Segate 2 TB drives (several preclear runs first), one as new parity drive, back on 9/7.

 

Any ideas? Also, is there something I can do to try to preserve the current syslog output in the event of a crash?

 

Thanks!

I don't see why either of those two changes (new faster PC or writing to the same folder) would cause unRAID to kernel panic but that is the only thing I have changed in the past week.

I could understand it a bit, You now have faster machines which can read and write date at a faster pace on the network.

It seems the kernel panic took place with the network driver.

 

I thought I remember reading that the the rt8169 driver in older releases was not that stable. I did not find anything, but it stands out for some reason.

 

Maybe you could try the newer beta's to see how the system handles.

 

Either that or shutdown the vmware instance for a while and test, maybe it is interfering with the network traffic.

Fixed in 2.6.30 so 4.5beta7 should stop it from re-occurring.

 

Caused by a large packet (jumbo frame) hit the r8169 NIC on the unRaid server. You'd need a sniffer running to see where the large packet is coming from.

 

Could be from an external source and may be unrelated to your recent changes or it could be the new NIC and or the high utilization causing an error and creating a "large packet". Make sure all machines are not using or trying to use jumbo frames, if the Gb switch is manageable disable jumbo frames. Make sure your unraid server isn't accessible from outside your network. If your gateway router supports jumbo frames disable them. 

 

If these cant be done then swap out the r8169 (if onboard disable it and add a different NIC).

 

 

This Realtek family of chipsets has become so ubiquitous, widely used, it must be cheap.  And they must consider it reliable enough, at least for desktop use.  Other unRAID users though have also had problems with it.  What you are trying to do with it is beyond normal desktop use.  I would recommend installing an Intel PRO/1000 PCI Express card, for much more robust file server usage, better able to handle the heavy simultaneous traffic streams.  I think WeeboTech was right, you overloaded it.

 

Even overloaded, it should not be crashing the machine like that, so upgrading to the latest is a good suggestion, to at least provide more stable operation.

I forgot to mention that your syslog shows that there were problems in the Reiser file system on the Cache drive (sdl).  There were a LOT of transactions replayed, then some repair work done on the spot.  I suspect transfers were in progress to the Cache drive when it crashed.  Because of the nature of the repairs done, I would run reiserfsck on the drive, see the Check Disk File systems page.  Then if you have a way, I would check the files that were on the Cache disk at that time, they are listed in the syslog as files that were moved by the mover script.  It is possible that one or more have a little corruption in them, or may be incomplete.