No need to be sorry, I am used to source code too much. I am using Gentoo, its just so natural to patch on issues. And I usually keep my explanation short and too short. Just ask, if something is unclear.

I made another patch that hopefully compiles and prints the state of EEE Support, enabled or disabled, on module initialization, which you can see with dmesg then.
Patch: https://geki.selfhost.eu/hacks/e1000e_3 … bled.patch

And here are the steps to unapply(-R) and appy the patch. You just need to apply, obviously.

die@deiwl:~$ cd Downloads/e1000e-3.8.4/
die@deiwl:~/Downloads/e1000e-3.8.4$ cat e1000e_384_param_eee_be_disabled.patch 
--- src/param.c	2021-04-27 23:48:45.280682963 +0200
+++ src/param.c	2021-04-28 00:03:09.596756791 +0200
@@ -540,17 +540,17 @@
 			.type = enable_option,
 			.name = "EEE Support",
 			.err  = "defaulting to Enabled (100T/1000T full)",
-			.def  = OPTION_ENABLED
+			.def  = OPTION_DISABLED
 		};
 
+		hw->dev_spec.ich8lan.eee_disable = !opt.def;
+
 		if (adapter->flags2 & FLAG2_HAS_EEE) {
 			/* Currently only supported on 82579 and newer */
 			if (num_EEE > bd) {
 				unsigned int eee = EEE[bd];
 				e1000_validate_option(&eee, &opt, adapter);
 				hw->dev_spec.ich8lan.eee_disable = !eee;
-			} else {
-				hw->dev_spec.ich8lan.eee_disable = !opt.def;
 			}
 		}
 	}
die@deiwl:~/Downloads/e1000e-3.8.4$ rm src/param.c.orig 
die@deiwl:~/Downloads/e1000e-3.8.4$ patch -p0 --dry-run -i e1000e_384_param_eee_be_disabled.patch 
checking file src/param.c
Reversed (or previously applied) patch detected!  Assume -R? [n] ^C
die@deiwl:~/Downloads/e1000e-3.8.4$ patch -p0 -R --dry-run -i e1000e_384_param_eee_be_disabled.patch 
checking file src/param.c
die@deiwl:~/Downloads/e1000e-3.8.4$ patch -p0 -R -i e1000e_384_param_eee_be_disabled.patch 
patching file src/param.c
die@deiwl:~/Downloads/e1000e-3.8.4$ patch -p0 --dry-run -i e1000e_384_param_eee_be_disabled.patch 
checking file src/param.c
die@deiwl:~/Downloads/e1000e-3.8.4$ patch -p0 -i e1000e_384_param_eee_be_disabled.patch 
patching file src/param.c
die@deiwl:~/Downloads/e1000e-3.8.4$ grep -C 10 FLAG2_HAS_EEE src/param.c 
	{
		static const struct e1000_option opt = {
			.type = enable_option,
			.name = "EEE Support",
			.err  = "defaulting to Enabled (100T/1000T full)",
			.def  = OPTION_DISABLED
		};

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

		if (adapter->flags2 & FLAG2_HAS_EEE) {
			/* Currently only supported on 82579 and newer */
			if (num_EEE > bd) {
				unsigned int eee = EEE[bd];
				e1000_validate_option(&eee, &opt, adapter);
				hw->dev_spec.ich8lan.eee_disable = !eee;
			}
		}
	}
	/* configure node specific allocation */
	{
die@deiwl:~/Downloads/e1000e-3.8.4$

Yeah, bad description of me. You have to patch the source. ;-)

Like you see in the .rej file - we want to patch the source file: src/param.c.

If you are asked to enter file name when patching, either the path you are in or the '-pN' parameter to patch is wrong. Or the patch is not for your source code. Ctrl-C helps to escape. If you enter the patch command I posted earlier, it should not ask you anything. To test the patch you can do patch -p0 --dry-run -i /path/to/patchfile. The --dry-run saves you from corrupting sourcecode by a bad patch, especially if the patch is big. And to be pedantic, wary or cautious, add --fuzz 0, so that no accompanying lines of code around the changed lines differ.

Just try to apply the patch. If it fails, I check again. It is fun to read source looking for such issues.

Yes, since that eee_disable flag has any value which is in memory at that position, it was true in the old times by sheer luck? Any memory value != 0 at that location is true in that case. And now, with kernel hardening, like default struct values initialization to zero, EEE is on for all e1000e PHY, even if the hardware has no EEE. Well, just some wild guess-work.

My patch explicitly sets the eee_disable flag to true as default.

Well the same function should be in the driver you compiled yourself and comment that line out there and recompile. I wonder if that EEE timer has anything to do with the bad shutdown. Though, I may be wrong.

And another root cause of misbehaving intel NICs wrt EEE are (old!) CAT5 network cables. If you want, try with CAT6/7 (S)FTP cable, if you got such old cable. That solved the EEE issues with some, though, I wonder...

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.

Hmm, on a second thought. For embedded hardware, there is this kernel (early) log piped to serial line feature. To debug early errors. I wonder if that feature works for shutdown, too?! To debug late errors? Never actually used that feature. At some point mounts are ro, right, and gfx stops updates to monitor. Is there some kernel commandline to activate that for debian kernels?

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

I have aided someone else with e1000e issues a decade ago, or so, on the gentoo forums. That one actually worked then with the e1000e linux developer back then. The linux developer of the e1000e actually did not own the hardware, IIRC. The e1000e linux driver thrashed its MAC Address in its early days, IIRC. It is best to avoid that chipset....

That c19 refers to patch from c11. The important patch is referenced in c33 and c55, which went in upstream kernel 5.5. That one seems to undo a major regression wrt the watchog timer handling. So, if you can, you should test kernel 5.5 or newer from beowulf-backports. I may have overseen, that you tested that kernel versions already.... See: https://pkginfo.devuan.org/cgi-bin/poli … mage-5.10*

Remember, if you move from resolvconf to openresolv, purge resolvconf apt-get purge resolvconf to delete init script; and stop it from emitting errors on boot and shutdown.

If you need a patch from cgit web frontend, see:

https://roy.marples.name/cgit/dhcpcd.gi … cpcd-9.3.3
https://roy.marples.name/cgit/dhcpcd-ui … d-ui-0.7.7

Roy likes to add fixes just after release.