Guzzi

No idea for that, because I have no PS3. You might try searching the keywords "PS3" and "WakeOnLAN"/MagicPacket. If the PS3 is not capable of sending a Magicpacket and you have another machine running 24/7, you might run a monitoring script there to check is PS3 started and send Magicpacket to Unraid server in that case. Could also be running e.g. on your DSL-router - I know that AVM boxes are running minilinux on them and are capable to send WoL-Packets. Good luck!

Thanks Joe, that worked perfect!

One question to get "GreenIT" running - I tried to get the S3-Syslogmessages Colored: I tried to add match_case||"s3sleep"||green to syslog_match.conf But my syslogentries are still in "black"... Dec 3 11:05:35 XMS-GMI-01 AutoS3sleep[21258]: Switching power state to S3 now Dec 3 21:44:25 XMS-GMI-01 AutoS3sleep[22504]: Returning from Power State S3 now Any hint what is wrong?

I use it with -f -p - but it depends on your MB and if and in what manner it is supported Options: sonne@erde:~> s2ram -h Usage: s2ram [-nhi] [-fspmra] Options: -h, --help: this text. -n, --test: test if the machine is in the database. returns 0 if known and supported -i, --identify: prints a string that identifies the machine. --nofbsuspend do not suspend the framebuffer (debugging only!). -f, --force: force suspending, even on unknown machines. the following options are only available with --force: -s, --vbe_save: save VBE state before suspending and restore after resume. -p, --vbe_post: VBE POST the graphics card after resume -m, --vbe_mode: get VBE mode before suspend and set it after resume -r, --radeontool: turn off the backlight on radeons before suspending. -a, --acpi_sleep: set the acpi_sleep parameter before suspend 1=s3_bios, 2=s3_mode, 3=both -v, --pci_save: save the PCI config space for the VGA card. Google is your friend, e.g. http://de.opensuse.org/S2ram

Manual Test from command line works fine - just inserted it in the Sleepscript and will check after next sleep state (currently not possible due to usage of family ;-) Syslog shows: Nov 24 23:28:15 XMS-GMI-02 AutoS3sleep[11578]: Switching power state to S3 now

Thanks for the hint - one more question: Do I need to follow a "sleep" to give it some time to finish? Well, I can just give it a try and see what happens - will post results... Guzzi

http://lime-technology.com/forum/index.php?topic=4405.30 Did that not work for you? uups, didn't see that - will give it a try, thanks! Hi, this is to confirm s2ram is working fine on my setup. I get the videoscreen back and Eth-link set to 1000 also by the script. Mobo is GA-MA78GM-S2H. Now after looking in the syslog it seems, all messages - also the stuff being done for shutdown - are being written AFTER wakeup and all with same timestamp. Question to the professionals here: Is there the possiblility to write a line within this script to get at least one entry in syslog when machine is sent to suspend (including the timestamp WHEN the script triggered it)? Thanks, Guzzi

http://lime-technology.com/forum/index.php?topic=4405.30 Did that not work for you? uups, didn't see that - will give it a try, thanks!

Kapperz, do you get proper videosignal on the monitor after WOL from S3? I have the precedor of this board (GA-MA780G) and suffer from that problem. No other functional issues beside this. There were hints using S2RAM, but I couldn't find a working slackwarepackage. Thanks, Guzzi

No and you won't.... ACPI doesn't provide for it. Even for drives with power management that will power up in spin-down mode, it won't work. ...so the script you have posted somewhere else for WD drives to get staggered spinup also doesn't work for it? So the reinitialization process includes a command to the disk that ALWAYS spins up the drive? I am not experienced nor do I know enough about the ata protocol and that stuff, just want to make sure i properly understand that and why it's working or not working. Thanks, Guzzi

When I wake my server from S3, it always spins up all drives and does some reinitialization on the ports. I have two questions: 1.) Do others get those errormessages on inizialization also? Is it something to be worried about or is it harmless? 2.) Did anybody find a solution to AVOID the spinup of the drives after WOL? So that just the drives being accessed spin up as in normal operations? I would be interested in a solution or hints into the right direction. Thanks, Guzzi Nov 17 22:37:04 XMS-GMI-02 kernel: ata1.05: SATA link up 1.5 Gbps (SStatus 113 SControl 320) Nov 17 22:37:04 XMS-GMI-02 kernel: ata2.00: failed to IDENTIFY (I/O error, err_mask=0x11) Nov 17 22:37:04 XMS-GMI-02 kernel: ata2.00: revalidation failed (errno=-5) Nov 17 22:37:04 XMS-GMI-02 kernel: ata2.15: hard resetting link Nov 17 22:37:04 XMS-GMI-02 kernel: ata2: controller in dubious state, performing PORT_RST Nov 17 22:37:04 XMS-GMI-02 kernel: ata1.00: failed to IDENTIFY (I/O error, err_mask=0x11) Nov 17 22:37:04 XMS-GMI-02 kernel: ata1.00: revalidation failed (errno=-5) Nov 17 22:37:04 XMS-GMI-02 kernel: ata1.15: hard resetting link Nov 17 22:37:04 XMS-GMI-02 kernel: ata1: controller in dubious state, performing PORT_RST Nov 17 22:37:04 XMS-GMI-02 kernel: ata2.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0) Nov 17 22:37:04 XMS-GMI-02 kernel: ata1.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0) Nov 17 22:37:04 XMS-GMI-02 kernel: ata2.00: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Nov 17 22:37:04 XMS-GMI-02 kernel: ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Nov 17 22:37:04 XMS-GMI-02 kernel: ata2.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Nov 17 22:37:04 XMS-GMI-02 kernel: ata1.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Been running the s3 script for several days and these new changes look great. What would make this perfect for me was if, as its final check, it pinged a list of IPs and if it couldn't reach any of them, then it would go to sleep. I don't know enough to do it myself and am looking for a bit of help on this. I believe someone else mentioned this earlier in the thread, but I don't think it got fleshed out far enough. It's just adding another section after the check of the timeframe. But I better do not post it - I can only do "if-then-else" - those guys here knowing better can easily set a vaiable containing the IP-adresses and have them processed. It should be very easy. So long you can do something like ping 1.2.3.4 -c 1 | grep -q "ttl=" if [ $? -eq 0 ] then ... so you can set a variable that prohibits (or allows) the machine to fall asleep...

Sorry. You guys are far... far ahead of me when it comes to Linux, which is to say that I don't know enough about Linux to write a competent script on my own. Rereading Guzzi's post and looking at the S3.SH script that I am using from awg's wiki, I now understand that Guzzi is refering to modifications he made on his script to check whether his HTPCs were on, and not to the basic script I am using. So Guzzi, if you would be kind enough to share your code I would like to give it a try. [edit]If all the added code does is ping the client for a response, I don't think it will help with the WDTV, because the WDTV does not power off completely. It only "soft-offs" so the network controller remains on. You can even telnet and FTP to it while it's in the "off" state.[/edit] And, WeeboTech, if you could illustrate how to incorporate your idea into the script I would also appreciate it. Though, please note, I am using NFS shares not smb, so maybe it wouldn't help in my case. My apologies for being at the beginning of the learning curve on this stuff and relatively useless at helping myself. Any help would be appreciated. ok, in fact my script is useless for you, if your networkdevice keeps TCP up while "switched off" - it works fine for devices that enter e.g. S3 mode - so, the networkadapter is active and responds on MAC address, but TCP-stack is not running, so it's NOT responding to a ping. For sure I am not good in scriptingstuff, so my script is not elegant, but it does what I need... here is what I added as "check": ping "DNSNameOfDevice or IP-Address" -c 1 | grep -q "ttl=" if [ $? -eq 0 ] then echo HTPC is active else echo HTPC is not active fi One more question from my side - I read somewhere, that it is possible not to spin up the harddrives when waking up the unraid machine from S3 - has anybody successfully done this? To my understanding at least the devices need some reinitialization that usually causes the drives to spin up. Or is this depending on the mobo/BIOS?

The S3 script already checks, if all disks are spun down. I have added checks if the HTPC-machines are up and available (powered on) - so Unraid doesn't go to sleep as long as the HTPCs are running - even if the disks are spun down. Can be done easily e.g. with ping and works fine. Disadvantage: Unraid will never go to S3 if HTPC is running, even if HTPC is not using it.

Thanks - I mounted the disk in the machine and got kernel errors - took me some time to find, it was the 16+ drive bug in current beta release - because I only had 16 drives (15+1, no cache drive). So it seems, the 16+-bug is not only related to the number of drives - but also related to the slots! After deleting super.dat (otherwise unraid always crashed on startup when trying to sync) and moving all drives to the lower slots it works fine ... now syncing...

Hi, I made another preclear on a disk with new cables, that had even syslogerrors before. Syslog is clean now, preclear did it, but tells about one difference in seek error rate. Something to worry about? THanks, Guzzi =========================================================================== = unRAID server Pre-Clear disk /dev/sdg = cycle 1 of 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Testing if the clear has been successful. DONE = Disk Post-Clear-Read completed DONE Disk Temperature: 32C, Elapsed Time: 15:00:48 ============================================================================ == == Disk /dev/sdg has been successfully precleared == ============================================================================ S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 58c58 < 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always - 0 --- > 7 Seek_Error_Rate 0x000e 100 253 051 Old_age Always - 0 ============================================================================

Well... sorry about causing you extra "trouble" but then I figure you might want to avoid extra issues that can be uncovered before you move your files... The cost of a few new drives is small compared to the amount of time and effort needed otherwise. I hope your data transfer goes smoothly once you have a set of disks to move it to. From what you've said, your RAID-5 array would have had to deal with the defects on those two old disks at some point... and it might not have been as easy to swap in a new larger drive. Joe L. I appreciate the help and the abilities of your tools - I didn't complain, just reported back my experience. Please don't misunderstand me - I am happy to discover the problems in advance instead of having the trouble later and yes, you're completely right - the price of a new disk is nothing compared to trouble of a machine and the data on it - that's why I replaced the failing drives quickly with new ones...

Don't you mean... just installing and being surprised, if when something fails :( [...] Yes, you're absolutely right - but you noticed my smiley also, didn't you ... It IS a positive thing to get those extended informations - I appreciate it - and as you might have seen to my last posts: at least 2 drives of my former windows raid-5 do not behave good - and I am more than happy to identify them and throw them out of my box. It's just the thing, that I didn't expect all that extra trouble - my initial plan was just move drives from windows to unraid, move data and finished ;-)

thanks for the infos - did some reading, lot's of details. Hmmm, I'm not sure, if I wasn't happier in total before thinking about my HDs - just installing and being surprised, if something fails ;-) - just kidding - I like the concept of the preclear script very much - once reading and writing the whole HD before using it in production IS a help to discover problems in advance. At least I found 2 harddiscs behaving strange - will have a closer look to them after doing my migration to the healthy drives.

Joe, Thanks for your answer - to be honest, I do not fully understand those values - understand your theory ... is there some sort of standard values to look after when checking drive health? The idea to check the drives is good - but interpreting the values is difficult (at least for me ;-)) - Is it correct that sector reallocation is the thing to have focus on?

Hi, I made another 4 preclears of disks formerly used in another windows raid-5. the Script claims there are some differences pre and post - can you have a look on the message of seekerrorrate and comment on it if it is something to worry? tnx, Guzzi =========================================================================== = unRAID server Pre-Clear disk /dev/sdb = cycle 1 of 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Testing if the clear has been successful. DONE = Disk Post-Clear-Read completed DONE Elapsed Time: 21:41:19 ============================================================================ == == Disk /dev/sdb has been successfully precleared == ============================================================================ S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 58c58 < 7 Seek_Error_Rate 0x000e 100 253 051 Old_age Always - 0 --- > 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always - 0 63c63 < 193 Load_Cycle_Count 0x0032 176 176 000 Old_age Always - 72598 --- > 193 Load_Cycle_Count 0x0032 176 176 000 Old_age Always - 72599 =========================================================================== = unRAID server Pre-Clear disk /dev/sdc = cycle 1 of 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Testing if the clear has been successful. DONE = Disk Post-Clear-Read completed DONE Elapsed Time: 23:20:10 ============================================================================ == == Disk /dev/sdc has been successfully precleared == ============================================================================ S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 58c58 < 7 Seek_Error_Rate 0x000e 100 253 051 Old_age Always - 0 --- > 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always - 0 63c63 < 193 Load_Cycle_Count 0x0032 176 176 000 Old_age Always - 73100 --- > 193 Load_Cycle_Count 0x0032 176 176 000 Old_age Always - 73101 =========================================================================== = unRAID server Pre-Clear disk /dev/sdd = cycle 1 of 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Testing if the clear has been successful. DONE = Disk Post-Clear-Read completed DONE Elapsed Time: 26:25:24 ============================================================================ == == Disk /dev/sdd has been successfully precleared == ============================================================================ S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 58c58 < 7 Seek_Error_Rate 0x000e 100 253 051 Old_age Always - 0 --- > 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always - 0 63c63 < 193 Load_Cycle_Count 0x0032 173 173 000 Old_age Always - 81301 --- > 193 Load_Cycle_Count 0x0032 173 173 000 Old_age Always - 81306 =========================================================================== = unRAID server Pre-Clear disk /dev/sde = cycle 1 of 1 = Disk Pre-Clear-Read completed DONE = Step 1 of 10 - Copying zeros to first 2048k bytes DONE = Step 2 of 10 - Copying zeros to remainder of disk to clear it DONE = Step 3 of 10 - Disk is now cleared from MBR onward. DONE = Step 4 of 10 - Clearing MBR bytes for partition 2,3 & 4 DONE = Step 5 of 10 - Clearing MBR code area DONE = Step 6 of 10 - Setting MBR signature bytes DONE = Step 7 of 10 - Setting partition 1 to precleared state DONE = Step 8 of 10 - Notifying kernel we changed the partitioning DONE = Step 9 of 10 - Creating the /dev/disk/by* entries DONE = Step 10 of 10 - Testing if the clear has been successful. DONE = Disk Post-Clear-Read completed DONE Elapsed Time: 25:00:20 ============================================================================ == == Disk /dev/sde has been successfully precleared == ============================================================================ S.M.A.R.T. error count differences detected after pre-clear note, some 'raw' values may change, but not be an indication of a problem 19,20c19,20 < Offline data collection status: (0x82) Offline data collection activity < was completed without error. --- > Offline data collection status: (0x84) Offline data collection activity > was suspended by an interrupting command from host. 63c63 < 193 Load_Cycle_Count 0x0032 176 176 000 Old_age Always - 72723 --- > 193 Load_Cycle_Count 0x0032 176 176 000 Old_age Always - 72724 ============================================================================

... you couldn't see it, because I didn't access the other drive - as soon as I do e.g. preclear on it, I get the same messages in syslog. I do NOT get any of those errors wth all other drives (did e.g. the reiserfsck on all drives except parity). Cabling is always a mess - I had those problems in the pre-unraid ära (windows raid-5 with the free veritas solution) as well - changed sata cables, chaged powercabling, changed powersupply, etc. The worst problem is those splitters, that you just touch and you hear the drive spindown and up again - just because voltage dropped a bit - this depends also on the brand of the drives - some are more sensitive, some less - at that time I replaced my powercabling from those PC-standard stuff to a more solid powerdistribution - helped a lot. Anyway, regarding this current situation: I have ordered a new drive yesterday, will be delivered today and it will replace those two "in question drives". I can then test those drives in another box when I have time to decide if or if not I can continue using them. If they show ok, I will throw them in my backupbox later. Currently my focus is on getting (or keeping) my main box stable and errorfree to put it "in the corner and forget about it" ;-)

... I'm done... I ran the memorytest overnight - it passed 8 times without errors plus I ran the reisefsck on all data drives - all went through without any errors reported. Checked syslog also, no errors, neither after boot nor after all those activities. Anything else I can / should do? So it seems that those problems are all around those 2 drives ? If so, I probably prefer to dispose them and order 2 new ones - much cheaper than the time it took me to check the whole server ... ;-)

The preclear_disk script is very good at thrashing exercising a disk. As already said, it is far easier to RMA the drives before they are loaded with your data if you find they do not test well. The errors you saw could be because of bad SATA cables or bad power cables/splitters, or even a bad disk controller. But... Remember, your SMART report showed an emergency retraction of the heads to a safe landing spot when it thought the drive was losing power in the middle of the preclearing process. That is pretty drastic as it tries to save itself from a head crash. Is your power supply being overloaded? Are you using a backplane for power distribution? Lots to check out, but, at least you are more informed than most Window's OS users. They just blue-screen. Joe L. Maybe I wastn't completely clear: I have NO data on those 2 "suspicious" drives (they're unassigned and I didn't mount them except for temporal checking if they're empty) - only the array is filled with data (where I didn't encounter problems with the drives so far). The drives are not new - most of them are coming from my former windows box and had been running there as raid-5 for 1-2 years (hope warranty not yet over ...) I never got BSODs on the windows box - but a remember once or twice drives where showing "yellow" - which probably was the same CRC-Problem as now. But nevertheless I have to admit, that there is much more transparence with unraid and linux tools what's "really" happening - windows doesn't help you much with that (just "reactivate" the drive, errors corrected by raid-layer anyway). BTW: I ran the memorytest overnight - it passed 8 times without errors. Will chkdsk the drives when finding the time (currently working with my son on his motorcyle ;-)) The biggest hasstle with those "many-disk-machines (regardless of windows or linux, or something else) is power and cabling - and very difficult to diagnose. Power might be fine for all normal operations - but if you are accessing a disk and at the same time 20 other disks spin up it might pull the voltage down - and I experienced in the past that HDs are VERY sensitive to voltages below 4,8 v on the 5Vrail - to be measured at the drive itself, not somewhere else, because you loose voltage on the cables. Anyway, I thought to be safe, because I operated the windows box and now the unraid box with same powersupply but 8 drives less... so maybe again checking the cables - it seems to be focused on those two ports... So I don't think it's overloaded powerwise, but unraid is in a diffenent box with different cabvles, no powerbackplane and there might be issues - I won't have any other possibility than to check and solve - because there is planned to add the remaining 4 disks from the windowsraid to the unraid-array as soon as the 17+ bug is solved... I hope to soon reach the stage to put the box back in the corner and forget it for the next years ;-)

Thanks Rob, Joe for the feedback. sdn and sdq are the two drives, I currently have not yet in the array - because they both were showing those errors when i first tried setting up the empty array some weeks ago. All other drives are in the array and were fine, showing no errors. Because I didn't trust those 2 drives I ran preclear script to be safe - with the result above. it was the very first time, I encountered such memoryrelated errors, never had it before - but you're right, I had even problems, accessing sambashares after this. I restarted the box and everything is fine so far, no errors at all in the syslog (except this DMA-stuff on the IDE-port - " kernel: atiixp 0000:00:14.1: simplex device: DMA disabled"). BTW: starting preclear on either of those 2 unassigned drives gives me those above "ata12.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0" - errors in the log. They do NOT appear during startup. cache_dirs was not started at all - removed it from go script and rebooted before I moved the files. So it definately cannot be responsible for any memoryrelated stuff. Me too I am worried, if I see such things - I think I will remove both of the drives and test them separately and see, if they need to be RMAed. Will also perform memorytest and chkdsk on all drives as recommended to be sure, everything is fine. And yes, there is already stuff on almost all drives, since I am already moving data during the last weeks. Will post after running the tests. Guzzi