Link to home
Start Free TrialLog in
Avatar of vwgtiturbo
vwgtiturbo

asked on

Suse 10 and Wake on LAN

Hello, I have spent about 60 hours trying to work out a scenario, and I am at wits end. I am to the point that I am considering REmigrating back to WinXP...

Okay, I have a home network with three machines (along with two not networked). I have a WinXP machine (wife's) and a WinXP/Suse 10 machine (mine), along with a machine that is built to be a backup server, running Suse 10 (at least, that was the plan). What I wanted to do is have my wife's machine (#1) and my machine (#2) perform a Wake on LAN function to the backup server (#3), run the backups, then power #3 off. However, my backup server's Wake on LAN isn't working. Here are some specs about the machines:

#1 (Not really important at this point)
#2 Asus A8V Deluxe with Marvell integrated NIC
#3 DFi Lanparty UT NF4 Ultra D with 2 x Intel Pro/1000MT NICs, 1 x Vitesse integrated NIC, 1 x Marvell integrated NIC

All machine's BIOSes are set to allow WOL(PME)...

Now, using #3 (backup server)... I started only using the two Intel NICs, with the onboard NICs disabled. My ACPI settings in the BIOS reflect 'S1&S3'... If I shut down before Linux loads, using the power button on the case, WOL works. However, if I let Linux load, then shutdown through the OS, the NIC is powered down (as evidenced by my link indicator on the router going out). I used ethtool to find out if WOL is enabled with the kernel module (e1000) and it is by default. I decided to give up on the PCI NICs, and removed them. I then enabled the onboard NICs. I setup both NICs through Suse's YaST and all seemed well. I used ethtool again on both NICs, and they are WOL capable, but it was disabled in the module (sk98lin) by default , I used 'ethtool -s ethx wol g' to enable WOL on both NICs and verified it through ethtool. Still, no workie.

Just for grins, as I was pulling out my hair, I went over to my personal machine (#2) and ran ethtool to verify it's WOL capability. It was capable, but not enabled in the module. So, using ethtool, I enabled this, and verified it. However, this machine also will not WOL. The net link indicator goes out when the machine shutsdown... unless I use the power switch on the case before Linux loads.

For grins, I decided to try this on my work machine (#4), which also runs Suse 10... This machine consists of some MSI motherboard, with an integrated Via Rhine NIC. This is so odd... I used ethtool to verify if the NIC would do WOL, and it could. I shutdown the machine, not even thinking to look in ethtool to see if WOL is enabled in the kernel module. When I shutdown, the activity indicator on my router DID NOT go out, so even though this doesn't prove that WOL works, at least the NIC seems to be powered. Now the kicker... when I booted back into Suse, I ran ethtool on the NIC and WOL was DISABLED!! On #4, it doesn't matter if the kernel module has WOL enabled or not, the NIC still links to the router when the machine is powered off. I am stumped...

Basically, Linux doesn't leave the NIC powered when the system goes down, but the computer itself DOES if I shut the computer off using the case's power switch...


**** In further developments... I have been using lspci and pci-tool to set the power state of the PCI NICs to D3 (sleep) instead of D0. I put this in a script, then verified that it worked. It did work, so I put the script into /etc/init.d/halt.local, and I can see that it happens AFTER the NICs are shutdown (the power state is applied after NIC shutdown), yet my link is lost and the NICs are dead when the computer shuts down.
Avatar of Gabriel Orozco
Gabriel Orozco
Flag of Mexico image

Following your post, I went to a SuSE I administer, and follow the halt process (just cat /etc/init.d/halt and then went to /etc/init.d/boot.d/ and then reviewed scripts there) and found interfaces are started/stoped at
/etc/init.d/boot.coldplug

and checking it found /sbin/hwdown is being used to shutdown the nic. that command it's also a script, so I dig on it.

it's more or less complex, but there are the step when modules are unloaded, and the step where interfase cards are shut down.

Since this command runs (per the halt command) *after* your halt.local, then there is why you cannot make your script work.
I would add your commands
a) reviewing and modifying the complex /sbin/hwdown script so it handles correctly WOL nics
b) at /etc/init.d/boot.coldplug. should work but it's not the best place if you do not check correctly where to do it, or...
c) at /etc/init.d/halt, just after you send the order to boot.d directory to stop, you can bring back your nic to D3 againt, and then the computer is turned off.

I think SuSE still has a long way to automate correctly all their steps... I myself have catched several errors on the automation scripts. However, it's improving daily...

I would not consider even to go back to windows if I can ;-)

Regards
Avatar of vwgtiturbo
vwgtiturbo

ASKER

I am not sure if this matters or not, but... You stated that halt.local happens prior to the network shutdown, which is why my commands for D3 wouldn't work, but looking at the verbose kernel messages while the machine is shutting down, the interfaces are shutdown prior to my script taking place. I will adding the command to halt, and see what that gives me. Thanks for the reply.
I tried adding the pci-config stuff to halt, but it still didn't work. I didn't have a monitor connected to the system (I disconnected it last night so I could reconnect it to my wife's machine), so I am not sure if there were any errors (maybe with my entries into the script) so I don't know if everthing went as it was supposed to or not... I will try to get a monitor hooked up to it, maybe connect it via a KVM switch, and see what happened.
just be sure you are suplying the full paths since many things would be disabled by that point.

if at that step you cannot make changes to the status of your card, maybe you will need to load its module again, -or- edit the previous script...
Will I be able to load the module again, as the filesystems should already be unmounted (right?). I don't know for sure, I am just guessing at this point...
it depends on the point you inserted your commands. normally filesystems are the last are unmounted
Okie dokie, well, I hooked up the KVM switch, and this is now a little easier, even though my home office is a little bit of a wreck...
I tweaked this script a little, just to give me more feedback about what was happening as the machine went down. Basically, I told the system to reload the kernel module for the NICs. It responded by saying it was already loaded. WOL STILL won't work. Man, this is stubborn...
Here is what I have in the script so far. Don't laugh too hard... I am still a newbie at most of this stuff...

>>

echo "Reinserting Kernel Module e1000.ko for Intel NICs."
insmod /lib/modules/2.6.13-15-default/kernel/drivers/net/e1000/e1000.ko
echo "Here are the NIC's current power states..."
echo
echo "Eth0's power state:"
/usr/local/bin/pci-config -B 1 -#1 | grep Power
echo
echo "Eth1's power state:"
/usr/local/bin/pci-config -B 1 -#2 | grep Power
echo
echo "Now putting NICs into D3 Sleep mode..."
/usr/local/bin/pci-config -S -B 1 -#1
/usr/local/bin/pci-config -S -B 1 -#2
echo
echo "Here are the NIC's new power states..."
echo
echo "Eth0's power state:"
/usr/local/bin/pci-config -B 1 -#1 | grep Power
echo
echo "Eth1's power state:"
/usr/local/bin/pci-config -B 1 -#2 | grep Power
echo
echo "NIC power states successfully changed."
echo
echo "Removing Kernel Module for Intel NICs..."
rmmod e1000
echo "Kernel module successfully removed."
echo "Hopefully, WOL works after this..."

>>
echo "Reinserting e1000 kernel module for Intel NICs..."
insmod /lib/modules/2.6.13-15-default/kernel/drivers/net/e1000/e1000.ko

echo "Putting NICs into D3 Sleep mode..."
/usr/local/bin/pci-config -S -B 1 -#1 | grep Power
/usr/local/bin/pci-config -S -B 1 -#2 | grep Power
sleep 5
echo "Here are the NIC's current power states..."
echo "NIC #1's power state (looking for D3):"
/usr/local/bin/pci-config -a -B 1 -#1 | grep Power
echo "NIC #2's power state (once again, looking for D3):"
/usr/local/bin/pci-config -a -B 1 -#2 | grep Power
sleep 5
echo "Removing Kernel Module for Intel NICs..."
rmmod e1000
echo "Kernel module successfully removed."
echo "Hopefully, WOL works after this..."
>>

Maybe I should try Slackware again. I haven't used that one in a while...
I think you should not rmmod modules. left them loaded.

and yes, I tried SuSE and at least for servers, I'm back with Slackware again.
Okay, I commented out the rmmod line, and instead of this:

echo "Now putting NICs into D3 Sleep mode..."
/usr/local/bin/pci-config -S -B 1 -#1
/usr/local/bin/pci-config -S -B 1 -#2

I put in:

echo "Now putting NICs into D3 Sleep mode..."
/usr/local/bin/pci-config -S -B 1 -#1 | grep Power > /dev/null
/usr/local/bin/pci-config -S -B 1 -#2 | grep Power > /dev/null

Basically, it was spitting out too much info, and I needed a way to cut it down a bit. I wasn't sure if the commands would work if I put > /dev/null in there, so I addedd the grep stuff, just to be cautious. Like I said, I am a newb, so I don't lay claim to knowing what I am doing all the time...

The link to the router still dies on shutdown, but I am going to look at it one more time tonight before I give up for the evening, and try to see WHERE in the shutdown it is dying. Maybe it will give me something to look for...
Is it possible to edit a comment? It looks like I went a little crazy with the copy and paste a couple of posts back...
Okay, I changed the script a bit, as the NICs were going down (as they should) and not coming back up when the power states were to be applied. Here is the new (and hopefully improved) script:

>>

echo
echo "Bring network interfaces back up..."
ifconfig eth0 up
ifconfig eth1 up
sleep 3
echo "Here are the NIC's current power states..."
echo "Eth0's power state:"
/usr/local/bin/pci-config -B 1 -#1 | grep Power
sleep 2
echo "Eth1's power state:"
/usr/local/bin/pci-config -B 1 -#2 | grep Power
sleep 2
echo
echo "Now putting NICs into D3 Sleep mode..."
/usr/local/bin/pci-config -S -B 1 -#1 | grep Power > /dev/null
sleep 3
/usr/local/bin/pci-config -S -B 1 -#2 | grep Power > /dev/null
sleep 3
echo
echo "Here are the NIC's new power states..."
echo "Eth0's power state:"
/usr/local/bin/pci-config -B 1 -#1 | grep Power
echo "Eth1's power state:"
/usr/local/bin/pci-config -B 1 -#2 | grep Power
echo
echo "NIC power states successfully changed."
echo
#echo "Removing Kernel Module for Intel NICs..."
#rmmod e1000
#echo "Kernel module successfully removed."
echo "Hopefully, WOL works after this..."
sleep 3

<<

Now, looking at the link with the router, this works okay. The NICs go down as they should, they come back up as they should. BUT, for some reason, they go back down at the point that it says "Now putting NICs into D3 Sleep mode...".
I am done for the night. If I can't figure anything out, I guess Slackware will go on tomorrow, and hopefully I will have better luck...
I would just do (for simplicity and try just to enable sleeping mode)

-----------------------
echo "Bring network interfaces back up..."
ifconfig eth0 up
ifconfig eth1 up

echo "Now putting NICs into D3 Sleep mode..."
/usr/local/bin/pci-config -S -B 1 -#1 | grep Power > /dev/null
sleep 3
/usr/local/bin/pci-config -S -B 1 -#2 | grep Power > /dev/null
----------------------
Alright, this isn't working. I am just going to put another OS on it. I will try Slackware, or maybe CentOS. If neither one of those works, I will go back to WinXP. I KNOW it works with XP, and seeing it is something I need, I have to go with what works. I suppose this question can be deleted. I figure that if 5 forums and experts exchange can't answer it, that it just can't be answered. Thanks a lot for all of your time.
ASKER CERTIFIED SOLUTION
Avatar of Gabriel Orozco
Gabriel Orozco
Flag of Mexico image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Well, I just thought I would let you know... I installed Slack 10.2 today. I did a basic install, choosing the bareacpi kernel, and when I shut the machine down, the NIC link to the router stayed up. I was SUPER antsy to test it, but I couldn't right away because my desktop machine (also a Suse 10 box) would not boot due to filesystem errors, and e2fsck is having a hard time with it. It looks to me like the OpenSuse Eval (that I used to use) actually performs better and more reliably, than the retail version... Anyways, I went over to my wife's machine, opened up a GUI Wake on LAN utility for Windows, and it WORKS!! WOOHOO!! So, basically, one of, if not THE, most user-friendly distros can't handle Wake on LAN even after some MAJOR work, yet Slackware, typically one of the most user-unfriendly distros, works OUT OF THE BOX!! I knew there was a reason that I liked Slackware a few years ago... Thanks a lot for the 'Go to Slackware' prodding. I probably would've ended up going back to XP, and we don't need that!