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.

Hello:

Hmm ...
Maybe it's too soon to sign the certificate?
There's still much to be said.

Many years ago (unfortunately much later than I should have) one day I realised that I could always solve any apparent confusion or contradiction by stepping back and having a close look at what was going on with the purpose of getting a grasp of who was where and why.

While the why part of the exercise many times remained (as it usually does) unknown, the who and where have always proved to be quite revealing.
The end result being that whatever confusion or contradiction I may have had cleared up very quickly.

To wit:
I realised I was definitely a Democrat by the age of 13 not because of my reading of the opinion pieces of the two newspapers I delivered every afternoon but by listening to what Mr. Davis, my next door neighbour and certified dyed in the wool Republican had to say about things in general.
I'll always be grateful to the old chap for that.

With respect to the matter of X, if Red Hat, IBM et al are attempting to sink it, don't count me in.
I have faith in the resilience of the Linux ecosystem albeit not in its constituents.

Just my 0.02.

A.

Hello:

Right.
Further thinking about it, I see it makes sense.

I recall (?) thinking about that but did not see the need for the rotated files.
I'll look into that, thanks for the heads up.

Yes, I have seen that done.
And taking into account how unintelligible they are ...

But I have found that they have been a sort of reference for comparison purposes between boots.
Not that I actually solved anything.  8^7

Thanks a lot for your input.

Best,

A.

Hello:

Yes, I'll have a look at the alternatives to *locate + the link and see what I can get.
Thanks a lot for your input.  8^)

Best,

A.