Whaler_99 Posted April 23, 2011 Share Posted April 23, 2011 This has happened multiple times to me know. The entire unit completely locks up. Even hitting the power button or CTRL+ALT+DEL doesn't invoke the cleanshutdown. System is completly frozen. Only seems to happen when writting data to the system. But, not always. Ran a memtest for hours, everthing showed ok. Have tried swapping memory, same issue. The system just froze on me while doing a data rebuild - after i identified my disk1 was bad. Here is the tail... Apr 23 09:40:30 Tower emhttp: shcmd (36): killall -HUP smbd Apr 23 09:40:30 Tower emhttp: shcmd (37): /etc/rc.d/rc.nfsd restart | logger Apr 23 09:41:00 Tower cache_dirs: ============================================== Apr 23 09:41:00 Tower cache_dirs: command-args=-w -m 1 -M 10 -d 2 -a -noleaf Apr 23 09:41:00 Tower cache_dirs: vfs_cache_pressure=10 Apr 23 09:41:00 Tower cache_dirs: max_seconds=10, min_seconds=1 Apr 23 09:41:00 Tower cache_dirs: max_depth=2 Apr 23 09:41:00 Tower cache_dirs: command=find -noleaf Apr 23 09:41:00 Tower cache_dirs: version=1.6.5 Apr 23 09:41:00 Tower cache_dirs: ---------- caching directories --------------- Apr 23 09:41:00 Tower cache_dirs: Backups Apr 23 09:41:00 Tower cache_dirs: KidsVideos Apr 23 09:41:00 Tower cache_dirs: LogansVideos Apr 23 09:41:00 Tower cache_dirs: MSIso Apr 23 09:41:00 Tower cache_dirs: Music Apr 23 09:41:00 Tower cache_dirs: MyData Apr 23 09:41:00 Tower cache_dirs: NewMovies Apr 23 09:41:00 Tower cache_dirs: TVRecordings Apr 23 09:41:00 Tower cache_dirs: WatchedMovies Apr 23 09:41:00 Tower cache_dirs: ---------------------------------------------- Apr 23 09:41:00 Tower cache_dirs: cache_dirs process ID 5292 started, To termina te it, type: cache_dirs -q Apr 23 09:45:28 Tower ntpd[1506]: synchronized to 208.69.56.110, stratum 2 Apr 23 09:47:09 Tower sSMTP[9388]: Creating SSL connection to host Apr 23 09:47:10 Tower sSMTP[9388]: SSL connection using RC4-SHA Apr 23 09:47:14 Tower sSMTP[9388]: Sent mail for root@ (221 2.0.0 closing connec tion l1sm2247452bkl.1) uid=0 username=root outbytes=1533 Apr 23 10:47:09 Tower sSMTP[25478]: Creating SSL connection to host Apr 23 10:47:10 Tower sSMTP[25478]: SSL connection using RC4-SHA Apr 23 10:47:14 Tower sSMTP[25478]: Sent mail for root@ (221 2.0.0 closing conne ction x6sm2268104bkv.12) uid=0 username=root outbytes=1534 Apr 23 11:44:30 Tower kernel: r8169: eth0: link up Apr 23 11:45:02 Tower last message repeated 7 times As per my sig, this is the system I am running. Anyone have any ideas on what to try now? This gear worked fine in another system. Only things I change recently was the mobo/cpu/ram upgrade. Maybe just fall back to that for the time being? Thanks, Shawn Edit - one thing I thought of, I have one disk mounted via SNAP - that I have some real time backups of my Windows systems running against. Anyone had issues with SNAP freezing up the system? Quote Link to comment
PeterB Posted April 23, 2011 Share Posted April 23, 2011 Here is the tail... ..... Apr 23 11:44:30 Tower kernel: r8169: eth0: link up Apr 23 11:45:02 Tower last message repeated 7 times I don't understand why you should get "eth0: link up" reported eight times in 30 seconds! Quote Link to comment
Whaler_99 Posted April 23, 2011 Author Share Posted April 23, 2011 I know - I previously posted about this specifically Here. Very weird - only shows up when writting data to the system, either the array or SNAP. Quote Link to comment
Whaler_99 Posted May 1, 2011 Author Share Posted May 1, 2011 Well, finally think I solved this. So far a bunch of copies have worked. Disabled the on-board NIC on the mobo, which is a Realtek, and added in a HP PCI-E dual port NIC that I had. No longer getting those "link up" messages and no freezes. Maybe an issue with this particular Realtek version? Shawn Quote Link to comment
LaurentHU Posted May 2, 2011 Share Posted May 2, 2011 Up on this one - it seems it's not only happening in a few MBs but rather wider on Realtek NICs... Did we find a real 4.7 bug? Quote Link to comment
prostuff1 Posted May 2, 2011 Share Posted May 2, 2011 Up on this one - it seems it's not only happening in a few MBs but rather wider on Realtek NICs... Did we find a real 4.7 bug? It is probably a driver issue, which unRAID does not have much control over. They use the driver that is provided by the kernel. I have a realtek NIC in my production system (on my gigabyte board) and have never had a problem with it. I have run nearly every stable release of unRAID since 4.5.6 and am running 5.0b6a right now. Quote Link to comment
Whaler_99 Posted May 2, 2011 Author Share Posted May 2, 2011 Which realtek chipset are you both running? According to what I saw on my system via the "tail" command, looks like unRaid thought mine was a r8169. According to the mobo, it is a Realtek 8111E. Here is Link to my motherboard. Shawn Quote Link to comment
prostuff1 Posted May 2, 2011 Share Posted May 2, 2011 According to my specs I am running the Realtek 8111C and the driver that is reported is the r8169 Quote Link to comment
Whaler_99 Posted May 2, 2011 Author Share Posted May 2, 2011 According to my specs I am running the Realtek 8111C and the driver that is reported is the r8169 I wonder if that may be some of the problem... this distro using the same driver for different chipsets, which is causing screwups.... Going to look around the shop, see if I can find any other Realtek nic's I can test on this... hopefully of the 8111x flavor... Shawn Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.