No idea how that works.
Quite happy to actually have been able to compile the driver.

For some reason I expected to see a .config file similar to what I have seen is used to compile a kernel.
So I'd check the boxes of the functions I wanted to compile in the driver.
But none of that came up.

And have no idea where to look or how to do it.

Well ...
That is precisely what I am attempting to find out by disabling EEE.
Something that (for unknown reasons) seems to be impossible.

If you had read Part II (post #2) ...  8^D

I ran my rig for more than a week without a bad shutdown using the shutdown script described.
With EEE (supposedly disabled) and a standard shutdown -h now I immediately got a bad shutdown.

Could be a coincidence?
Maybe.

But I also got a line which would seem to be evidence of the EEE TX LPI Timer being active at shutdown, before the system went to S5 and powered down.     
This in spite of EEE being disabled albeit with nothing in dmesg indicating that it was or it was not, like with Smart Power Down Disabled.

eg: e1000e: EEE Disabled or e1000e: unknown parameter 'eee' ignored.

I may be wrong.
But up to 'now' everything points to the EEE function in the NIC.

Would it be OK if we continue with this in PII?
That's where the driver module compilation (if it comes to that) would be discussed.

Thanks a lot for your input.

Best,

A.

No problem ...
But I'll have to continue with the rest on Part II.
You'll see why.

Hmm ...
Thanks for the suggestion but I'll pass on that one.
I'm not confortable with having to do all that just to be able to disable this EEE crap.  8^7

Yes, I saw those links but didn't understand what was going on.

I had not done it before so I was rather apprehensive but I managed to follow the instructions and compiled the latest e1000e driver module.

Please bear with me and see the results of my efforts in PII.  8^)
Thanks a lot for your input.

Best,

A.

Looking at [0], there is just one e1000e device/phy/whatever type of many supporting ethtool EEE queries. Bad luck for you. Looking at [1], I guess you need to compile your favorite kernel version and comment out one line, to see if that helps. The call to e1000e_igp3_phy_powerdown_workaround_ich8lan in drivers/net/ethernet/intel/e1000e/ich8lan.c. Maybe your hardware hangs there, who knows. Maybe is no good on your hardware? Trial and error....

[0] https://github.com/torvalds/linux/searc … G2_HAS_EEE
[1] https://github.com/torvalds/linux/searc … nd_ich8lan

The plot thickens ...

Since I set up the igb.EEE=0 stanza in the kernel command line, things had been coming along well enough.

But this morning I had another, albeit different, bad shutdown.
It had not reared its head for the longest while, probably because it was obscured by the other one.

This one reboots the box on shutdown with the fans on.
Not as bad but still quite annoying.

I then realised that I had not edited my shutdown script to its previous version.
ie: the one disabling WoL before shutting down and had left it at the version that removed the e1000e module before shutting down.

ie:

This one ...

#!/bin/sh
# added to troubleshoot nic related bad shutdown 
PATH=/sbin:/bin:/usr/sbin:/usr/bin:

# sync
# remove e1000e module
# shutdown system directly (no shutdownhelper) 
sync && sudo rmmod -s -v e1000e && sudo shutdown -h now

instead of this other one ...

#!/bin/sh
# added to troubleshoot nic related bad shutdown 
PATH=/sbin:/bin:/usr/sbin:/usr/bin:

# sync
# disable onboard eth wol
# shutdown system directly (no shutdownhelper) 
sync && sudo ethtool -s eth0 wol d && sudo shutdown -h now

Made me think that it was the reason for the tty1 output being different.
ie: no e1000e: eth0 NIC Link is Down or e1000e: EEE TX LPI TIMER: 00000000 in the output.

And that maybe the igb.EEE=0 bit was not really working. 8^7

Once things were as I thought they should be, I rebooted and shutdown while getting a video and got the bad news:

The e1000e: eth0 NIC Link is Down and e1000e: EEE TX LPI TIMER: 00000000 lines now show in the output again.
So, the added stanza does not really work.

So I decided to make my shutdown script work a bit more and edited it to this version:

#!/bin/sh
# added to troubleshoot nic related bad shutdown 
PATH=/sbin:/bin:/usr/sbin:/usr/bin:

# sync
# disable onboard eth wol
# remove e1000e module
# shutdown system directly (no shutdownhelper) 
sync && sudo ethtool -s eth0 wol d && sudo rmmod -s -v e1000e && sudo shutdown -h now

A shutdown, reboot and video grab later got me this*:
* times edited for simplicity's sake

Devuan GNU/Linux 3 devuan tty1
devuan login: [        ] EXT4-fs (sda1): re-mounted. Opts: (null)
[        ] kvm: exiting hardware virtualization
[        ] sd 8:0:3:0: [sdg] Syncronizing SCSI cache
[        ] sd 8:0:2:0: [sdf] Syncronizing SCSI cache
[        ] sd 5:0:0:0: [sdb] Syncronizing SCSI cache
[        ] sd 5:0:0:0: [sdb] Stopping disk
[        ] sd 4:0:0:0: [sda] Syncronizing SCSI cache
[        ] sd 4:0:0:0: [sda] Stopping disk
[        ] ACPI: Preparing to enter sleep state S5
[        ] reboot: Power down

Looking back, it makes sense as the NIC driver in use is not the igb driver but the e1000e one.
I'll have to try and see what using the e1000e.EEE=0 stanza gets me.

Edit:

groucho@devuan:~$ sudo dmesg | grep e1000e
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-16-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro acpi_osi=Linux e1000e.eee=0 agp=off apparmor=0 ipv6.disable=1 enable_mtrr_cleanup nmi_watchdog=0
--- snip ---
[    2.158949] e1000e: unknown parameter 'eee' ignored
--- snip ---
groucho@devuan:~$

Very sorry for the screw up. 8^7

Best,

A.

Would not be at all surprised.
But I don't think the POS router my telco provides has any EEE capability, so the problem is probably (in part) there.

That could be a solution, if I had any need for EEE, which I don't.
Like I said, I think it is more a hindrance/problem for anything but a portable/non-mains device.
And then, after careful consideration of the pros/cons.

Just how much does a NIC in a portable device use?
How much energy is actually saved by adding this layer of complexity to an already very complex device? 

From what I understand, EEE needs both devices (controller and router/switch/other controller) to autonegotiate what/how/when/whatever.
Otherwise it does not work.

More of a problem is (I think) that the Intel's e1000e driver blocks all access to EEE, both for querying status and changing settings.
And that Intel Support makes no mention of it whatsoever and throws Sun under the bus.

Thanks for your input.

Best,

A.

e1000e EEE driver part seems to need to "see" some link layer state and with old cables somehow gets it wrong and enters some bogus state, so that it cannot shutdown properly in your case?! That would be crazy, but I have seen all kind of things already. Always worth to try.

But yeah, its kind of energy savings feature, which is not always necessary.

I got a reply from him this afternoon.

I had asked:

Here's a transcription of the relevant part of his reply:

As clear as Perrier ...

So it's quite definitely the e1000e driver that is blocking access to both the status and configuration of the EEE settings in the 82566DM-2 GbE controller.
No doubt about that because I have been able to disable it completely via the igb.EEE=0 bit added to the kernel command line.

What is really irritating is that Intel Ethernet Products support insisted from the start that the only way to get it done was either through ethtool or modprobe, something which I repetedly reported as being non-working solutions:

This is the last I heard from them back in 01/2019:

Draw your own conclusions.

Best,

A.

... above-mentioned link says something different AFAIUI.

I'll have another look.

Maybe I missed something.
Thanks for the heads up.

From what I have seen, the e1000e driver has always been very problematic, its link to the Intel ME and how it works probably having much to do with that being so.
ie: up to now, an Intel network controller has been essential for IME to work.

The fact that I cannot disable my GbE controller (WTF?) or access all of its settings in Linux via the tool used to that effect (ethtool) speaks volumes.
I have not yet heard from ethtool's maintainer with respect to that.

Problems with this driver are known to exist as far back as 2012 (!) and it seems that, almost 10 years later, things have not changed much.
From where I sit, I don't see any need for the EEE feature in a desktop, workstation or server.
To me it is just another layer of complication, so I want it turned off.

I posted the solution I found to the Intel e1000e support forum.
But haven't heard from them yet and it's quite possible I won't.

In my view, this EEE thing it is only useful (and only to a limited extent) in a portable, battery operated device or one in which the network component tends to run hot.
eg: some SoCs

And the same goes for any other energy saving features they come up with.

If disabling the controller's EEE does effectively do away with the bad shutdown problem I have, that will be it for the time being.
I'll upgrade my kernels conservatively, as I have always done.
Which is why I ultimately chose Debian as my distribution.
And when the developers/maintainers turned into DebHoles, moved to Devuan.

Hope is in very short supply in this day and age.
I'd rather use the little there is for other, more important things.  8^D!

Thanks a lot for you input, your post steered me in the right direction.

Best,

A.

But the last information you would get would be the tty1 output, ...

I wonder, the above-mentioned link says something different AFAIUI. But it seems to be the best to use the latest kernel with its newest e1000e driver and hope for the best.

I suppose it would.

But the last information you would get would be the tty1 output, up to where the screen reads reboot: Power down but doesn't power down and stays there.
Like you pointed out, waiting for a signal that it will never receive.

There's nothing more after that because at that stage, the OS is in a frozen and totally unresponsive state.
The only way out of that is a hard shutdown.

Thanks for your input.

Best,

A.

See: https://kernelnewbies.org/Linux_Kernel_ … e_Chapter3

Yes, that would be /var/log/kern.log.

But at that stage, (preparing to enter S5), all system files are read only.
ie: all drives have been synced and stopped, the last one being the one with the /boot partition.

I have never found any useful data with respect to this bad shutdown problem in the log files.
It happens when no one is looking and save for the useless and volatile tty1 printout, leaves no trace behind. 8^7

According to /var/log/auth.log, I added the igb.EEE=0 instruction to the kernel command line @08:27.
I then shutdown and got another bad shutdown instance.

But the kernel line addition was not active yet, so that bad shutdown only means that everything done to that point had had no effect.
Nothing new ...

These are the kernel log entries from that time forward, the last one at shutdown and the first one at boot:

groucho@devuan:/var/log$ tail -6000 kern.log
--- snip ---
Apr 19 08:29:27 devuan kernel: [ 3556.858961] e1000e: eth0 NIC Link is Down                                           <--- | fix not active |
Apr 19 08:31:30 devuan kernel: [    0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28 <--- | fix active |
--- snip ---
Apr 19 08:45:16 devuan kernel: [  858.318960] e1000e: eth0 NIC Link is Down
Apr 19 08:47:43 devuan kernel: [    0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
--- snip ---
Apr 19 08:48:06 devuan kernel: [   58.328174] e1000e: eth0 NIC Link is Down
Apr 19 08:50:08 devuan kernel: [    0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
--- snip ---
Apr 19 11:42:27 devuan kernel: [10373.487079] e1000e: eth0 NIC Link is Down
Apr 19 12:51:32 devuan kernel: [    0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
--- snip ---
Apr 19 16:08:27 devuan kernel: [ 2166.724262] e1000e: eth0 NIC Link is Down
Apr 19 16:10:32 devuan kernel: [    0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
--- snip ---
groucho@devuan:/var/log$

Nothing in the log after the NIC is down.
The fact that the tty1 print out has no entries indicating the status of the NIC link or EEE (always present before) would seem to imply that we may be on the right track.

Now I just have to wait 15 days and see if stanza added to the kernel command line actually fixed the problem.
A 'bad shutdown' quarantine if you'll willing to pardon the pun.

Thanks a lot for your input.

Best,

A.

I have found a way to disable this Energy-Efficient Ethernet thing in my Intel e1000e on-board controller.

Where the ethool utility has no access, the kernel does: adding igb.EEE=0 to the kernel cmdline disables EEE during boot.

https://www.toradex.com/community/quest … ernet.html

This EEE issue seems to be something that has been around for a long time:
https://thatbytes.co.uk/posts/fun-with- … ontroller/   <---  05/2012!

EDIT:
Doing all this again helped me remember that at one time (back in 2019) I tried solving this problem by adding the stanza e1000e.EEE=0 to the kernel command line.
It did not work: the e1000e: EEE TX LPI TIMER: 00000000 bit was also present in the tty1 output in case of a normal shutdown and the bad shutdowns kept happening.

See https://www.linuxquestions.org/question … ost5954899

Maybe my ISP provided cheapo router does not (most probably) support EEE.
But I was already having this problem when I was on a shared WiFi connection.

But not everything is good news.
After setting this parameter and rebooting to see the results, I got a bad shudown, albeit without the presence of the e1000e: EEE TX LPI TIMER: 00000000 bit:

Devuan GNU/Linux 3 devuan tty1
devuan login: [   864.785061] EXT4-fs (sda1): re-mounted. Opts: (null)
[   864.824466] kvm: exiting hardware virtualization
[   864.910856] sd 7:0:3:0: [sde] Syncronizing SCSI cache
[   864.911235] sd 7:0:2:0: [sdd] Syncronizing SCSI cache
[   864.911634] sd 5:0:0:0: [sda] Syncronizing SCSI cache
[   864.913092] sd 5:0:0:0: [sda] Stopping disk
[   865.013903] ACPI: Preparing to enter sleep state S5
[   865.014444] reboot: Power down

Note that there are no lines referring to the status of the NIC link or EEE:
ie:
e1000e: eth0 NIC Link is Down or e1000e: EEE TX LPI TIMER: 00000000.

Maybe (?) the bad shutdown was a consequence of having disabled EEE on the controller.
Won't know till at least 15 days go by without another bad shutdown.

Meanwhile, I'll enjoy my having found this tidbit of information.

[rant]
Information I asked for but the DHs at Intel e1000e support were unable to give me.
I'll assume that they did not know what I was talking about.
[/rant]

Best,

A.