The officially official Devuan Forum!

You are not logged in.

#26 2021-04-29 20:15:07

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Well, it is okay for the most parts, but hangs or crashes in corner-cases. big_smile Suspend and shutdown is similar in the driver, same functions used. This has nothing to do with EEE actually, now.

Hokay, this is quite tricky, therefore we do print debug messages to see where it hopefully goes wrong. But you have to hang the shutdown for this again and show the last messages printed on screen....
Patch: https://geki.selfhost.eu/hacks/e1000e_3 … ages.patch

I hope, that the message PM FREEZE NETIF RUNNING will not print. That is the obvious issue also discussed in the above-mentioned link. They mentioned e1000e driver, too. big_smile

Last edited by geki (2021-04-29 20:18:23)

Offline

#27 2021-04-29 20:37:14

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello;

geki wrote:

... okay for the most parts, but hangs or crashes in corner-cases.

Yes ...
This corner.   8^/

geki wrote:

Suspend and shutdown is similar ...
... has nothing to do with EEE actually, now.

I see.

geki wrote:

... this is quite tricky, therefore we do print debug messages to see where it hopefully goes wrong.

OK

geki wrote:

But you have to hang the shutdown for this again and show the last messages printed on screen ...

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?

geki wrote:

I hope, that the message PM FREEZE NETIF RUNNING will not print.
That is the obvious issue also discussed in the above-mentioned link.

If you say so ...  8^ *

geki wrote:

They mentioned e1000e driver, too.

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.

Offline

#28 2021-04-29 21:10:49

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Yes. Please apply both patches. We will get a better result.

Last edited by geki (2021-04-29 21:13:59)

Offline

#29 2021-04-29 21:22:12

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

geki wrote:

Yes. Please apply both patches. We will get a better result.

Sorry if I appear to be an idiot.  8^/

Second patch applied to 3.8.7p  ->  3.8.7q.
Right?

----

In /usr/src I copied the e1000e-3.8.7p to e1000e-3.8.7q, renamed the second patch e1000e_387_2.patch and ran the test from /.
Got this:

groucho@devuan:/$ sudo patch -p0 --dry-run --fuzz 0 -i /usr/src/e1000e-patch/e1000e_387_2.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.
Hunk #2 FAILED at 5341.
Hunk #3 FAILED at 5358.
Hunk #4 FAILED at 7377.
4 out of 4 hunks FAILED
groucho@devuan:/$ 

Thanks in advance,

A.

Last edited by Altoid (2021-04-29 21:52:19)

Offline

#30 2021-04-29 21:58:25

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Good that you ask. I acually reworked the second patch to keep a local pdev pointer from adapter->pdev, since we are shutting down. Who knows how long adapter->pdev is alive....

Patch v2: https://geki.selfhost.eu/hacks/e1000e_3 … s_v2.patch

Yes, please apply param patch and the v2 of netdev shutdown patch. Example: unapply e1000e_387_netdev_shutdown_debug_messages.patch and apply e1000e_387_netdev_shutdown_debug_messages_v2.patch instead, if you got that v1 applied already. That one hopefully does not crash unexpectedly.... May still crash... But we get v1still some clues!

Ask again, if you need. smile

Offline

#31 2021-04-29 22:00:59

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

If you copy the param patched source, the param patch must not be applied again. That is all. And again, please use v2 of the netdev shutdown patch! Otherwise false positive hang or crash may happen.

Offline

#32 2021-04-29 22:11:01

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

geki wrote:

Good that you ask.
... reworked the second patch to keep a local pdev pointer from adapter->pdev, since we are shutting down.
Who knows how long adapter->pdev is alive....

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

geki wrote:

... apply param patch and the v2 of netdev shutdown patch.

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.   

In /usr/src I copied the e1000e-3.8.7p to e1000e-3.8.7q, renamed the second patch e1000e_387_2.patch and ran the test from /.

geki wrote:

... hopefully does not crash unexpectedly....
May still crash...
But we get v1still some clues!
Ask again, if you need.

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.

Offline

#33 2021-04-29 22:32:01

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

Altoid wrote:

... get to this right away ...

I deleted the now old e1000e-3.8.7q directory and then repeated what I did the last time with the previous patch:

Copied the e1000e-3.8.7p directory to e1000e-3.8.7q, renamed the last patch e1000e_387_v2.patch (deleting its predecesor) and ran the test from /.

But got the same result but with one different line number (?)

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:/$ 

Thanks in advance.

Best,

A.

Offline

#34 2021-04-30 05:09:40

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Yes, issue of either incremental or absolute. big_smile

1. Use the commands I used being in root of your source tree. See my example work-flow. That is how everyone expects it to be used. smile
2. Do not confuse yourself with making different copies of the source tree. Keep just vanilla being patched and apply/unapply there.
3. If you need to do it that way: p -> q obviously needs only netdev shutown v2 patch (incremental)
4. Or somewhat sane: vanilla -> ${STRANGE_VERSIONING} obviously needs all, param and netdev shutdown v2 patch (absolute)

Now, I hope I got you some more confused. cool Keep it simple instead.

Offline

#35 2021-04-30 11:34:41

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

geki wrote:

Yes, issue of either incremental or absolute.

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

geki wrote:

1. Use the commands I used being in root of your source tree.

Not in /?

geki wrote:

See my example work-flow. That is how everyone expects it to be used.

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

geki wrote:

2. Do not confuse yourself with making different copies of the source tree.
Keep just vanilla being patched and apply/unapply there.

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.

geki wrote:

3. If you need to do it that way: p -> q obviously needs only netdev shutown v2 patch (incremental)

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?

geki wrote:

4. Or somewhat sane: vanilla -> ${STRANGE_VERSIONING} obviously needs all, param and netdev shutdown v2 patch (absolute)
Now, I hope I got you some more confused.

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/

Laura Dobberstein wrote:

The reason for the failure is also known: a software bug that results in a watchdog timer expiration prior to mode transition.
And if Ingenuity doesn't make it into flight mode, it doesn't fly.

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

Last edited by Altoid (2021-04-30 13:20:51)

Offline

#36 2021-04-30 15:14:59

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Your patch command makes no sense. big_smile Copy my commands. And you succeed. cool

Edit If you want to be so smart I recommend you not to add the file, to forcefully try to apply patchfile content onto. But rather check out patch parameter -d. E heh. cool

Last edited by geki (2021-04-30 15:33:46)

Offline

#37 2021-04-30 16:22:56

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

geki wrote:

... patch command makes no sense.

At least someone knows what's going on.  8^/

geki wrote:

Copy my commands.
And you succeed.

OK.

Would this command set be correct? ie: applying the v2 patch to the copy of the e1000e-3.7.8p module.

# cd /usr/src/e1000e-3.8.7q/src/ && patch --dry-run -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch

geki wrote:

If you want to be so smart ...

Nah!
I'd like to be able to do this as easily as I can do other things I've been doing for a long time.  8^7

geki wrote:

... recommend you not to add the file, to forcefully try to apply patchfile content onto.
But rather check out patch parameter -d.

I'll have to look at that later on.

Thanks for the heads up.

Best,

A.

Offline

#38 2021-04-30 20:07:28

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Altoid wrote:

Would this command set be correct? ie: applying the v2 patch to the copy of the e1000e-3.7.8p module.

# cd /usr/src/e1000e-3.8.7q/src/ && patch --dry-run -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch

Close call. Would be instead:

$ pushd /usr/src/e1000e-3.8.7q/ # <<<-- That is the root of your driver's source code ^_-_^
$ patch -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch
$ popd

Remember, smile if you enter sub directories like src, the -pN param increases respectively. big_smile And take the pieces for hunks of the patch not being within that sub directory. yikes

Alternative:

$ patch -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch -d /usr/src/e1000e-3.8.7q/

That rocks. big_smile

And as a note: Do not mix source code directory and the actual c code directories. Source code is more than just the .{c*,h*} files. I guess you mix these. smile

Last edited by geki (2021-04-30 20:15:24)

Offline

#39 2021-04-30 20:20:31

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Ado

$ grep ^\+\+\+ e1000e_387_netdev_shutdown_debug_messages_v2.patch 
+++ src/netdev.c	2021-04-29 23:39:38.044088043 +0200

And

$ patch -p0 -i e1000e_387_netdev_shutdown_debug_messages_v2.patch -d Downloads/e1000e-3.8.7/

Now, what file will be patched? Right:

Downloads/e1000e-3.8.7/src/netdev.c

There is no magic involved. Just get your paths right. big_smile

Last edited by geki (2021-04-30 20:21:06)

Offline

#40 2021-04-30 21:10:41

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

geki wrote:

# cd /usr/src/e1000e-3.8.7q/src/ && patch --dry-run -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch

Close call.
Well ...
I think I followed (?) your example to the letter.

Would be instead:

$ pushd /usr/src/e1000e-3.8.7q/      # <<<-- That is the root of your driver's source code ^_-_^
$ patch -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch
$ popd

Hmm ...

Have to find out what pushd and popd are.
And learn how to use them in this context.

geki wrote:

Remember, smile if you enter sub directories like src, the -pN param increases respectively.
And take the pieces for hunks of the patch not being within that sub directory. yikes

I think I'll have to see about taking a course to be able to do at least the basics.

geki wrote:

Alternative:

$ patch -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch -d /usr/src/e1000e-3.8.7q/

That rocks.

Then that's the one I'll use.  8^D

geki wrote:

Do not mix source code directory and the actual c code directories. Source code is more than just the .{c*,h*} files. I guess you mix these.

Well ...
When I unpacked the code files, in all there is a /src directory and all this inside:

groucho@devuan:/usr/src/e1000e-3.8.7/src$ ls
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:/usr/src/e1000e-3.8.7/src$ 

They are already mixed ...

geki wrote:

There is no magic involved. Just get your paths right.

Till I learn how to do it right, it's no magic but a language I am not proficient in.
I'd starve.

I'll patch, compile e1000e-3.8.7q and report back.

Thanks a lot for your help.  8^ )

Best,

A.

Offline

#41 2021-04-30 22:01:22

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

Altoid wrote:

I'll patch, compile e1000e-3.8.7q and report back.

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.

Offline

#42 2021-05-01 08:38:48

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Yep, you mix it up. And you do not follow my commands to the letter. There is more than src to it. big_smile

die@deiwl:~/Downloads/e1000e-3.8.7$ ls -R
.:
COPYING                                             e1000e_387_param_eee_be_disabled.patch  pci.updates  SUMS
e1000e_387_netdev_shutdown_debug_messages.patch     e1000e.7                                README
e1000e_387_netdev_shutdown_debug_messages_v2.patch  e1000e.spec                             src

./src:
80003es2lan.c  common.mk  hw.h       kcompat_ethtool.c   mac.h     Module.supported  nvm.h         phy.h
80003es2lan.h  defines.h  ich8lan.c  kcompat.h           Makefile  netdev.c          param.c       ptp.c
82571.c        e1000.h    ich8lan.h  kcompat_overflow.h  manage.c  netdev.c.orig     param.c.orig  regs.h
82571.h        ethtool.c  kcompat.c  mac.c               manage.h  nvm.c             phy.c

Offline

#43 2021-05-01 11:39:01

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

geki wrote:

Yep, you mix it up.

I don't understand what I have mixed up.

geki wrote:

... do not follow my commands to the letter.

Hmm ...
You lost me here.
The patch is not correctly applied?

ie:

geki wrote:

    Alternative:

    $ patch -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch -d /usr/src/e1000e-3.8.7q/

    That rocks.

That is what I did and I got this output:

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:/$ 

Which part of that is wrong?

geki wrote:

There is more than src to it.

die@deiwl:~/Downloads/e1000e-3.8.7$ ls -R
.:
COPYING                                             e1000e_387_param_eee_be_disabled.patch  pci.updates  SUMS
e1000e_387_netdev_shutdown_debug_messages.patch     e1000e.7                                README
e1000e_387_netdev_shutdown_debug_messages_v2.patch  e1000e.spec                             src

./src:
80003es2lan.c  common.mk  hw.h       kcompat_ethtool.c   mac.h     Module.supported  nvm.h         phy.h
80003es2lan.h  defines.h  ich8lan.c  kcompat.h           Makefile  netdev.c          param.c       ptp.c
82571.c        e1000.h    ich8lan.h  kcompat_overflow.h  manage.c  netdev.c.orig     param.c.orig  regs.h
82571.h        ethtool.c  kcompat.c  mac.c               manage.h  nvm.c             phy.c

Yes, than much I do understand.
The only difference I see is that I have the patches in /usr/src/e1000e-patch:

groucho@devuan:/usr/src$ ls e1000e-patch
e1000e_384.patch  e1000e_387.patch  e1000e_387_v2.patch  patch.txt
groucho@devuan:/usr/src$ 

It's difficult to get a grasp of all this due to my lack of experience in anything code related.
Maybe just *.bat files but not too complex.
I have always dealt in hardware support (desktops to servers) and installs, not code.

Thanks in advance,

A.

Offline

#44 2021-05-01 21:14:04

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Yes, in the end it applied. But before, you wanted to apply the patch being in sub directory src. That just fails. Then, you told patch explicitly which file to apply the content onto. That just fails. I did not do that in my commands. That's all. smile

Compare below to what you tried before. And to my commands I posted. You may see the difference.

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:/$ 

In the end it applied. big_smile Therefore we can go on.

Edit The failures freely translated into sketching:

Cut a region out of sketch A, throw away the rest of sketch A, and then want to make corrections outside of that region into sketch B. It is just not there.

Edit The (ascii-art) sketch we work with here is the content of my above-printed output of ls -R. The files and directories are the parts and regions of the sketch. cool

Edit Repetition:

- patch parameter -p0 -> Sketch-wide, -p1 -> move into 1. level of regions, -pN -> move into N. level of sub regions. You may notice the implication, that if you want to modify multiple regions it fails.
- patch parameter "destination file to apply content onto" tells what part in a region to correct, but you be in a wrong region or part, oups you go https://www.youtube.com/watch?v=CduA0TULnow

Last edited by geki (2021-05-01 21:58:05)

Offline

#45 2021-05-01 22:16:55

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

geki wrote:

Yes, in the end it applied ...

Glad to hear that.  8^D

geki wrote:

Compare below to what you tried before. And to my commands I posted. You may see the difference.

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:/$

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

geki wrote:

... we can go on.

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?

geki wrote:

... failures freely translated into sketching:
Cut a region out of sketch A, throw away the rest of sketch A ...

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^/

3-8-7q-NAPI-EEE.png

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.

Last edited by Altoid (2021-05-02 15:34:35)

Offline

#46 2021-05-02 10:24:18

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Altoid wrote:
geki wrote:

... failures freely translated into sketching:
Cut a region out of sketch A, throw away the rest of sketch A ...

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

Yeah, I skipped some details. The nomenclature is off, too, I guess. big_smile

Though, the procedures are quite similar in many business/work processes. And I guess its common pattern to start from the (local) root. Therefore, you see in good examples usually a cd /path/to/shelf/floor/sketch/ as first command. And since we are lazy, we base all changes onto that root. Otherwise things mix up and fail. roll Only thing we may have to adjust is the parameter -pN of patch for some flavors like Git Patch or extracted libraries of big projects, like a detail-sketch of a part of the overview-sketch. But then you have to extract patches respectively. For me, its all the same. cool

Offline

#47 2021-05-02 11:38:31

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

geki wrote:

... procedures are quite similar in many business/work processes.

I think that in the end it is doing things like you are used to doing them.
Either in specific known things or adapting the learnt methods to other unknown things.
Sorry if I sound like I am channeling Rumsfeld ...  8^/

Back in early 2019, posted to a Sourceforge Intel Ethernet Drivers and Utilities page and received this interesting answer: https://sourceforge.net/p/e1000/bugs/635/#d3ba .
Besides the tech's slip, which seems to be much more sincericide than a lapsus linguae, 2012 marked the last of interactive support for this driver, so at Linux and much more so at Devuan, we're on our own.

And whatever RHE does for it, be sure the source code won't be available. 

You've discovered interesting/fun facts: EEE seems to be enabled by default for anything and everything using this module and enabling SmartPowerDownEnable reports itself as Enabled in spite of the hardware not supporting it.

Makes me wonder how many more fun tidbits there are lurking inside the code.

Any leeway I can help you make with respect to this module will of great advantage to the Linux community.

Is there any NIC related test you'd need for me to carry out while we wait for a bad shutdown?

Thanks in advance,

A.

Note: check previous post again - uploded the correct tty1 screen grab.

Last edited by Altoid (2021-05-02 15:27:22)

Offline

#48 2021-05-02 18:20:17

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Actually, nothing more to test. It works but the confused initialization and shutdown. Let's see where it hangs in the end. I wonder, if the NETIF CLOSE callback is run in another thread than the PM FREEZE callback. And that they sporadically block each other with that stray detach call, which is obviously wrong in that scope. big_smile

Last edited by geki (2021-05-02 18:27:17)

Offline

#49 2021-05-02 19:06:51

Altoid
Member
Registered: 2017-05-07
Posts: 766  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Hello:

geki wrote:

... nothing more to test.

Good.

geki wrote:

It works but the confused initialization and shutdown.

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?

geki wrote:

Let's see where it hangs in the end.

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 ...

geki wrote:

I wonder, if the NETIF CLOSE callback is run ...
... sporadically block each other with that stray detach call ...

If I knew what that was all about ...

Thanks in advance,

A.

Offline

#50 2021-05-02 21:10:27

geki
Member
Registered: 2019-02-04
Posts: 92  

Re: Linux e1000e module removal and e1000e EEE timer - Part II

Well, if it is not happening always, it is most likely an issue with concurrent access to one resource. In this case the netdev resource on shutdown.
This may help, also mentioned in that mailing list thread: https://www.kernel.org/doc/htmldocs/net … -lock.html

Offline

Board footer