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.

Hello:

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.

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.

Hello:

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.

Hello:

Ahh ...
Now I (sort of) understand.

I get where you are going.

But ...
Maybe I did not explain myself correctly.

Without any intervention on my behalf ie: explicitly unloading the module before shutdown (see script posted previously), when I get a bad shutdown instance, the output on the screen is the same.

ie:

Devuan GNU/Linux ascii devuan tty1
devuan login: [483.367459] EXT-fs (sdc1): re-mounted. Opts: (null)
[485.772216] e1000e: eth0 NIC Link is Down
[485.776885] kvm: exiting hardware virtualization
[485.777756] sd 9:0:3:0: [sdf] Synchronizing SCSI cache
[485.778154] sd 9:0:2:0: [sdf] Synchronizing SCSI cache
[485.781519] e1000e: EEE TX LPI TIMER: 00000000
[485.785219] ACPI: Preparing to enter sleep state S5
[485.868007] reboot: Power down    <---- screen freezes at this point

Now, if I understand what you are saying, then I was right from the very start when I went looking for how to disable the #$&@ timer.

When a bad shutdown comes along, the e1000e: EEE TX LPI TIMER: 00000000 bit shows up and the box freezes as previously described.
But when the shudown is normal, the e1000e: EEE TX LPI TIMER: 00000000 bit is also there but the box shuts down properly.

So ...
It is a question of timing, maybe a +/- 0.5s somewhere may be the 'trigger' for the bad shutdown which has proven impossible for me to replicate.
Absolutely unpredictable, I have had more than a fortnight of uneventful shutdowns and as many as three in just a couple of days.
Then, out of nowhere ...   8^7

Thanks for the heads up.

So it is a kernel problem?
Of course, Intel is doing nobody a favour by making it impossible to disable the EEE Timer.
That would be a very quick fix.

---

Not too easy to test then ...
Maybe that's why the driver is such a POS?

Indeed ...

Unfortunately, it is what came onboard with the U24 which is, even by today's standards, a great piece of kit.
Keep in mind that it was brought  to market almost 15 years ago, in mid 2007.

It was a great buy for me, practically brand new.
And all my slots are filled, so I'll have to make do till this glitch finally gets fixed or I can do something kernel-wise.

Because I hope to be using this HW for a few years more, maybe with a faster SAS controller and SSDs.

Thanks a lot for you input.
Finally I have had some light shed on this rather annoying problem.

Best,

A.

Hello:

No.

Had no idea but I am not at all surprised that the bug exists.
Nor am I surprised that it is unsolved almost two years later.

What I do know (own experience, web-wide rants) is that the e1000e, besides being is a real piece of work, is intrinsically linked* to the Intel Management Engine.

In my Ultra 24's BIOS, the GbE entry is greyed out, you cannot disable it.

ie: the box's owner, OS administrator cannot disable the on-board GbE controller or access the settings the entry presumably allows you to change.
I have not been able to find any instructions anywhere on how to do it. Owner's manual, Field manual, etc. have no mention of it.
WTF?

I run Beowulf which uses the 3.2.6-k version, the problems reported seem to be with the version with the upstream kernels.
And the shutdown problem I have is present from when I first installed Linux on this box, around late 2015.

Upgrading to the last BIOS available (1.56) did not solve the problem.

* : see this post from your link to the bug: https://bugzilla.kernel.org/show_bug.cgi?id=205047#c19

Understand what I am referring to?

My installation has both modules (mei and mei_me) blacklisted in /etc/modprobe.d.
And yes, the problem I have was there before I blacklisted the modules.

No, not planning to do it.

Lockdown has still some time to go, so I may look into trying the DKMS version of the driver.
But I've never done such a thing it and would have to study a bit to see how it is done.

But what really I want to do is to disable the EEE timer.
It was the first thing I thought of doing and have come back to it after trying all sorts of ACPI magic, kernel command entries and DSDT mods, to no avail.

Maybe the email I wrote to the e1000e driver ethtool utility maintainer will get me something.

I fail to understand why e1000e: EEE TX LPI TIMER: 00000000 is still there at shutdown if the module had been previously removed.

Thanks for your input.

Best,

A.

Edited: mail was actually sent to maintainer of ethtool utility - on if it is at all possible to disable EEE Timer / how to do it.
-

Hello:

Painted short, probably?
Have to be more careful.

I see.

Kudos to them.
Thanks for taking the time to explain.

Best,

A.

Hello:

I am not the author of the script.
Unfortunately, I don't have a clue as to how this all works.

Thanks for your input.

Best,

A.