TheWombat Posted May 15, 2012 Share Posted May 15, 2012 I seem to be having some issues with RC3 where my UnRaid server appears to freeze. e.g. this evening was copy 20+ gb of files and ended up getting a file copy error in Windows 7. The error displayed is that my UnRaid server/directory is no longer available. On following up I found: a) could not access UnRaid via web browser b) could not access UnRaid via Putty c) The Parity drive and data drive I was writing to were still 'lit' d) the UnRaid server therefore seemed to have disappeared of the network - unable to Ping it etc. e) as I didn't have a keyboard plugged into the server I was unable to do anything but flick the switch. This has happened a couple of times with RC3, so I am switching back to RC2 to see if the same issue occurs. As I flicked the switch there is not a syslog available in /flash/logs however I have attached some prior ones from this morning and previous days in case there is any useful information that can be gleaned. I am assuming the issue is network card related but could be wrong. I have a realtek NIC on my Gigabyte motherboard any thoughts? UPDATE: Similar thing just re-occurred although I was able to Putty in and grab the Syslog (Syslog latest.zip) which is now attached. Alex syslogs.zip syslog_latest.zip Link to comment
opentoe Posted May 16, 2012 Share Posted May 16, 2012 I seem to be having some issues with RC3 where my UnRaid server appears to freeze. e.g. this evening was copy 20+ gb of files and ended up getting a file copy error in Windows 7. The error displayed is that my UnRaid server/directory is no longer available. On following up I found: a) could not access UnRaid via web browser b) could not access UnRaid via Putty c) The Parity drive and data drive I was writing to were still 'lit' d) the UnRaid server therefore seemed to have disappeared of the network - unable to Ping it etc. e) as I didn't have a keyboard plugged into the server I was unable to do anything but flick the switch. This has happened a couple of times with RC3, so I am switching back to RC2 to see if the same issue occurs. As I flicked the switch there is not a syslog available in /flash/logs however I have attached some prior ones from this morning and previous days in case there is any useful information that can be gleaned. I am assuming the issue is network card related but could be wrong. I have a realtek NIC on my Gigabyte motherboard any thoughts? UPDATE: Similar thing just re-occurred although I was able to Putty in and grab the Syslog (Syslog latest.zip) which is now attached. Alex This happens to me also. While I'm transferring files to my unraid box I mostly can't access any other shares or files on the unraid server. Like it is too busy dealing with the copy. I have a dual-core processor in there with 8GB of ram. All 7200 RPM drives so copying files should halt the server. Hopefully just a bug that will get squashed. Link to comment
Jaco2k Posted May 16, 2012 Share Posted May 16, 2012 Speaking of bugs... I have been shutting down my system as always did - press power button on the machine and wait for the shutdown cycle to complete - but after the update from b14 to RC3 I am getting a default Parity Check on every single bootup. How can I get rid of that? This never happened before... Link to comment
prostuff1 Posted May 16, 2012 Share Posted May 16, 2012 Speaking of bugs... I have been shutting down my system as always did - press power button on the machine and wait for the shutdown cycle to complete - but after the update from b14 to RC3 I am getting a default Parity Check on every single bootup. How can I get rid of that? This never happened before... Shut the server down properly from the webGUI Link to comment
Joe L. Posted May 16, 2012 Share Posted May 16, 2012 Speaking of bugs... I have been shutting down my system as always did - press power button on the machine and wait for the shutdown cycle to complete - but after the update from b14 to RC3 I am getting a default Parity Check on every single bootup. How can I get rid of that? This never happened before... i THINK YOU NEED TO STOP THE ARRAY FIRST. Link to comment
PeterB Posted May 16, 2012 Share Posted May 16, 2012 Speaking of bugs... I have been shutting down my system as always did - press power button on the machine and wait for the shutdown cycle to complete - but after the update from b14 to RC3 I am getting a default Parity Check on every single bootup. How can I get rid of that? This never happened before... Shut the server down properly from the webGUI This is always a good idea. However, I believe that the powerdown package, installed through unMENU, will perform a clean powerdown when the power button is pressed briefly - I guess that this is what Jaco is expecting. I've just tested with rc3 and, yes, it still does a clean powerdown. Perhaps Jaco has forgotten to re-install the powerdown package, and/or he is using a long press on the powerbutton. Link to comment
limetech Posted May 17, 2012 Share Posted May 17, 2012 Speaking of bugs... I have been shutting down my system as always did - press power button on the machine and wait for the shutdown cycle to complete - but after the update from b14 to RC3 I am getting a default Parity Check on every single bootup. How can I get rid of that? This never happened before... This is a bug. Link to comment
Jaco2k Posted May 17, 2012 Share Posted May 17, 2012 Speaking of bugs... I have been shutting down my system as always did - press power button on the machine and wait for the shutdown cycle to complete - but after the update from b14 to RC3 I am getting a default Parity Check on every single bootup. How can I get rid of that? This never happened before... This is a bug. Thanks for the reply - do you know when it was introduced so that I can revert to a working one until it gets sorted? Link to comment
PeterB Posted May 17, 2012 Share Posted May 17, 2012 Thanks for the reply - do you know when it was introduced so that I can revert to a working one until it gets sorted? I re-iterate ... I'm running RC3 and get a clean shutdown when I press the power button. If this is a bug, what are the circumstances required to reproduce it? Link to comment
Jaco2k Posted May 17, 2012 Share Posted May 17, 2012 Thanks for the reply - do you know when it was introduced so that I can revert to a working one until it gets sorted? I re-iterate ... I'm running RC3 and get a clean shutdown when I press the power button. If this is a bug, what are the circumstances required to reproduce it? And because it works for you it has to work for everyone else? It was confirmed already it is a bug. Link to comment
prostuff1 Posted May 17, 2012 Share Posted May 17, 2012 And because it works for you it has to work for everyone else? It was confirmed already it is a bug. I am fairly certain PeterB did not mean what he posted to sound harsh. Yes, Tom said it was a bug, but it would still be nice to know what might cause it to happen so that people running RC3 can at least try to avoid making it happen. Link to comment
Jaco2k Posted May 17, 2012 Share Posted May 17, 2012 And because it works for you it has to work for everyone else? It was confirmed already it is a bug. I am fairly certain PeterB did not mean what he posted to sound harsh. Yes, Tom said it was a bug, but it would still be nice to know what might cause it to happen so that people running RC3 can at least try to avoid making it happen. I am going on a limb here and say that it is not gracefully unmounting the shares if something is accessing them. If I have my XBMC machine accessing UnRaid, even after I shutdown XBMC box it still seems to have some "locks" in UnRaid. On previous UnRaid builds it would just take longer to shutdown before it realized the files were not locked anymore. Currently it shuts down normally but something along triggers this Parity check after booting. Steps to reproduce: - Play a video from a share in UnRaid - Stop the video - Press the power button in UnRaid (yes, short press...) - Wait for UnRaid to go through the whole shutdown process (this means, wake the sleeping HDDs and one by one turn them off, etc.) - After UnRaid shuts down, wait 10 seconds and power it up again Expected results: - UnRaid shuts down clean - Upon bootup it is in normal state Actual results - (I am guessing) the Shutdown process is not clean - Upon bootup (repro 100% of times) it is in Parity check mode Link to comment
prostuff1 Posted May 17, 2012 Share Posted May 17, 2012 And because it works for you it has to work for everyone else? It was confirmed already it is a bug. I am fairly certain PeterB did not mean what he posted to sound harsh. Yes, Tom said it was a bug, but it would still be nice to know what might cause it to happen so that people running RC3 can at least try to avoid making it happen. I am going on a limb here and say that it is not gracefully unmounting the shares if something is accessing them. If I have my XBMC machine accessing UnRaid, even after I shutdown XBMC box it still seems to have some "locks" in UnRaid. On previous UnRaid builds it would just take longer to shutdown before it realized the files were not locked anymore. Currently it shuts down normally but something along triggers this Parity check after booting. Steps to reproduce: - Play a video from a share in UnRaid - Stop the video - Press the power button in UnRaid (yes, short press...) - Wait for UnRaid to go through the whole shutdown process (this means, wake the sleeping HDDs and one by one turn them off, etc.) - After UnRaid shuts down, wait 10 seconds and power it up again Expected results: - UnRaid shuts down clean - Upon bootup it is in normal state Actual results - (I am guessing) the Shutdown process is not clean - Upon bootup (repro 100% of times) it is in Parity check mode The only question i have is: by stopping the video are you pressing stop in the video player but leaving the application open/running. If you are then that app still has access to the video and it should be locked. An unclean shutdown would likely be the result of that. If you quit the app the resource should be released and a clean shutdown should happen. Either way for me, i use clean powerdown so I rarely get a parity check on reboot unless I did something completely wrong or the server froze. Link to comment
PeterB Posted May 17, 2012 Share Posted May 17, 2012 And because it works for you it has to work for everyone else? That is not what I said! For your sake, and that of the rest of the community, I tried to replicate your problem (on my live system) and, to my surprise, the system came back up clean. It was confirmed already it is a bug. Yes, so it would be helpful for all of us to know the circumstances necessary to provoke this bug ... so that we can replicate it if we wish or, more usefully, avoid it. Link to comment
TheWombat Posted May 17, 2012 Author Share Posted May 17, 2012 Further to my previous post on RC3 seeming to lose network connectivity I noticed the following line in one of my SysLogs: May 13 22:59:41 NAS-03 kernel: INFO: rcu_sched_state detected stall on CPU 3 (t=6000 jiffies) This seemed a little odd as I had disabled 2 cores in my AMD X4 via the BIOS many months ago, however I'd just (in the last few days) upgraded my BIOS on my motherboard (and still kept 2 cores disabled) in order to allow me to update the firmware of my SAS cards to .21. This may be a complete red-herring to the issues I have been having with RC3, or it might be related to the BIOS upgrade to my motherboard however I find it odd that with 2 cores disabled in BIOS that UnRaid is still registering 4 CPUs i.e.: May 14 19:08:14 NAS-03 kernel: Total of 4 processors activated (8036.70 BogoMIPS). Whereas when I go into BIOS and enable all 4 cores, it shores 4 processors but a higher BogoMIPS count: May 16 14:02:39 NAS-03 kernel: Total of 4 processors activated (22504.65 BogoMIPS). I am currently back on RC2 and with all 4 Cores enabled and the previous issues with network connectivity dropping seem to have disappeared (so far) and I've copied many GBs of data over to UnRaid now. It therefore appears to be either a BIOS issue with my motherboard when disabling Cores, or it is an RC3 issue.I'm busy for the next few days, however when I get the chance I'll go back to RC3 (with all 4 cores enabled) and see if I get the issues again. If I don't then it would seem the issue is something to do with having cores disabled (on my motherboard with the BIOS version I have). SysLog with 2 cores disabled May 14 19:08:14 NAS-03 kernel: CPU0: AMD Athlon II X4 630 Processor stepping 02 May 14 19:08:14 NAS-03 kernel: Performance Events: AMD PMU driver. May 14 19:08:14 NAS-03 kernel: ... version: 0 May 14 19:08:14 NAS-03 kernel: ... bit width: 48 May 14 19:08:14 NAS-03 kernel: ... generic registers: 4 May 14 19:08:14 NAS-03 kernel: ... value mask: 0000ffffffffffff May 14 19:08:14 NAS-03 kernel: ... max period: 00007fffffffffff May 14 19:08:14 NAS-03 kernel: ... fixed-purpose events: 0 May 14 19:08:14 NAS-03 kernel: ... event mask: 000000000000000f May 14 19:08:14 NAS-03 kernel: CPU 1 irqstacks, hard=f3096000 soft=f3098000 May 14 19:08:14 NAS-03 kernel: Booting Node 0, Processors #1 May 14 19:08:14 NAS-03 kernel: smpboot cpu 1: start_ip = 93000 May 14 19:08:14 NAS-03 kernel: Initializing CPU#1 May 14 19:08:14 NAS-03 kernel: System has AMD C1E enabled May 14 19:08:14 NAS-03 kernel: CPU 2 irqstacks, hard=f30a6000 soft=f30a8000 May 14 19:08:14 NAS-03 kernel: #2 May 14 19:08:14 NAS-03 kernel: smpboot cpu 2: start_ip = 93000 May 14 19:08:14 NAS-03 kernel: Switch to broadcast mode on CPU1 May 14 19:08:14 NAS-03 kernel: Initializing CPU#2 May 14 19:08:14 NAS-03 kernel: Switch to broadcast mode on CPU2 May 14 19:08:14 NAS-03 kernel: CPU 3 irqstacks, hard=f30b2000 soft=f30b4000 May 14 19:08:14 NAS-03 kernel: #3 May 14 19:08:14 NAS-03 kernel: smpboot cpu 3: start_ip = 93000 May 14 19:08:14 NAS-03 kernel: Initializing CPU#3 May 14 19:08:14 NAS-03 kernel: Brought up 4 CPUs May 14 19:08:14 NAS-03 kernel: Switch to broadcast mode on CPU3 May 14 19:08:14 NAS-03 kernel: Total of 4 processors activated (8036.70 BogoMIPS). -------------------------------------------------------------------------------------- Syslog with all 4 cores enabled May 16 14:02:39 NAS-03 kernel: CPU0: AMD Athlon II X4 630 Processor stepping 02 May 16 14:02:39 NAS-03 kernel: Performance Events: AMD PMU driver. May 16 14:02:39 NAS-03 kernel: ... version: 0 May 16 14:02:39 NAS-03 kernel: ... bit width: 48 May 16 14:02:39 NAS-03 kernel: ... generic registers: 4 May 16 14:02:39 NAS-03 kernel: ... value mask: 0000ffffffffffff May 16 14:02:39 NAS-03 kernel: ... max period: 00007fffffffffff May 16 14:02:39 NAS-03 kernel: ... fixed-purpose events: 0 May 16 14:02:39 NAS-03 kernel: ... event mask: 000000000000000f May 16 14:02:39 NAS-03 kernel: CPU 1 irqstacks, hard=f3096000 soft=f3098000 May 16 14:02:39 NAS-03 kernel: Booting Node 0, Processors #1 May 16 14:02:39 NAS-03 kernel: smpboot cpu 1: start_ip = 93000 May 16 14:02:39 NAS-03 kernel: Initializing CPU#1 May 16 14:02:39 NAS-03 kernel: System has AMD C1E enabled May 16 14:02:39 NAS-03 kernel: CPU 2 irqstacks, hard=f30a6000 soft=f30a8000 May 16 14:02:39 NAS-03 kernel: #2 May 16 14:02:39 NAS-03 kernel: smpboot cpu 2: start_ip = 93000 May 16 14:02:39 NAS-03 kernel: Switch to broadcast mode on CPU1 May 16 14:02:39 NAS-03 kernel: Initializing CPU#2 May 16 14:02:39 NAS-03 kernel: Switch to broadcast mode on CPU2 May 16 14:02:39 NAS-03 kernel: CPU 3 irqstacks, hard=f30b2000 soft=f30b4000 May 16 14:02:39 NAS-03 kernel: #3 May 16 14:02:39 NAS-03 kernel: smpboot cpu 3: start_ip = 93000 May 16 14:02:39 NAS-03 kernel: Initializing CPU#3 May 16 14:02:39 NAS-03 kernel: Brought up 4 CPUs May 16 14:02:39 NAS-03 kernel: Switch to broadcast mode on CPU3 May 16 14:02:39 NAS-03 kernel: Total of 4 processors activated (22504.65 BogoMIPS). Link to comment
TheWombat Posted May 17, 2012 Author Share Posted May 17, 2012 I spoke too soon, copy ~40 GB of small files in batches of 2-8GB worked fine, then just tried to copy a 45GB ISO image and the server froze.. I couldn't even use the plugged in keyboard to do anything. I will revert back to rc1 and see if the issues goes away. TheWombat Link to comment
opentoe Posted May 24, 2012 Share Posted May 24, 2012 Any update on this? Maybe related to some other issues I'm having too. Link to comment
TheWombat Posted May 25, 2012 Author Share Posted May 25, 2012 Update from me. I have just successfully copied the same 43GB file across using RC1. This is the file that failed with RC2 and RC3. Note: that I also had noticed failures with RC2/3 when copying sizeable (10GB+) sets of small files (i.e. individual file size < 5MB-10MB) I'm unsure if the issues in RC2/3 are due to my Realtek motherboard LAN port. It is a RTL8111D/E chip Let me know if there is any other information I can provide to help. Alex Link to comment
RobJ Posted May 25, 2012 Share Posted May 25, 2012 Update from me. I have just successfully copied the same 43GB file across using RC1. This is the file that failed with RC2 and RC3. Note: that I also had noticed failures with RC2/3 when copying sizeable (10GB+) sets of small files (i.e. individual file size < 5MB-10MB) I'm unsure if the issues in RC2/3 are due to my Realtek motherboard LAN port. It is a RTL8111D/E chip Let me know if there is any other information I can provide to help. Alex The primary difference between rc1 and rc2/rc3 is that the Linux kernel was reverted to the 3.0.x series, rc1 used the 3.3.x series kernel. Earlier you pointed out possible issues with the CPU support in rc2/rc3. It sounds to me as if one possible explanation here is that the 3.3.x kernels include better support for your CPU and/or motherboard. Unfortunately, the kernels that followed 3.0.x appear to break LSI chipset support, required by many users here. If my theory here is true, then you may have to wait for a future version that includes a newer kernel that also correctly supports the LSI chips. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.