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.
I doubt if much of the linux stuff matters. There's no kernel loaded. It's the apparently dodgy BIOS and whatever 'start-up state' eth0 is programmed into before shutdown that will affect the start-up state.
I doubt if much of the linux stuff matters. There's no kernel loaded. It's the apparently dodgy BIOS and whatever 'start-up state' eth0 is programmed into before shutdown that will affect the start-up state.
OK.
But PM-Utils reads the disable_wol script and acts according to a flag. ie: 'true' / 'false'.
Code:
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:~$
And the script seems to get some sort of data/setting from whatever is in /sys/class/net/?
I don't know how to interpret the script ie: step by step.
If you run that script in shutdown with the word 'true' after it, that should disable WOL. 'false' would enable it. I thought only us Irish were into double negatives "Don't tell me you're not going to (such and such)."
After I did a complete uninstall, WoL went to 'on' again, as expected.
I still have to find out how it is that it is on and not off by default.
But for the time being I added a line to /etc/rc.local
Code:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
#
# Disable WoL - 20181212
/sbin/ethtool -s eth0 wol d
exit 0
Now athtool reports it as being off after booting ie: set to to d.
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: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
[root@devuan groucho]#
I tested it by disconnecting and reconnecting the eth0 interface while logged in to see if it survived a disconnect and it did.
Nevertheless, it may be better (?) to have a script somewhere that set it to 'd' on 'ifup' and 'ifdown'
Now I have to continue with the shutdown issue, so this is not closed.
I'll see if it comes up again now, with all the PM-Utils stuff removed.
But it may be more useful to start a new thread with a reference to this one to continue as it went on for a good while being just about WoL.
Next obvious question is - what kernel are you on? Distro kernel or your own compile?With pm-utils gone, do you still have the shutdown program?? What's the response to
[root@devuan groucho]# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[root@devuan groucho]#
Code:
[root@devuan groucho]#
[root@devuan groucho]# apt-get check
Reading package lists... Done
Building dependency tree
Reading state information... Done
[root@devuan groucho]#
It's the plain vainilla out of the box kernel version, up to date.
I'm afraid compiling a custom kernel is out of my league.
Quote:
Originally Posted by business_kid
With pm-utils gone, do you still have the shutdown program?
No, but that may be just for the time being.
Like I mentioned earlier on in the thread:
Quote:
Originally Posted by Altoid
This happens ocasionally and I have not been able to reliably reproduce the behaviour, no idea what causes it.
Quote:
Originally Posted by business_kid
What's the response to
Code:
shutdown -h now
It shuts down gracefully.
But like I said, for the time being.
eg: I've seen it not happen for days and then out of nowhere happen again.
And I've also seen it happen two or three times on the same day.
No idea why, was not able to detect a pattern.
The bug that affects some motherboards (link in another post) that use WoL obviously also affecs mine and I suspect (?) that it could be because PM-Utils (or something else?) at some point and in spite of my setting it to 'off', re-enabled WoL momentaily.
Can't think of any other reason now.
Unless the problem crops up again without PM-Utils installed and running.
The only way to find out is to see if it happens again in the course of the next few days.
As I don't have the habit of leaving my rig on when I'm not working/using it, I shut down/start a few times a day so if the issue is still present, it's just a question of time till it shows up again.
What's a speaker of the Erse doing in the Southern Hemisphere? Do they sell Guinness down there?
Anyhow, while you're exhaustively checking this, 2 things. There's a kernel setting for a custom dsdt file. That's normally in the bios and controls this sort of thing. I went very near to messing with it for a different laptop 10 years back, but didn't have to in the end.
The other thing I would do is an extensive google for your box or m/b and acpi problems. Try adding LQ or linux-laptop.net as search terms
I'm afraid my Irish goes no further.
But I do have a distinct preference for green eyed red-headed ladies. =-)
Quote:
Originally Posted by business_kid
What's a speaker of the Erse doing in the Southern Hemisphere?
Born here but lived in Jamaica, USA and Barbados for a good while.
Quote:
Originally Posted by business_kid
Do they sell Guinness down there?
Yes, I believe you can get it at some stores. ($$$!)
But whiskey is really my preferred spirit.
Quote:
Originally Posted by business_kid
... kernel setting for a custom dsdt file.
Indeed ...
I've already gone through that sometime ago.
Actually managed to hack a working DSDT file with no errors/warnings.
But never found a way to be able load it at boot time (!), highly frustrating.
By the time I found out about it, some switch had been turned off at the base kernel resulting in no longer being possible to load a custom DSDT at boot time or even compile that option in the kernel.
From what I recall reading on the web, the idea behind that smart decision was that the kernel had to be able to solve buggy BIOS issues at boot time.
And yes, I'm still waiting for the kernel to get around my buggy Sun Microsystems BIOS.
Whoever made that particular call (a real dickhead IMO) forgot to think about all the buggy BIOS issues that will not ever be addressed for various reasons eg: hardware too old or not enough affected rigs, amongst a good number of other reasons that maintainers give for not wanting to invest time to fix code with problems.
I asked and asked (and asked) but was not able to get a straightforward answer from anyone wrt that, so I finally gave up on a custom DSDT.
Quote:
Originally Posted by business_kid
... an extensive google for your box or m/b and acpi problems.
Been there, done that ...
The Ultra24 (released in 2007) was a rather unique offering from Sun in that it was it's return to x86 in the form of a high-end workstation, offering both Intel and AMD based rigs. Oracle then gobbled up Sun Microsystems in 2009, dropped anything x86 related and sequestered ($$$) all available BIOS updates and basic tech support ($$$).
By that time only a comparatively small amount of U24s had been sold and this lack of commercial sense on behalf of Oracle prompted a great many users (who had paid top money for their ws) to get rid of a really fine piece of hardware, so there's a general lack of information on the web.
The most complained about problem with the U24 is probably its crap BIOS.
Quote:
Originally Posted by business_kid
... is devuan any use?
For what it is worth, I can tell you this: I have over 24 years of PC use on my back, essentially from DOS 5.0 up to XPSP3 and 5+ years of desktop support at work. One day I finally got fed up with MS.
I had already toyed with some early Debians on recovered laptops but never really managed to get a fully working rig on line. After that, I started with early Ubuntus and went through Mint, CrunchBang, PCLinux to finally settle with Devuan.
I think it is as good as it gets.
The fact that it is systemd free (an MS Windows system registry in disguise) is what decided me to stay with it.
But (as always) it's just my 0.02 so YMMV.
As Google translate will tell you, it means 'How Are You?' Really, Irish is dead. People are being paid to speak it, and certain people e.g. Police, and solicitors, indeed Government need to be able to do business in Irish.
Barbados & Jamaica, but it's a case of hoping you're away every time a tornado/hurricane/earthquake. I have friends from Martinique, Dominican Republic & Haiti. I worked for years with the guy Phillipe (Tatlot - he's French) mentioned in thisin_this . He comes in around paragraph 3 or 4.
The thing to do with your box seems to be
Grab your kernel config of choice and put it in the top kernel source as .config.
Drop your DSDT in /lib/firmware.
Go to General Setup & change LOCALVERSION, so you can tell it's yours.
In Power Management & ACPI, set the DSDT file location (/lib/somewhere/my-dodgy-file).
Set Use Custom DSDT=y & make your kernel, & modules.
Boot it and see what blows up, or works.
Buggy BIOS in a SUN box doesn't surprise me. They're not fighting the sort of competition PC manufacturers are. You seem to have done all the right things. /lib/modules/<version>/misc seems like a good place for it, because you could build it into the initrd. So you won't need the path. Google that and find out where it goes.
EDIT: 'Maidin mhaith' is literally 'Morning good' but it's not a recognised Irish greeting. I gave you about the only one that doesn't involve prayers or invocations to the dead, non-existent, or misrepresented. Fairies are alive and well in Gaelic tradition and the crossover between pagan, superstition and Christian tolerated here for so long is alarming.
Last edited by business_kid; 12-14-2018 at 02:20 PM.
... a case of hoping you're away every time a tornado/hurricane ...
Bbdos is far enough to the east (the farthest) to be quite safe.
Jca on the other hand most always gets a very rough time.
In the early 1690's, an earthquake sunk Port Royal into the sea.
I think in 190X there was another one with great damage.
Quote:
Originally Posted by business_kid
The thing to do with your box ...
Yes, I have to roll my own kernel using a DIY trouble free DSDT.
I was willing to go as far as loading a custom one from the kernel line which was easy enough once I achieved a problem free one, but to roll my own kernel was not what I had in mind.
But many thanks for the tips, I'll think about it.
Quote:
Originally Posted by business_kid
Buggy BIOS in a SUN box ...
A strange combination ie: good company/great hardware/crap BIOS.
To the extent of being commercially negligent.
Incredible. =-/
Quote:
Originally Posted by business_kid
You seem to have done all the right things.
I think so.
If this WoL/BIOS thing (hopefully) does not crop up again I think I'll be able to manage.
Quote:
Originally Posted by business_kid
'Maidin mhaith' is literally 'Morning good' but it's not a recognised Irish greeting.
I see.
Like the very popular Top o'the mornin' to you which has never been said by any Irishman. =-)
Quote:
Originally Posted by business_kid
... only one that doesn't involve prayers or invocations to the dead, non-existent, or misrepresented.
Gqroan!
I will go this far with you. I believe that EXTRATERRESTRIALS exist. I mean the Spirit world. The Bible names some, and numbers more but this is dangerously OT
Much to my chagrin, the problem that gave origin to this thread has cropped up again.
To recap:
Quote:
Originally Posted by OP
Description of the problem:
On shutdown, the rig will do one of three things:
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 is happening even after getting rid of all PM-Utils files and finally being able to get WoL disabled at boot, something which was a problem with PM-Utils installed.
Seeing that this involved the e1000e: EEE Tx LPI Timer, I searched and found this:
I've news for you friend . . .
S5 = Hibernate, if I'm not very much mistaken. That's ok, but I wonder where "off" went? What happens if you, as root, enter this on a terminal/console
Code:
shutdown -h now
FYI, I took a look in Slackware's pm-utils, and the script /usr/lib64/pm-utils/power.d/disable_wol struck me as interesting. Here it is
Code:
#!/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
I'd look up that ethtool command man page but I gather you feed it 'disable' or 'enable' and it does the business with ethtool. I really like this about slackware; it isn't a big deal to see what's in each package. See what hackery you can manage with these nuggets.
But as I don't usually shutdown in that manner ie: via a terminal, I don't have enough data to say the problem also happens if I do so. I expect it would eventually show the same behaviour like when I do it from the desktop, no reason it would not do so as it is just a desktop shortcut to the command.
Quote:
Originally Posted by business_kid
... Slackware's pm-utils, and the script /usr/lib64/pm-utils/power.d/disable_wol ...
It's exactly the same script that I found in /usr/lib/pm-utils/power.d/disable_wol.
See post #13
So I tried seeing what the EEE setting was for my on-board NIC using ethtool:
Code:
[root@devuan groucho]# ethtool --show-eee eth0
Cannot get EEE settings: Operation not supported
[root@devuan groucho]#
Just to try and see, I attempted to turn EEE off:
Code:
[root@devuan groucho]# ethtool --set-eee eth0 eee off
Cannot get EEE settings: Operation not supported
[root@devuan groucho]#
From the last link it seems that the EEE settings can be modified with the Windows driver but not with the Linux driver, at least not using ethtool.
The path I see to attempting a solution is getting the latest version of the driver installed in Devuan and if it does not work with the installed version of ethtool, then getting the latest version to see if it does.
ethtool is the standard Linux utility for controlling network drivers and hardware, particularly for wired Ethernet devices. It can be used to:
Get identification and diagnostic information
Get extended device statistics
Control speed, duplex, autonegotiation and flow control for Ethernet devices
Control checksum offload and other hardware offload features
Control DMA ring sizes and interrupt moderation
Control receive queue selection for multiqueue devices
Upgrade firmware in flash memory
Most features are dependent on support in the specific driver. See the manual page for full information.
Having the latest available driver for the on-board 82566DM Gbe may do the trick.
How can I get it installed in Devuan?
---
For Intel® 82566DM Gigabit Ethernet PHY
Intel® Network Adapter Driver for PCIe* Intel® Gigabit Ethernet Network Connections Under Linux*
Version: 3.4.2.1 (Latest) Date: 8/26/2018
---
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
