Shutdown problem - e1000 driver bug?

business_kid · 12-18-2018, 08:54 AM

Quote:

> ... wonder where "off" went?
That seems to be part of the problem at hand.

My no #1 guess - permissions. Your desktop has luser permissions, you need suid or root somewhere in the chain.

Personally, I put little faith in latest drivers. Go after the usual suspects - ACPI & BIOS.

ACPI links events to scripts. If you start acpid with a '-l' option, it logs events to syslog. then run 'tail -f' on syslog and try your shutdown stuff. Your shutdown sequence is probably linked to a wrong or under permissioned script. Slackware's acpi is primitive beyond belief, but some distros are very involved. You may need to get another acpi script collection. From my previous ACPI issues with a certain deceased HP laptop, Debian & Fedora have extensive collections, but you have to weed them vigorously.

I'm amazed that your BIOS won't disable wake on lan, like even mine does.

Altoid · 12-21-2018, 08:08 AM

Hello:

Quote:

Originally Posted by business_kid

My no #1 guess - permissions ...

If this problem were of a permanent nature ie: if it happened at every shutdown, I would totally agree with you.

But because I can either have permission to do X or not have permission to do X ie: shutdown the workstation, it seems (to me) highly unlikely that this is a premissions issue.

As I have related previously, this is an issue that crops up in a random manner without my being able to reproduce it, no matter what.
Of course, I'm quite sure that there is a way to reproduce it, I just have not been able to find it.

But all is not lost:
What I can say is that one of the symptoms ie: the random reboots after shutdown I mentioned in my OP has not cropped up again, probably due to having been able to disable WoL.

Quote:

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 ...

The issue that remains unsolved is #3, the one that seems to be linked to the e1000e EEE Tx Timer.

Quote:

Originally Posted by business_kid

... put little faith in latest drivers.

You may be right in that.

Just in case, I decided to go through the updating of the driver.
I downloaded the latest available version from Intel:

https://downloadcenter.intel.com/dow...3.4.2.1.tar.gz

To my surprise (!) and even though the readme file indicated that the previous module had to be removed before loading the new one, on [c]# make install[/c], the script installed the module correctly without further intervention from me, which was a relief.

Good going Intel! (for once).

Code:

[root@devuan groucho]# modinfo e1000e
filename:       /lib/modules/4.9.0-8-amd64/updates/drivers/net/ethernet/intel/e1000e/e1000e.ko
version:        3.4.2.1-NAPI
license:        GPL
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
--- snip ---
[root@devuan groucho]#

But even with the latest driver I am not able to disable the e1000e EEE Tx LPI Timer:

Code:

[root@devuan groucho]# ethtool --set-eee eth0 tx-lpi off
Cannot get EEE settings: Operation not supported
[root@devuan groucho]# ethtool --set-eee eth0 eee off
Cannot get EEE settings: Operation not supported
[root@devuan groucho]#

Now, "Operation not supported" cannot mean anything but "ethtool cannot do this" or maybe "the driver cannot do this" as the card clearly supports EEE.

Check the screen output showing that the tx-lpi timer is in action:

Code:

--- copied from uploded screen image ---
Devuan GNU/Linux ascii devuan tty1

devuan login: [483.367459] EXT-fs (sdc1): re-mounted. Opts: (null)
[485.772216] e1000e: eth0 NIC Link is Down
[485.776885] kvm: exiting hardware virtualization
[485.777756] sd 9:0:3:0: [sdf] Synchronizing SCSI cache
[485.778154] sd 9:0:2:0: [sdf] Synchronizing SCSI cache
[485.781519] e1000e: EEE TX LPI TIMER: 00000000
[485.785219] ACPI: Preparing to enter sleep state S5
[485.868007] reboot: Power down
--- copied from uploded screen image ---

From [485.868007] on, the rig freezes with the case/CPU fans blasting loudly at 100% output.
The only way out of this situation is a hard shutdown.

Quote:

Originally Posted by business_kid

Go after the usual suspects - ACPI & BIOS.

The only part of the BIOS that I will not touch again is the Intel ME settings.
Changing anything in there will wreak havoc. Been there , done that and really feared for the hardware. =-/

Quote:

Originally Posted by business_kid

... start acpid with a '-l' option, it logs events to syslog.

Done that:

Code:

groucho@devuan:~$ tail -1000 /var/log/syslog | grep -i logging
Dec 21 09:09:46 devuan acpid: waiting for events: event logging is on
groucho@devuan:~$

But I have found nothing in syslog.
Or auth.log, user.log, messages, daemon.log, kern.log, debug and boot for that matter.

Quote:

Originally Posted by business_kid

I'm amazed that your BIOS won't disable wake on lan ...

Like I mentioned earlier in the thread: I am unable to disable the Gbe controller: it is greyed out on the BIOS screen.

If you think that is strange, how about this: the BIOS reports the rig as 'Hand Held Computer', no matter who you ask:

Code:

[root@devuan groucho]# lshw
devuan                      
    description: Hand Held Computer
    product: Ultra 24 (Null)
    vendor: Sun Microsystems
    version: 0.00.01
    serial: 0123456789
    width: 64 bits
    capabilities: smbios-2.5 dmi-2.5 smp vsyscall32
    configuration: boot=normal chassis=handheld family=Null sku=Null uuid=295894AA-8E10-4A53-9090-00144F4AA281
[root@devuan groucho]#

Code:

[root@devuan groucho]# inxi -M
Machine:   Device: portable System: Sun Microsystems product: Ultra 24 v: 0.00.01 serial: 0123456789
           Mobo: Sun Microsystems model: Ultra 24 v: 50 serial: 3K08QG
           BIOS: American Megatrends v: 1.56 date: 01/21/2011
[root@devuan groucho]#

So imagine the rest ...

[rant]
It's a real pity that the destiny of such excellently designed/built hardware was eventually obscured by the dickheads that wrote the BIOS and then, having received thousands of bug reports/complaints, never fixed them properly. I hope they are all rotting in some cold, dark Oracle dungeon.
[/rant]

I'll give this a rest for a few days: have to cook for monday/tuesday.
Thank you very much for your input.

Have a very Merry Xmas. *<8^D !

Cheers,

A.

business_kid · 12-21-2018, 10:07 AM

Well, I don't often say this, but I'm inclined to give up. I'm up against Sun hardware & BIOS that I have no familiarity with. There's likely diagnostic utilities also. You being limited on permissions and things being greyed out doesn't help.

Is there a sun specific forum for you to try?

Altoid · 12-21-2018, 10:29 AM

Hello:

Quote:

Originally Posted by business_kid

... inclined to give up.

Don't worry ...

Quote:

Originally Posted by business_kid

I'm up against Sun hardware & BIOS ...

Actually the Gbe controller hardware is Intel, but I get your point and you've been a real sport.
Many thanks go out to you. =^)

In the time between ovens and pots, I downloaded and installed the last available version of ethtool:

Code:

[root@devuan groucho]# ethtool --version
ethtool version 4.19
[root@devuan groucho]#

With both ethtool and the Intel e1000e driver updated I still cannot change the EEE settings:

Code:

[root@devuan groucho]# ethtool --show-eee eth0
Cannot get EEE settings: Operation not supported
[root@devuan groucho]#

I've posted about that at the Intel forum to see if I can get some advise there: after all it's their hardware and their driver but I'm not holding my breath.

https://forums.intel.com/s/question/...language=en_US

Quote:

Originally Posted by business_kid

... sun specific forum for you to try?

Not that I know of.

From what I have heard/read, when Oracle gobbled up Sun Microsystems, that was it for any Sun hardware out there in need of basic support or BIOS updates, even when they were to fix pre-existing bugs. ie: If you did not have a (very expensive) service contract you were absolutely on your own.

But some light has shone on this: when I updated the driver it seems (?) that the Tx Timer was reset to 0 and on shutdown the problem cropped up again, so it's yet another indication of the problem's possible origin.

Code:

[485.781519] e1000e: EEE TX LPI TIMER: 00000000   <----

I have some other stuff to fix on my rig, so we'll see each other here again.

In the meantime, Merry Xmas.

Best,

A.

Altoid · 01-16-2019, 05:05 PM

Hello:

The Xmas/NYE break has come and gone and I finally found out how to disable EEE in the e1000e driver, which was the yet unsolved part of the OP, the first part being disabling WoL.

Posting in the Sourceforge forum got me nowhere:
https://sourceforge.net/p/e1000/bugs/635/
Check out the "Also, we don't support Debian" bit while referring to a kernel module for Linux.(!!!)

Doing the same at the Intel Ethernet forum not only turned out to be a total waste of time but also a huge dissapointment which ended up costing me a bet.
https://forums.intel.com/s/question/...language=en_US

I'll try to be brief:

The Intel e1000e driver for Linux is only supported as a loadable module.

See here: https://www.intel.com/content/www/us...-products.html

Quote:

The drivers are only supported as a loadable module. We don't supply patches against the kernel source to allow for static linking of the drivers.

From what I gathered from an email by the maintainer of the ethtool utility [a *big* thank you here], this means that many (if not all) driver options such as EEE settings or SmartPowerDownEnable cannot be accessed or set using the ethtool utility. (corrections welcome)

So the way to set the driver module options is either through /etc/modprobe.d (with a *.conf file) or in /sys/module/e1000e/parameters/, for which (apparently) some unload/reload module magic must be done.

Here's a couple of links to read up on how to do that:

http://baruch.siach.name/blog/posts/...le_parameters/
https://access.redhat.com/documentat...ule_parameters
https://www.kernel.org/doc/html/v4.1...arameters.html

A *.conf in /etc/modprobe.d file did not work (no idea why, maybe label or syntax?) and I was really wary of loading/unloading the module lest I royally screw up my eth0 configuration (never done it before) so I went with the kernel command line way by adding this stanza to mine:

Code:

e1000e.EEE=0

Apparently it works as I have no dmesg, kern.log or syslog entries with a fail or warnings.
But, as I am unable to get the EEE status through ethtool I really cannot categorically say if this is so, I'll just have to wait and see if it happens again.

Code:

[root@devuan]# ethtool --show-eee eth0
Cannot get EEE settings: Operation not supported
[root@devuan]#

rant
I would have thought that all of this I looked for and found elsewhere would be information/data that the people running support at Intel Ethernet or Sourceforge knew about and had properly documented: after all, it's Intel hardware and Intel drivers written by them. But all I got was assorted BS.
A very sad and unfortunate state of affairs.
/rant

Hope this information is useful to those who come across the same issues.

Cheers.

A.

Altoid · 01-29-2019, 05:39 AM

Hello:

An update to my last post.

Quote:

Originally Posted by Altoid

Code:

e1000e.EEE=0

Apparently it works as I have no dmesg, kern.log or syslog entries with a fail or warnings.
But, as I am unable to get the EEE status through ethtool I really cannot categorically say if this is so, I'll just have to wait and see if it happens again.

Much to my chagrin and after quite a long run of shutdowns without incident, Part II of the dreaded shutdown issue cropped up again:

Code:

e1000e: EEE Tx LPI Timer
Preparing to enter sleep state S5
Reboot: Power Down

I don't know if it is that the kernel command line solution is not working or if there is 'something' in my system that is changing the EEE setting once booted.

Seeing that this thread has grown long, the issue has been partly solved and that the remaining part of the problem is related to the e1000e driver module's EEE setting (and how to change it), unless the moderators opine differently, I think it will be better to start a new one to address it specifically, with a reference to this one.

Cheers,

A.