Hello:

I'll get the gist of it, eventually.

Yes.
I really don't like that either, rather annoying.
But that's what's there to use.

I managed to get the param.c file patched, a new e1000e.ko (3.8.7p) compiled and working.
I keep forgetting to do update-initramfs -u -k all, it will sink in eventually.

I have noticed that with the previous versions of the module, if I rmmod e1000e and then modprobe e1000e, to connect again I had to do it manually via the applet.
Maybe it took longer and I didn't notice?
Can't say, but with is new patched version (e1000e-3.8.7p) either the link comes up without my intervention or it does so faster.

This is the dmesg when loading the new module version:

groucho@devuan:~$ sudo dmesg | grep e1000e
[    2.130179] e1000e: loading out-of-tree module taints kernel.
[    2.130458] e1000e: module verification failed: signature and/or required key missing - tainting kernel
[    2.187380] e1000e: Intel(R) PRO/1000 Network Driver - 3.8.7-NAPI
[    2.209432] e1000e: Copyright(c) 1999 - 2020 Intel Corporation.
[    2.220453] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    2.242892] e1000e 0000:00:19.0: PHY Smart Power Down Disabled
[    2.254057] e1000e 0000:00:19.0: EEE Support was initialized to be enabled
[    2.276187] e1000e 0000:00:19.0: EEE Support has been reset to be disabled
[    2.727852] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:14:4f:4a:a2:81
[    2.727853] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    2.727874] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 6, PBA No: FFFFFF-0FF
[   26.905148] e1000e 0000:00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[   26.917281] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
groucho@devuan:~$

This the output when I remove and then reload the module:

groucho@devuan:~$ sudo dmesg
--- snip ---
[  127.472489] e1000e 0000:00:19.0 eth0: NIC Link is Down
[  142.796192] e1000e: Intel(R) PRO/1000 Network Driver - 3.8.7-NAPI
[  142.796197] e1000e: Copyright(c) 1999 - 2020 Intel Corporation.
[  142.796432] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[  142.796434] e1000e 0000:00:19.0: PHY Smart Power Down Disabled
[  142.796436] e1000e 0000:00:19.0: EEE Support was initialized to be enabled
[  142.796438] e1000e 0000:00:19.0: EEE Support has been reset to be disabled
[  143.112495] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:14:4f:4a:a2:81
[  143.112499] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[  143.112525] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 6, PBA No: FFFFFF-0FF
groucho@devuan:~$

The eth0 link seems to be working correctly and a speedtest shows no apparent difference in upload/download rates.

Now for the bad news:
The screen grab video of the tty1 printout at shutdown -h now is still showing the same sequence with the line EEE TX LPI TIMER: 00000000.     

To me, the tell tale sign pointing to the module is that this does not happen when using my shutdown script:
ie: removing it prior to shutdown.

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

It would seem that any doubts about the 82566DM-2 controller supporting EEE have been cleared:
re: /* Currently only supported on 82579 and newer */

But if this controller does not have EEE capabilty, where is this EEE TX LPI TIMER: 00000000 coming from?
And most importantly: why?
Some left over half-cooked code?

Edit 1
EEE support requires auto-negotiation with the device the NIC is connected to.
Could it be that there is some code in there that is attempting to do just that?

Up to now, by removing the module I have not had another bad shutdown (knock wood).
But it is too early to know if it holds it's only been a week.

Edit 2
Looking at the files in /e1000e-3.8.7p/src I came across this in ethtool.c:

groucho@devuan:/usr/src/e1000e-3.8.7p/src$ cat ethtool.c | grep -i "timer"
	mod_timer(&adapter->blink_timer, jiffies + E1000_ID_INTERVAL);
		if (!adapter->blink_timer.function) {
			init_timer(&adapter->blink_timer);
			adapter->blink_timer.function =
			adapter->blink_timer.data = (unsigned long)adapter;
		mod_timer(&adapter->blink_timer, jiffies);
		del_timer_sync(&adapter->blink_timer);
	edata->tx_lpi_timer = er32(LPIC) >> E1000_LPIC_LPIET_SHIFT;   <----- | x | 
	if (eee_curr.tx_lpi_timer != edata->tx_lpi_timer) {           <----- | x |
		e_err("Setting EEE Tx LPI timer is not supported\n"); < ---- | x |
groucho@devuan:/usr/src/e1000e-3.8.7p/src$ 

Thought it may have some relevance.

Thank you very much for your help and patience.

Best,

A.

Hello:

Thanks. 8^)

Hello:

Can't seem to get this right.

Code location:

groucho@devuan:~$ ls /usr/src/e1000e-3.8.7/src
80003es2lan.c  82571.o           defines.h     e1000e.o   ich8lan.h  kcompat_ethtool.c   manage.c       netdev.o  param.o  ptp.o
80003es2lan.h  Makefile          e1000.h       ethtool.c  ich8lan.o  kcompat_overflow.h  manage.h       nvm.c     phy.c    regs.h
80003es2lan.o  Module.supported  e1000e.ko     ethtool.o  kcompat.c  mac.c               manage.o       nvm.h     phy.h
82571.c        Module.symvers    e1000e.mod.c  hw.h       kcompat.h  mac.h               modules.order  nvm.o     phy.o
82571.h        common.mk         e1000e.mod.o  ich8lan.c  kcompat.o  mac.o               netdev.c       param.c   ptp.c
groucho@devuan:~$ 

Patch location:

groucho@devuan:~$ ls /usr/src/e1000e-patch/
e1000e_384_param_eee_be_disabled.patch  patch.txt
groucho@devuan:~$ 

Having verified the path was correct, I ran the patch:

groucho@devuan:~$ cd /usr/src/e1000e-3.8.7/src && sudo patch -p0 --dry-run --fuzz 0 -i /usr/src/e1000e-patch/e1000e_384_param_eee_be_disabled.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- src/param.c	2021-04-27 23:48:45.280682963 +0200
|+++ src/param.c	2021-04-28 00:03:09.596756791 +0200
--------------------------
File to patch: param.c
checking file param.c
groucho@devuan:/usr/src/e1000e-3.8.7/src$ 

Thinking I had somehow muggled up the path, ran the patch again, but from && onwards:

groucho@devuan:/usr/src/e1000e-3.8.7/src$ sudo patch -p0 --dry-run --fuzz 0 -i /usr/src/e1000e-patch/e1000e_384_param_eee_be_disabled.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- src/param.c	2021-04-27 23:48:45.280682963 +0200
|+++ src/param.c	2021-04-28 00:03:09.596756791 +0200
--------------------------
File to patch: param.c
checking file param.c
groucho@devuan:/usr/src/e1000e-3.8.7/src$ 

But got the same result.
As you suggested it is a dry run so no harm done.

My editor (jed) shows that input line 3 reads  @@ -540,17 +540,17 @@ and that line 540 in param.c reads .type = enable_option,.

As I was about to post this, I saw this new post.

Thanks.

I'll run this one and report back.

Edit

I'm getting the same result with the new patch:

groucho@devuan:/usr/src/e1000e-3.8.7/src$ sudo patch -p0 --dry-run --fuzz 0 -i /usr/src/e1000e-patch/e1000e_387.patch
[sudo] password for groucho: 
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- src/param.c	2021-04-28 22:38:00.543340862 +0200
|+++ src/param.c	2021-04-28 22:44:42.391432332 +0200
--------------------------
File to patch: param.c
checking file param.c
groucho@devuan:/usr/src/e1000e-3.8.7/src$ 
groucho@devuan:/usr/src/e1000e-3.8.7/src$ 

To make it easier to run, I shortened the patch name  and ran it from /usr/src/e1000e-3.8.7/src
The dry run asks me for a file name but then does not complain about it.

What am I missing?

Thanks in advance.

Best,

A.

Hello:

What would that be?
Bear in mind that this is the first time I've ever run a patch.
Don't have a clue.

Right ...

Take the file /usr/src/e1000e-3.8.7/src/param.c, open to edit and ...

1.

-			.def  = OPTION_ENABLED
+			.def  = OPTION_DISABLED

... remove the line after - and add the line afte +

2.

+		hw->dev_spec.ich8lan.eee_disable = !opt.def;
+

Add the lines after +, one with code and the other one blank

3.

-			} else {
-				hw->dev_spec.ich8lan.eee_disable = !opt.def;

Remove those two lines and save.

4. recompile a new e1000e.ko. Right?

Q:
This would then be a patched e1000e-3.8.7 and I guess we have to have some version control.
Another directory?

eg: /usr/src/e1000e-3.8.7p, exact copy of /3.8.7 save for param.c where the only change has been in those lines.

Thanks in advance.

Best,

A.

Hello:

Will do.

Thank you very much for checking this out for me.
If this works as intended, maybe you could consider submitting your findings and the patch to https://github.com/torvalds/linux/tree/master/drivers?

Can't say.

Taking into account what you have discovered, I would not discard some hasty cut-and-paste with respect to the e1000e driver.
I have found no spec sheet/manual for the 82566DM-2 controller clearly stating that it either has or does not have EEE capabilty.
When it comes to EEE, the only thing I have found everywhere is reference to "... parts that support it".

As posted previously, I don't see any need for this EEE feature in a desktop, workstation or server.
To me it is just another layer of complication (painfully obvious here) and should be disabled by default.

In my opinion, this sort of EEE is only useful (and only to a <i>limited</i> extent) in a portable, battery operated device or one in which the network component tends to run hot.
eg: some SoCs.

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

Actually, this is the first box I have with an on-board NIC as on-board components have never been my cup of tea.
All my other boxes have had 3Com hardware but I cannot say is any better than Intel stuff.

I still remember the eye watering telco bills (ca. 1995) caused by a 3Com/USR Sportster modem that had  a severe call-dropping problem.
3Com/USR knew of the problem but the solution (a new chip mailed to customerrs at no cost and under warranty) was buried deep down in their website.
Only found out about that thanks to a PCMag article.   8^/

So that's the reason for e1000e: EEE TX LPI TIMER: 00000000 in the tty1 output?

I wonder if that output is the only thing happening here or if it has any effect on something else and is causing the bad shutdowns.

And a noble effort on your behalf.
Very grateful for that.  8^)

Right.

I'll have that done by this afternoon (-03:00 GMT) and report back.

Thanks a lot for your input.

Best,

A.

Hello:

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.

Hello:

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.

Hello:

Yes, I'm aware than it is not supported in every NIC.

But if in this box I get this ...

groucho@devuan:~$ sudo ethtool --show-eee eth0
[sudo] password for groucho: 
Cannot get EEE settings: Operation not supported
groucho@devuan:~$ 

... while at the same time, at every instance of a bad shutdown I get this:

Devuan GNU/Linux 3 devuan tty1
devuan login: [   286.719428] e1000e: eth0 NIC Link is Down
--- snip ---
[287.219230] e1000e: EEE TX LPI TIMER: 00000000              <-------------- | x |
[287.223022] ACPI: Preparing to enter sleep state S5
[287.223551] reboot: Power down

... it is clear (to me) that this is a NIC that does support EEE.
At the same time, access to both the EEE status and settings via ethtool is disabled in the e1000e driver.

But I think I am (?) getting somewhere:

I now tried this:

[root@devuan groucho]# echo "options e1000e SmartPowerDownEnable=0" | sudo tee /etc/modprobe.d/e1000e.conf

groucho@devuan:~$ cat /etc/modprobe.d/e1000e.conf
options e1000e SmartPowerDownEnable=0
groucho@devuan:~$ 

An update-initramfs -u -k all and a reboot later ...

groucho@devuan:~$ sudo dmesg | grep e1000e
--- snip ---
[    2.147204] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    2.158309] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    2.169606] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[    2.180672] e1000e 0000:00:19.0: PHY Smart Power Down Disabled           <-----  | x |
[    2.603166] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:14:4f:4a:a2:81
[    2.616729] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[    2.637607] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 6, PBA No: FFFFFF-0FF
[   27.495860] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[   27.507904] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
--- snip ---
groucho@devuan:~$ 

The tty1 on a plain sudo shutdown -h now instead the one I've been using sync && sudo ethtool -s eth0 wol d && sudo rmmod -s -v e1000e && sudo shutdown -h now shows no trace of the EEE TX LPI TIMER: 00000000 (have to check with a video grab)*.

If that is so, I'll start using the plain unedited shutdown script I  was using ie: sync && sudo shutdown -h now and wait to see if I get another bad shutdown.

Hopefully, I won't.  8^/

* Unfortunately, I can confirm that disabling SmartPowerDownEnable does not do much with/to EEE.

The tty1 output when shutting down with sync && sudo shutdown -h now shows the line e1000e: EEE TX LPI TIMER: 00000000, which unless I am mistaken, is telling me that EEE is still active.

Which is precisely what I want to avoid.  8^7

Devuan GNU/Linux 3 devuan tty1
devuan login: [        ] e1000e: eth0 NIC Link is Down
[        ] EXT-fs (sdb1): re-mounted. Opts: (null)
[        ] kvm: exiting hardware virtualization
[        ] sd 7:0:3:0: [sdf] Syncronizing SCSI cache
[        ] sd 7:0:2:0: [sde] 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
[        ] e1000e: EEE TX LPI TIMER: 00000000    <--------- | x |
[        ] ACPI: Preparing to enter sleep state S5
[        ] reboot: Power down

Thanks for your input.

Best,

A.

Hello:

groucho@devuan:~$ ls /sys/module/e1000e/parameters
copybreak
groucho@devuan:~$ cat /sys/module/e1000e/parameters/copybreak
256
groucho@devuan:~$ 

Hmm ...
I think this is the e1000 driver but the 82566DM-2 controller uses the e1000e driver.
At least in my Devuan it loads the e1000e module.

groucho@devuan:~$ sudo ethtool -i eth0
driver: e1000e             <---- | x |
version: 3.2.6-k
firmware-version: 1.4-0
expansion-rom-version: 
bus-info: 0000:00:19.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
groucho@devuan:~$ 

See https://downloadmirror.intel.com/15817/eng/readme.txt

Ah ...
Thanks for the heads up, good to know.
No error for madeup_nonsense=1 then?

Thanks for your input.

Best,

A.

Hello:

No, I don't.

That's the reason I posted about the old modules in the first place.
I didn't understand why these files pertaining to 4.9.0-8-amd64 and 4.19.0-14-amd64 were still around.

More importantly, why in spite of having manually removed the old kernels (each time) these files were there.
Still don't know the reason, but they are not there anymore:

[root@devuan groucho]# dpkg -S /lib/modules/*
linux-image-4.19.0-16-amd64, linux-headers-4.19.0-16-amd64: /lib/modules/4.19.0-16-amd64
[root@devuan groucho]# 

Thanks for your input.

Best,

A.

Hello:

Yes, makes sense.
But you never know.

Found this a while ago:

https://unix.stackexchange.com/question … ib-modules

You run # dpkg -S /lib/modules/* to check whether any installed package matches those directories.
Then you can delete any directory for which the above says: dpkg-query: no path found matching pattern /lib/modules/...

Thanks for your input.

Best,

A.

Hello:

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.

Hello:

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.