You are not logged in.
Well, it is okay for the most parts, but hangs or crashes in corner-cases. 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.
Last edited by geki (2021-04-29 20:18:23)
Offline
Hello;
... okay for the most parts, but hangs or crashes in corner-cases.
Yes ...
This corner. 8^/
Suspend and shutdown is similar ...
... has nothing to do with EEE actually, now.
I see.
... this is quite tricky, therefore we do print debug messages to see where it hopefully goes wrong.
OK
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?
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^ *
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
Yes. Please apply both patches. We will get a better result.
Last edited by geki (2021-04-29 21:13:59)
Offline
Hello:
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
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.
Offline
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
Hello:
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
... 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 /.
... 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
Hello:
... 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
Yes, issue of either incremental or absolute.
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.
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. Keep it simple instead.
Offline
Hello:
Yes, issue of either incremental or absolute.
I don't have a clear idea of absolute, but incremental I get.
1. Use the commands I used being in root of your source tree.
Not in /?
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!
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.
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?
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/
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
Your patch command makes no sense. Copy my commands. And you succeed.
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.
Last edited by geki (2021-04-30 15:33:46)
Offline
Hello:
... patch command makes no sense.
At least someone knows what's going on. 8^/
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
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
... 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
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, 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.
Alternative:
$ patch -p0 -i /usr/src/e1000e-patch/e1000e_387_v2.patch -d /usr/src/e1000e-3.8.7q/
That rocks.
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.
Last edited by geki (2021-04-30 20:15:24)
Offline
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.
Last edited by geki (2021-04-30 20:21:06)
Offline
Hello:
# 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.
Remember, 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.
I think I'll have to see about taking a course to be able to do at least the basics.
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
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 ...
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
Hello:
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
Yep, you mix it up. And you do not follow my commands to the letter. 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
Offline
Hello:
Yep, you mix it up.
I don't understand what I have mixed up.
... do not follow my commands to the letter.
Hmm ...
You lost me here.
The patch is not correctly applied?
ie:
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?
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
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.
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. 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.
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
Hello:
Yes, in the end it applied ...
Glad to hear that. 8^D
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.
... 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?
... 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^/
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
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.
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. 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.
Offline
Hello:
... 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
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.
Last edited by geki (2021-05-02 18:27:17)
Offline
Hello:
... nothing more to test.
Good.
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?
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 ...
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
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