Hello:

Well ...
Looks fine to me.  8^)

OK.

So ...
I see you're still discovering e1000e fun.

Whenever you can.

Thanks in advance,

Best.

A.

Hello:

Good.

Which could eventually be corrected.
eg: EEE being enabled for all hardware / SmartPowerDownEnabled not doing anything but reporting it is.

Q:
I see the e1000e: EEE TX LPI TIMER: 00000000 line is still present at shutdown.
Wasn't EEE disabled with the first patch you wrote?

Yes, actually looking forward to a bad shutdown.
But it is absolutely impredictable and aleatory.
Never been able to reproduce it.

Typical.
When you do want something to happen ...

If I knew what that was all about ...

Thanks in advance,

A.

Hello:

Glad to hear that.  8^D

I'll go back and check it out after this.

Great ..

OK.
What I now have is the e1000e v.3.4.7 module, downloaded from Intel and patched with the e1000e_387_param_eee_be_disabled.patch and e1000e_387_netdev_shutdown_debug_messages_v2.patch files you wrote.

The module loads without issue:

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

If I understand correctly, what I now have to do is edit my shutdown script to be a simple shutdown -h now.
This would (apparently) not prevent a bad shutdown and your patch will show some of the fun on the screen for me grab.

I say apparently because by shutting down with the script I have not had a bad shutdown in ~10 days. 
Is there any other test you want me to run before I do that?

Won't work.
Unless you paste it over another piece of paper.  8^)

The problem I have is the lack of background in this specific area ie: coding.
I would not hesitate to take apart and try to diagnose any of today's PC/Workstations.
Although I am a bit far behind HW wise, I can catch up in a few hours with the proper literature at hand. 

But this gets me.  8^/

Edit 1:
This is what the shutdown tty1 output (not a bad one) looks like.

Edit 2:
Sorry, I uploaded the wrong image ... 8^/

Now we are seeing your debug messages.  8^D

Also found this in dmesg, had never looked at it by pci bus numbers:

--- snip ---
[    1.080260] pci 0000:00:19.0: [8086:10bd] type 00 class 0x020000
[    1.080275] pci 0000:00:19.0: reg 0x10: [mem 0xf5fc0000-0xf5fdffff]
[    1.080282] pci 0000:00:19.0: reg 0x14: [mem 0xf5ffe000-0xf5ffefff]
[    1.080288] pci 0000:00:19.0: reg 0x18: [io  0xac00-0xac1f]
[    1.080335] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold      <---- | x |
--- snip ---

From here on, I will be shutting down without previously removing the module.
Let's see what happens now.

Thanks a lot for your input.  8^)

Best,

A.

Hello:

I only added --dry-run to the command line.
I checked the paths and they are correct:

groucho@devuan:/$ locate e1000e_387_v2.patch
/home/groucho/Downloads/e1000e_387_v2.patch
/usr/src/e1000e-patch/e1000e_387_v2.patch      # <--- | x |
groucho@devuan:/$ 

groucho@devuan:/$ locate /src/param.c
/usr/src/e1000e-3.8.4/src/param.c
/usr/src/e1000e-3.8.7/src/param.c
/usr/src/e1000e-3.8.7p/src/param.c
/usr/src/e1000e-3.8.7q/src/param.c       # <--- | x |
groucho@devuan:/$ 

Like I mentioned, /usr/src/e1000e-3.8.7q/src/ is a copy of /usr/src/e1000e-3.8.7p/src/.
Just in case, I deleted it and made a new copy:

[root@devuan src]# cp -R e1000e-3.8.7p e1000e-3.8.7q

[root@devuan src]# ls -1 | grep e1000e
e1000e-3.8.4
e1000e-3.8.4.tar.gz
e1000e-3.8.7
e1000e-3.8.7.tar.gz
e1000e-3.8.7p
e1000e-3.8.7q      # <---- | x |
e1000e-patch
[root@devuan src]# 

It worked:    8^D

groucho@devuan:/$ sudo patch -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch -d /usr/src/e1000e-3.8.7q/
patching file src/netdev.c
groucho@devuan:/$ 

Now to compile the module:

groucho@devuan:/usr/src/e1000e-3.8.7q/src$ sudo make
make[1]: Entering directory '/usr/src/linux-headers-4.19.0-16-common'
make[2]: Entering directory '/usr/src/linux-headers-4.19.0-16-amd64'
  CC [M]  /usr/src/e1000e-3.8.7q/src/netdev.o
/usr/src/e1000e-3.8.7q/src/netdev.c: In function 'e1000e_pm_freeze':
/usr/src/e1000e-3.8.7q/src/netdev.c:7413:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
   int count = E1000_CHECK_RESET_COUNT;
   ^~~
  CC [M]  /usr/src/e1000e-3.8.7q/src/ethtool.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/ich8lan.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/mac.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/nvm.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/phy.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/manage.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/80003es2lan.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/82571.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/param.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/ptp.o
  CC [M]  /usr/src/e1000e-3.8.7q/src/kcompat.o
  LD [M]  /usr/src/e1000e-3.8.7q/src/e1000e.o
  Building modules, stage 2.
  MODPOST 1 modules
  CC      /usr/src/e1000e-3.8.7q/src/e1000e.mod.o
  LD [M]  /usr/src/e1000e-3.8.7q/src/e1000e.ko
make[2]: Leaving directory '/usr/src/linux-headers-4.19.0-16-amd64'
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-16-common'
groucho@devuan:/usr/src/e1000e-3.8.7q/src$ 

But there's a warning.

Thanks in advance,

A.

Hello:

Indeed.

https://forums.theregister.com/forum/al … e_spotted/

May?

systemd is the ideal vector for all sorts of nastry stuff, it is just the LInux version of the registry in MSOSs
This new discovery is just a trial run, the next one or the one after that will probably not be noticed.

I can't believe that this can even be considered a subject to be discussed.
But then that's just my $0.02.

A.

Hello:

I don't have a clear idea of absolute, but incremental I get.

Not in /?

Evidently I'm not in that intersection of the venn diagramme.  8^D!

It's the unapply thing that complicates my train of thought.

An architect by trade, 30+ years at it has sunk in deeply
It's the way I keep track of previous versions so I can go back to them.
Freehand drafting table stuff, before this CAD thing.

eg:
1. sketch A, with a min of corrections/erasing. (erasing = unpatch)
2. but sketch A needs to be modified and see changes clearly/check the result.
3. put a translucid piece of paper over sketch A and draw on that
4. result is sketch B, a modified sketch A (sketch B = incremental patch)

But in this case, as the second patch did not work/was modified, I deleted it to avoid confusion. 
The equivalent of throwing away the piece of paper used in 3.

Hmm ...
I get that it is not the 'usual way' but it is the way I got an easier grasp of it.

But ...
Isn't that what I did yesterday?   

ie:
I had an original working 3.8.7 params.c patched to 3.8.7p params.c which worked and showed us the 'fun' you were looking for.

I then applied the v2 patch to it to get 3.8.7q which would hopefully debug the e1000e mess.
ie: 3.8.7p + v2.patch = 3.8.7q

groucho@devuan:/$ sudo patch -p0 --dry-run --fuzz 0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch  /usr/src/e1000e-3.8.7q/src/param.c

v2 patch is at /usr/src/e1000e-patch/e1000e_387_v2.patch

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

A complete copy of the 3.8.7p code, renamed as 3.8.7q is at /usr/src/e1000e-3.8.7q/src/param.c

groucho@devuan:~$ sudo cp -R e1000e-3.8.7p e1000e-3.8.7q

It contains param.c ...

groucho@devuan:~$ ls /usr/src/e1000e-3.8.7q/src/param.c
/usr/src/e1000e-3.8.7q/src/param.c
groucho@devuan:~$ 

... which is identical to it's original version:

groucho@devuan:~$ diff /usr/src/e1000e-3.8.7p/src/param.c  /usr/src/e1000e-3.8.7q/src/param.c
groucho@devuan:~$ 

And I got this:

groucho@devuan:/$ sudo patch -p0 --dry-run --fuzz 0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch  /usr/src/e1000e-3.8.7q/src/param.c
checking file /usr/src/e1000e-3.8.7q/src/param.c
Hunk #1 FAILED at 5300.   -> same
Hunk #2 FAILED at 5341.  -> same
Hunk #3 FAILED at 5358.  -> same
Hunk #4 FAILED at 7373.  -> was 7377
4 out of 4 hunks FAILED
groucho@devuan:/$ 

What did I miss?

Indeed ...

This part I don't get.
I'm confident we'll ge there.  8^D

Thank you so much for your input.

Best,

A.

Edit:
On Mars too ...

https://www.theregister.com/2021/04/30/ … ght_flops/

Sorry, OT but could not resist.  8^D !

Hello:

Hmm ...
Until I do a hard reboot?
I once let it run for a good while, I think it eventually rebooted.
Can't remember.

OK

No need to unapply.
I'll just backtrack and do what I did before, no big deal.
Better start with a clean e1000e-3.8.7p.   

Thanks a lot for your help.

I'll get to this right away if I can manage or early tomorrow morning at the latest and report results.

Cheers,

A.

Hello;

Yes ...
This corner.   8^/

I see.

OK

Yes.
What I did when I started with this: take a photo of the screen when it froze.
Right?

And I'll have to use the plain standard shutdown -h now.

OK

Q: which one do I patch?
The unpatched 3.8.7 or the once patched 3.8.7 --> 3.8.7p
If the 3.8.7p, it would become 3.8.7q.
Make sense?

If you say so ...  8^ *

Yes, I saw that.

It is famous for how 'problematic' it is.
And it goes waaaay back.
It never got fixed.

Let me know.

Thanks in advance,

A.

Hello:

Hmmm ...
The only harmless code is the well written code.

Evidently it's only us (?)
Certainly not the hacks at Intel

Ahh ...
Then those are the ones screwing up my shutdowns.

Can't make heads or tails from it.

I only know that my rig does not have any suspends enabled and the NIC does not support EEE of any sort.

It seems to me that whoever slapped together the driver did not take into account that a great deal of the code was not to be run if the part was not EEE able or if there were no S states besides S0, S1 or S5 in play.

Seems that it is what the interruped shutdown is doing ...
But there's no sleep to finish although the counter (LX LPI Timer) is at 00000000.

It's a wonder that the damned driver works at all ...

Thanks for your input.

Best,

A.

Hello:

Hmm ....
No idea.
I cut my rock teeth on Beatles, CSN&Y, S&G, Joe C., J.Joplin, Stones, BS&T ...
My first album was Abbey Road, hot off the press.

Not that there's anything wrong with boobies.  8^D

Ahh ...
I see.

I thought as much.
Happy to know I was not too far off the mark.

Let me know if you need me to help with some digging.

Thanks a lot for your input.

Best,

A.

Hello:

Good ...
Then it's | one | for the good guys.

... you.
You were the one who discovered this.
As you know, I don't have a clue.
I just ask and try to make sense of the answer.

Whenever you can.
In the meanwhile I run with the e1000e-3.8.7p version and hope to be able to confirm that the unloading of the module avoids the bad shutdown.
Which in turn would confirm the e1000e module as the cuprit.

If I understand correctly, the module has has EEE set to Enabled by default on all the devices it is used on, irrespective of the hardware supporting EEE.
Looks like I am right in assuming that the driver was just slapped together with not much attention paid to it.
Nice going Intel ...  8^/

If this is so, how can we be sure that some routine/code within the module is not broadcasting something EEEish and causing the freeze?
eg: the autonegotiation part of the code that is needed for EEE to work.

Make sense?

Once again, thank you very much for your help in this matter.

Best,

A.

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.