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.

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.