Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
My Sun Microsystems Ultra24 rig has a problem which up to now I’ve chalked up to a crap BIOS.
It happened with the previous (original) version it came with and with this one, which is the latest one available.
I'm on Devuan latest:
Code:
groucho@devuan:~$ uname -a
Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
groucho@devuan:~$
1. shut down properly
2. shut down properly and after about 5s. reboot start reboot and freeze
3. freeze during the shutdown at this point ...
Code:
e1000e: EEE Tx LPI Timer
Preparing to enter sleep state S5
Reboot: Power Down
… with the fans blowing at full speed.
This happens ocasionally and I have not been able to reliably reproduce the behaviour, no idea what causes it.
It happened when I only had wireless access ie: before I had a wired connection and it also happens now.
Unfortunately, there’s no way of disabling the on board e1000e controller (you see, as this Sun MoBo has IME, that would be a no-no).
Could it be that (at least part of the issue) is caused by this bug:
General
When power button is pressed: Shutdown
When sleep button is pressed: Do nothing
When hibernate button is pressed: Do nothing
System
System sleep mode: Suspend
Put sytem to sleep when inactive for: Never
This also happened with other distros I have tried before settling with Devuan.
Previous owner of the rig used a Gates OS but I don’t think he would have mentioned this anyway.
I have not found a way to log what is happening so as to be able to get a better idea of what is happening.
I’d appreciate any suggestions you may have as this is a real PITA.
Are there any wake-on-lan settings? If so, can you disable them?
GbE LAN Boot option in BIOS is disabled and Suspend option is set to S1 (POS), the other option being S3 (STR).
System sleep mode is set to 'Never' so I guess it wouldn't matter.
For logging it, run acpid with a '-l' option, which logs events to syslog. Don't presume that because you set something up in XFCE, it will happen. XFCE's power manager has the power to screw things up, but never to straighten them out, in my experience.
As for power saving states, S3 = suspend, S5 = hibernate. Sopmething is hibernating and nothing is going off directly.
Try booting with the boot parameter "resume=/dev/<your-swap-partition>", & enable hibernate. For power off, run
For logging it, run acpid with a '-l' option, which logs events to syslog.
OK.
Do I add it to the boot string?
I expect that if I run it on a terminal it would not survive a reboot.
Quote:
Originally Posted by business_kid
... because you set something up in XFCE, it will happen.
XFCE's power manager has the power to screw things up, but never to straighten them ...
Good to know.
But I did not have Xfce's power manager installed and did so before posting to see what was going on. After installing it, I applied the settings I mentioned previously.
As part of this even on-going search for a solution, I set the Suspend option in BIOS to S1 (POS), it was previously set at S3 (STR).
I have not had another episode since (knock on wood) but that does not mean anything: I've gone for a week or so without one, with me thinking I finally had it tied down and then it reared it's ugly head again.
Quote:
Originally Posted by business_kid
... S3 = suspend, S5 = hibernate.
Something is hibernating and nothing is going off directly.
Yes, that is exactly what was bugging me.
Where did it come from?
There was nothing set for the system to do that.
I've never been a fan of hibernating or any other thing other than a basic S1 suspend.
Not even with my netbooks, I simply don't trust it working properly.
Comes from my other life when I ran MS OSs.
But in any case, my rig is not a portable even though the BIOS IDs the it as one. (!)
That's what Oracle dining on Sun Microsystems got us all. 8^|
A further update:
I've made some headway and managed to configure ACPID -l at boot in etc/default/acpid.
Code:
# Options to pass to acpid
#
# OPTIONS are appended to the acpid command-line
# enabled 20181108 to log events to syslog
OPTIONS="-l"
#
# Linux kernel modules to load before starting acpid
#
# MODULES is a space separated list of modules to load, or "all" to load all
# acpi drivers, or commented out to load no module
#MODULES="battery ac processor button fan thermal video"
#MODULES="all"
Now syslog says:
Code:
Dec 8 18:23:32 devuan acpid: waiting for events: event logging is on
So now I guess I can expect that the next time I get the freeze something should get logged in syslog.
Hopefully the entry will tell me what is calling for S5 in a rig that has anything S5 related turned off.
I'll have to wait for the next one and see what it is.
Yes.
Power Management is set to 'Disabled', Power Button Mode is set to 'On/Off'.
As I don't leave my rig on all day (if I'm not using it) day or leave the screen more than 10', I don't think it matters much if my setting is S1 or S3, but I understand your point.
Now to see what is wanting to go S5 on me instead of shutting down and why.
Where else can I look?
S5 is actually good, as long as you reboot the same kernel ...
I'll look into S5 as soon as I get this one figured out.
I may have made some headway.
By looking at the /var/log I found there is a pm-powersave.log, so I checked it for eth0 activity.
Sure enough:
Code:
groucho@devuan:~$ cat /var/log/pm-powersave.log | grep -i eth0
Setting Wake On Lan for eth0 to enable...Done.
--- snip ---
Setting Wake On Lan for eth0 to enable...Done.
groucho@devuan:~$
No time stamps but from the look of it, it's once at every boot.
There's a script somewhere that enables WoL but where?
"Note that some motherboards are affected by a bug that can cause immediate or random #Wake-up after shutdown whenever the BIOS WoL feature is enabled."
With a follow up down below:
Quote:
Originally Posted by Link
Troubleshooting
Wake-up after shutdown
It is known that some motherboards are affected by a bug that can cause immediate or random wake-up after a shutdown whenever the BIOS WoL feature is enabled (as discussed in this thread for example). The following actions in the BIOS preferences can solve this issue with some motherboards:
1. Disable all references to xHCI in the USB settings (note this will also disable USB 3.0 at boot time)
2. Disable EuP 2013 if it is explicitly an option
3. Optionally enable wake-up on keyboard actions
Note: There are mixed opinions as to the value of #3 above and it may be motherboard dependent.
So the culprit is as I thought a motherboard/BIOS bug but in combination with WoL being enabled.
WRT to the options listed above, #1 won't do as I use USB a lot, #2 is not explicitly an option as my rig is from 2007 and does not have that and with #3, if my rig ever goes into S1 it wakes up with the kb/mouse so it is already enabled.
As I do not need or want WoL, I decided that the best was to disable it.
Which will also keep the motherboard bug from cropping up.
rant
It really nags me that it is enabled. Why is it enabled and who enabled it?
/rant
To check the e1000e driver settings, I used ethtool, which I only now found out about.
Code:
[root@devuan groucho]# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbgWake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
[root@devuan groucho]#
Just like the log file says, WoL is enabled, and ethtool can be used to set the WoL parameters:
Code:
# ethtool -s interface wol [x]
The possible settings for x are:
d (disabled)
p (PHY activity)
u (unicast activity)
m (multicast activity)
b (broadcast activity)
a (ARP activity)
g (magic packet activity). <---- this being set by the driver, it is needed for WoL to work.
MagicPacket ...
Just the name makes me uneasy.
To disable it I run the command with the 'd' option:
Code:
# ethtool -s eth0 wol d
Code:
[root@devuan groucho]# ethtool -s eth0 wol d
[root@devuan groucho]#
An then check the result ...
Code:
[root@devuan groucho]# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
[root@devuan groucho]#
It did not stick.
I check the log again and there's no trace of my attempt.
The last entry is the same as above:
Code:
groucho@devuan:~$ cat /var/log/pm-powersave.log | grep -i eth0
Setting Wake On Lan for eth0 to enable...Done.
groucho@devuan:~$
You could use /etc/rc.local or some system boot scripts, but this wouldn't be the best way to do it. On startup your network interfaces are configured, sure, but there are other times when your network interfaces may be brought up or down and you will need this executed during those times.
You want to edit /etc/network/interfaces:
You should have a line like:
iface eth0 inet static
Underneath that, indented further, you want to create a post-up and post-down commands e.g.
iface eth0 inet static
post-up /usr/sbin/ethtool -s eth0 wol g
post-down /usr/sbin/ethtool -s eth0 wol g
Obviously, replace eth0 with the relevant interface if different.
See interfaces(5) for more information on post-up and post-down commands
I go look at /etc/network/interfaces:
Code:
groucho@devuan:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback
groucho@devuan:~$
But it is different and there's no mention of eth0.
So what to do now?
Where is the script that enables WoL, as reported by pm-powersave.log?
If I could set that to disabled it may be the solution to all this.
No time stamps but from the look of it, it's once at every boot.
There's a script somewhere that enables WoL but where?
Wake on Lan, & Wake on Keyboard can be disabled in the BIOS, and should be if they're causing issues. It's only the Bios can wake on keyboard or lan, and then simply to boot.
Once acpid is running, The scripts for events should be in /etc/acpi; there's 'events', & 'scripts' which should be two subdirs. It's a "kneebone connected to the thigh bone connected . . " type of thing. Bios events point at scripts which do stuff.
groucho@devuan:~$ cat /usr/lib/pm-utils/power.d/disable_wol
#!/bin/sh
. "${PM_FUNCTIONS}"
command_exists ethtool || exit $NA
set_wol_status() {
for d in "/sys/class/net/"*; do
[ -e "$d/wireless" ] && continue
[ -h "$d/device/driver" ] || continue
printf "Setting Wake On Lan for %s to %s..." "${d##*/}" "$1"
case $1 in
disable) ethtool -s "${d##*/}" wol d>/dev/null 2>&1;;
enable) ethtool -s "${d##*/}" wol g>/dev/null 2>&1;;
esac
[ "$?" -eq 0 ] && echo Done. || echo Failed.
done
}
case $1 in
true) set_wol_status disable;;
false) set_wol_status enable;;
*) exit $NA;;
esac
exit 0
groucho@devuan:~$
I'm not well versed in bash but I think that this script can either enable or disable Wol and it will do it according to the setting of a flag somewhere ie: true) set_wol_status disable or false) set_wol_status enable.
That flag (wherever it is located) is now set to 'false'.
One thing I could do is simply make the script non-executable and see what happens but for linux/bash literacy's sake, I'd really like to find out just what makes this script tick. ie: where the damn 'false' flag is located.
I cannot make heads or tails of this disable_wol script and I have not found anything I could see had 'true' or 'false' in /sys/class/net/.
For whatever reason, now I can (don't have a clue as to why it did not work before) set the e1000e WoL to disabled, but it does not survive a reboot:
A reboot gives it a software reset. I don't know your machine, but I'm surprised there's no way to disable wake on lan. How do others with your M/B handle this? It definitely seems to be arguing a M/B & Bios argument, and you're stuck in the middle. Let's hope you don't end up having to humour it with a tftp server :-/.
A reboot gives it a software reset. I don't know your machine, but I'm surprised there's no way to disable wake on lan.
I'm not: the on-board Gbe controller cannot be disabled, the option is available but shaded out. (!)
I don't now if other workstation type rigs have the same setup, but the Sun Microsystems Ultra24 does.
Like I've mentioned earlier, I think this is tied to the presence IME on the board.
I've shut it down but (as I've read in a few places) it does not and that would be coherent with not being able to disable WoL on this board.
Quote:
Originally Posted by business_kid
How do others with your M/B handle this?
No idea ...
But I've found a solution, actually a temporary workaround.
Searching around, I came across this very informative page:
"Hardware
--- snip ---
Recent motherboards with onboard NICs support Wake On LAN without the need for any pins/cables."
"Firmware / BIOS
In a nice BIOS under power management you will have a clear, intuitive option labeled "Wake On LAN". Unfortunately my system wasn't so clear and has a couple options available."
See, you have to have a nice BIOS.
Not my case or the OP's.
The fellow/s who wrote this up document an issue with how PM-Utils works:
"PM-Utils Conflicts
The pm-utils package contains scripts that are run on suspend, hibernate and on resume of the system. There is one script, /usr/lib/pmutils/power.d/disable_wol, which sets the configuration for interfaces to only wake on "Magic Packet" (g), regardless of the settings you may have configured in /etc/network/interfaces (or one of the files under /etc/network/interfaces.d, or manually using ethtool or in some other way). Look for lines in the file similar to the following:
disable) ethtool -s "${d##*/}" wol d>/dev/null 2>&1;;
enable) ethtool -s "${d##*/}" wol g>/dev/null 2>&1;;
Obviously, if you have set an interface to Wake on LAN in the event of a unicast packet or "Magic Packet" (ug), then suspend using pm-suspend, for example, this script will set the interface to "Magic Packet" only (g) as part of the suspension process.
---
Note:
As you can surely gather, this guy does not know how to make the disable_wol script run with a 'true' flag.
ie: for different reasons, has the same problem I do.
---
You can detect the problem, once you know what you're looking for, by noticing through ethtool after a resume that the "Wake-on" settings for interfaces have been set to "g".
A simple fix (that will not interfere with package updates) is to add a file with the same name, disable_wol to the local configuration directory, /etc/pm/power.d/. This overrides the script in /usr/lib/pm-utils/power.d/disable_wol."
From this write-up I learned two things:
1. PM-Utils runs the /usr/lib/pmutils/power.d/disable_wol script on suspend/resume/hibernate, everytime.
2. As it is run everytime, it overrides any setting you've put in place previously.
I did not have PM-Utils installed in my default Devuan setup and installed it to investigate the shutdown problem as I did not have an interface to check the settings.
What I did was copy the /usr/lib/pmutils/power.d/disable_wol script to the local configuration directory, /etc/pm/power.d/ and modified it so that when it is run it will disable WoL whether the flag (wherever it is) is set to 'true' or 'false'.
Code:
disable) ethtool -s "${d##*/}" wol d>/dev/null 2>&1;;
enable) ethtool -s "${d##*/}" wol d>/dev/null 2>&1;;
This works prefectly well for the time being and will survive any update of PM-Utils.
I could uninstall PM-Utils but the motheorboard bug/WoL combination that caused the reboot on shutdown issue that prompted this thread was already there before I installed it so it is evident that WoL was being set without PM-Utils intervention.
I still don't know where the 'true'/'false' setting is.
ie: what is telling the disable_wol that the flag is 'false'.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.