Humm, I'll have to check where  that EEE TX LPI TIMER message comes from.... not from the pci shutdown callback.

Yes, indeed, another oversight.

And the next round of cleaned patches:
https://geki.selfhost.eu/hacks/1001-e10 … bled.patch
https://geki.selfhost.eu/hacks/1002-e10 … ages.patch
https://geki.selfhost.eu/hacks/1003-e10 … eeze.patch
https://geki.selfhost.eu/hacks/1004-e10 … ages.patch

Yah, faster than for my own good.

Now, better naming and to have a complete list, these files may be applied:
https://geki.selfhost.eu/hacks/0001-e10 … bled.patch
https://geki.selfhost.eu/hacks/0002-e10 … s_v3.patch
https://geki.selfhost.eu/hacks/0003-e10 … eeze.patch

As a reminder for me:
- Patch 0001 needs default disabled globally, default enabled for EEE featured devices.
- In the end, remove all debug messages again, e heh.

Sadly, I overlooked one function that is called in the shutdown process... in src/netdev.c. There are these functions involved: e1000e_close (netdev callback seen early in your screen capture), e1000_remove and e1000_shutdown (pci device callbacks). In e1000_shutdown, it seems that the call to e1000e_pm_freeze is just superfluous. Other shutdown callbacks handle it; without that funny unprotected call to the netdev detach function. It seems that this call can safely be removed. I will do a V3 for debug messages, tomorrow.

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

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.

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

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.

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.

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.

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.

Nay, these guys: https://en.wikipedia.org/wiki/Hooray_for_Boobies

Yes, that is the fun - in context to the above-mentioned songs.

Yes, looking for eee and lpi used without the catch of if (!eee_disable) ....