You are not logged in.
- Topics: Active | Unanswered
#1226 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-04 11:15:43
Hello:
... check where that EEE TX LPI TIMER message comes from....
I looked into all the files in /src, these had references to LPI:
groucho@devuan:/usr/src/e1000e-3.8.7/src$ cat ethtool.c | grep LPI
* on whether Tx or Rx LPI indications have been received.
if (phy_data & (E1000_EEE_TX_LPI_RCVD | E1000_EEE_RX_LPI_RCVD))
edata->tx_lpi_timer = er32(LPIC) >> E1000_LPIC_LPIET_SHIFT;
e_err("Setting EEE Tx LPI timer is not supported\n");
groucho@devuan:/usr/src/e1000e-3.8.7/src$ groucho@devuan:/usr/src/e1000e-3.8.7/src$ cat ich8lan.c | grep LPI
* the link and the EEE capabilities of the link partner. The LPI Control
* EEE LPI must not be asserted earlier than one second after link is up.
* On 82579, EEE LPI should not be enabled until such time otherwise there
* can be link issues with some switches. Other devices can have EEE LPI
* prevents LPI from being asserted too early.
ret_val = e1e_rphy_locked(hw, I82579_LPI_CTRL, &lpi_ctrl);
lpi_ctrl &= ~I82579_LPI_CTRL_ENABLE_MASK;
lpi_ctrl |= I82579_LPI_CTRL_1000_ENABLE;
lpi_ctrl |= I82579_LPI_CTRL_100_ENABLE;
ret_val = e1000_read_emi_reg_locked(hw, I82579_LPI_PLL_SHUT,
data &= ~I82579_LPI_100_PLL_SHUT;
ret_val = e1000_write_emi_reg_locked(hw, I82579_LPI_PLL_SHUT,
/* R/Clr IEEE MMD 3.1 bits 11:10 - Tx/Rx LPI Received */
ret_val = e1e_wphy_locked(hw, I82579_LPI_CTRL, lpi_ctrl);
/* Set EEE LPI Update Timer to 200usec */
I82579_LPI_UPDATE_TIMER,
* link, and enable Auto Enable LPI since there will
* be no driver to enable LPI while in Sx.
/* Set Auto Enable LPI after link up */
I217_LPI_GPIO_CTRL, &phy_reg);
phy_reg |= I217_LPI_GPIO_CTRL_AUTO_EN_LPI;
I217_LPI_GPIO_CTRL, phy_reg);
* power good. LPI (Low Power Idle) state must also reset only
/* Set bit enable LPI (EEE) to reset only on
phy_reg |= I217_SxCTRL_ENABLE_LPI_RESET;
/* Clear Auto Enable LPI after link up */
e1e_rphy_locked(hw, I217_LPI_GPIO_CTRL, &phy_reg);
phy_reg &= ~I217_LPI_GPIO_CTRL_AUTO_EN_LPI;
e1e_wphy_locked(hw, I217_LPI_GPIO_CTRL, phy_reg);
groucho@devuan:/usr/src/e1000e-3.8.7/src$ groucho@devuan:/usr/src/e1000e-3.8.7/src$ cat ich8lan.h | grep LPI
#define I217_LPI_GPIO_CTRL PHY_REG(772, 18)
#define I217_LPI_GPIO_CTRL_AUTO_EN_LPI 0x0800
#define I82579_LPI_CTRL PHY_REG(772, 20)
#define I82579_LPI_CTRL_100_ENABLE 0x2000
#define I82579_LPI_CTRL_1000_ENABLE 0x4000
#define I82579_LPI_CTRL_ENABLE_MASK 0x6000
#define I82579_LPI_UPDATE_TIMER 0x4805 /* in 40ns units + 40 ns base value */
#define I82579_LPI_PLL_SHUT 0x4412 /* LPI PLL Shut Enable */
#define I82579_LPI_100_PLL_SHUT (1 << 2) /* 100M LPI PLL Shut Enabled */
#define E1000_EEE_RX_LPI_RCVD 0x0400 /* Tx LP idle received */
#define E1000_EEE_TX_LPI_RCVD 0x0800 /* Rx LP idle received */
#define I217_SxCTRL_ENABLE_LPI_RESET 0x1000
groucho@devuan:/usr/src/e1000e-3.8.7/src$ But this was the only one I found with the complete string:
ie: EEE TX LPI TIMER:
groucho@devuan:/usr/src/e1000e-3.8.7/src$ cat netdev.c | grep LPI
pr_info("EEE TX LPI TIMER: %08X\n", # <--- | x |
er32(LPIC) >> E1000_LPIC_LPIET_SHIFT);
/* Ensure that the appropriate bits are set in LPI_CTRL
retval = e1e_rphy_locked(hw, I82579_LPI_CTRL,
lpi_ctrl |= I82579_LPI_CTRL_100_ENABLE;
lpi_ctrl |= I82579_LPI_CTRL_1000_ENABLE;
retval = e1e_wphy_locked(hw, I82579_LPI_CTRL,
groucho@devuan:/usr/src/e1000e-3.8.7/src$ Looked at with jed to get the line numbers:
7150 to 7172
7150 }
7151
7152 static void e1000e_flush_lpic(struct pci_dev *pdev)
7153 {
7154 struct net_device *netdev = pci_get_drvdata(pdev);
7155 struct e1000_adapter *adapter = netdev_priv(netdev);
7156 struct e1000_hw *hw = &adapter->hw;
7157 u32 ret_val;
7158
7159 pm_runtime_get_sync((netdev_to_dev(netdev))->parent);
7160
7161 ret_val = hw->phy.ops.acquire(hw);
7162 if (ret_val)
7163 goto fl_out;
7164
7165 pr_info("EEE TX LPI TIMER: %08X\n",
7166 er32(LPIC) >> E1000_LPIC_LPIET_SHIFT);
7167
7168 hw->phy.ops.release(hw);
7169
7170 fl_out:
7171 pm_runtime_put_sync(netdev->dev.parent);
7172 }7526 to 7554:
7526 }
7527
7528 /* Ensure that the appropriate bits are set in LPI_CTRL
7529 * for EEE in Sx
7530 */
7531 if ((hw->phy.type >= e1000_phy_i217) &&
7532 adapter->eee_advert && hw->dev_spec.ich8lan.eee_lp_ability) {
7533 u16 lpi_ctrl = 0;
7534
7535 retval = hw->phy.ops.acquire(hw);
7536 if (!retval) {
7537 retval = e1e_rphy_locked(hw, I82579_LPI_CTRL,
7538 &lpi_ctrl);
7539 if (!retval) {
7540 if (adapter->eee_advert &
7541 hw->dev_spec.ich8lan.eee_lp_ability &
7542 I82579_EEE_100_SUPPORTED)
7543 lpi_ctrl |= I82579_LPI_CTRL_100_ENABLE;
7544 if (adapter->eee_advert &
7545 hw->dev_spec.ich8lan.eee_lp_ability &
7546 I82579_EEE_1000_SUPPORTED)
7547 lpi_ctrl |= I82579_LPI_CTRL_1000_ENABLE;
7548
7549 retval = e1e_wphy_locked(hw, I82579_LPI_CTRL,
7550 lpi_ctrl);
7551 }
7552 }
7553 hw->phy.ops.release(hw);
7554 }Any use?
Thanks in advance,
A.
#1227 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-04 08:00:38
Hello:
... that warning is not mine.
Did not think so.
I expect that it is from Makefile.
Because: ISO C90, mixed declarations, code, syntax?
that EEE TX LPI TIMER message is actually good.
NULL means nothing active.
I thought the value 00000000 meant the timer was active and at that point in the process had reached a value of nought.
Rather misleading.
... just a debug message ...
... they did not remove yet.
I see ...
Left over from the original primary Intel driver e1000e module code?
Seems very sloppy. 8^/
Right.
If all is well up to now (sort of got the hang of it), booting with e1000e_3.8.7+*.patch 1000-4000 and shutting down in a standard manner, then we just have to wait.
I'll post back as soon as I get something.
Thank you so very much for your help.
Best,
A.
#1228 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-03 21:02:17
Hello:
... another oversight.
None of that.
The only way to avoid it is to do nothing.
Not your case. ;^D
Right.
Here we go ...
groucho@devuan:/$ pushd /usr/src/e1000e-3.8.7
/usr/src/e1000e-3.8.7 /
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch --dry-run -p0 -i /usr/src/e1000e-patch/1001-e1000e_387_param_eee_be_disabled.patch
checking file src/param.c
groucho@devuan:/usr/src/e1000e-3.8.7$No complaints.
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch -p0 -i /usr/src/e1000e-patch/1001-e1000e_387_param_eee_be_disabled.patch
patching file src/param.c
groucho@devuan:/usr/src/e1000e-3.8.7$P1001 done.
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch --dry-run -p0 -i /usr/src/e1000e-patch/1002-e1000e_387_param_eee_debug_messages.patch
checking file src/param.c
groucho@devuan:/usr/src/e1000e-3.8.7$No complaints.
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch -p0 -i /usr/src/e1000e-patch/1002-e1000e_387_param_eee_debug_messages.patch
patching file src/param.c
groucho@devuan:/usr/src/e1000e-3.8.7$ P1002 done.
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch --dry-run -p0 -i /usr/src/e1000e-patch/1003-e1000e_387_shutdown_superfluous_pm_freeze.patch
checking file src/netdev.c
groucho@devuan:/usr/src/e1000e-3.8.7$ No complaints.
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch -p0 -i /usr/src/e1000e-patch/1003-e1000e_387_shutdown_superfluous_pm_freeze.patch
patching file src/netdev.c
groucho@devuan:/usr/src/e1000e-3.8.7$ P1003 done.
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch --dry-run -p0 -i /usr/src/e1000e-patch/1004-e1000e_387_shutdown_debug_messages.patch
checking file src/netdev.c
groucho@devuan:/usr/src/e1000e-3.8.7$ No complaints.
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch -p0 -i /usr/src/e1000e-patch/1004-e1000e_387_shutdown_debug_messages.patch
patching file src/netdev.c
groucho@devuan:/usr/src/e1000e-3.8.7$ P1004 done.
Now we make:
groucho@devuan:/usr/src/e1000e-3.8.7$ cd src
groucho@devuan:/usr/src/e1000e-3.8.7/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.7/src/netdev.o
/usr/src/e1000e-3.8.7/src/netdev.c: In function 'e1000e_pm_freeze':
/usr/src/e1000e-3.8.7/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.7/src/ethtool.o
CC [M] /usr/src/e1000e-3.8.7/src/ich8lan.o
CC [M] /usr/src/e1000e-3.8.7/src/mac.o
CC [M] /usr/src/e1000e-3.8.7/src/nvm.o
CC [M] /usr/src/e1000e-3.8.7/src/phy.o
CC [M] /usr/src/e1000e-3.8.7/src/manage.o
CC [M] /usr/src/e1000e-3.8.7/src/80003es2lan.o
CC [M] /usr/src/e1000e-3.8.7/src/82571.o
CC [M] /usr/src/e1000e-3.8.7/src/param.o
CC [M] /usr/src/e1000e-3.8.7/src/ptp.o
CC [M] /usr/src/e1000e-3.8.7/src/kcompat.o
LD [M] /usr/src/e1000e-3.8.7/src/e1000e.o
Building modules, stage 2.
MODPOST 1 modules
CC /usr/src/e1000e-3.8.7/src/e1000e.mod.o
LD [M] /usr/src/e1000e-3.8.7/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.7/src$ Looks OK:
groucho@devuan:/usr/src/e1000e-3.8.7/src$ sudo modinfo /usr/src/e1000e-3.8.7/src/e1000e.ko
filename: /usr/src/e1000e-3.8.7/src/e1000e.ko
version: 3.8.7-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver
author: Intel Corporation, <linux.nics@intel.com>
srcversion: E009D1772E8A46CD7637A2F
alias: pci:v00008086d00001A1Dsv*sd*bc*sc*i*
--- snip ---
alias: pci:v00008086d0000105Esv*sd*bc*sc*i*
depends:
retpoline: Y
name: e1000e
vermagic: 4.19.0-16-amd64 SMP mod_unload modversions
parm: copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm: TxIntDelay:Transmit Interrupt Delay (array of int)
parm: TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm: RxIntDelay:Receive Interrupt Delay (array of int)
parm: RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm: InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm: IntMode:Interrupt Mode (array of int)
parm: SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm: KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm: CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)
parm: EEE:Enable/disable on parts that support the feature (array of int)
parm: Node:[ROUTING] Node to allocate memory on, default -1 (array of int)
parm: debug:Debug level (0=none,...,16=all) (int)
groucho@devuan:/usr/src/e1000e-3.8.7/src$ Let me know if all this looks right to you.
Edit:
I realised that I had seen this before.
/usr/src/e1000e-3.8.7/src/netdev.c: In function 'e1000e_pm_freeze':
/usr/src/e1000e-3.8.7/src/netdev.c:7413:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
int count = E1000_CHECK_RESET_COUNT;
^~~So I installed the patched module.
groucho@devuan:~$ sudo dmesg | grep e1000e
[ 2.138286] e1000e: loading out-of-tree module taints kernel.
[ 2.138541] e1000e: module verification failed: signature and/or required key missing - tainting kernel
[ 2.193603] e1000e: Intel(R) PRO/1000 Network Driver - 3.8.7-NAPI
[ 2.215556] e1000e: Copyright(c) 1999 - 2020 Intel Corporation.
[ 2.226843] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[ 2.238204] e1000e 0000:00:19.0: PHY Smart Power Down Disabled
[ 2.260496] e1000e 0000:00:19.0: EEE Support was initialized to be enabled
[ 2.271540] e1000e 0000:00:19.0: EEE Support has been reset to be disabled
[ 2.679491] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:14:4f:4a:a2:81
[ 2.679492] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[ 2.679510] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 6, PBA No: FFFFFF-0FF
[ 26.936094] e1000e 0000:00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[ 26.948223] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
groucho@devuan:~$
groucho@devuan:~$ sudo dmesg | grep 00:19.0
[ 1.053337] pci 0000:00:19.0: [8086:10bd] type 00 class 0x020000
[ 1.053353] pci 0000:00:19.0: reg 0x10: [mem 0xf5fc0000-0xf5fdffff]
[ 1.053359] pci 0000:00:19.0: reg 0x14: [mem 0xf5ffe000-0xf5ffefff]
[ 1.053365] pci 0000:00:19.0: reg 0x18: [io 0xac00-0xac1f]
[ 1.053413] pci 0000:00:19.0: PME# supported from D0 D3hot D3cold
[ 2.226843] e1000e 0000:00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
[ 2.238204] e1000e 0000:00:19.0: PHY Smart Power Down Disabled
[ 2.260496] e1000e 0000:00:19.0: EEE Support was initialized to be enabled
[ 2.271540] e1000e 0000:00:19.0: EEE Support has been reset to be disabled
[ 2.679491] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 00:14:4f:4a:a2:81
[ 2.679492] e1000e 0000:00:19.0 eth0: Intel(R) PRO/1000 Network Connection
[ 2.679510] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 6, PBA No: FFFFFF-0FF
[ 26.936094] e1000e 0000:00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
[ 26.948223] e1000e 0000:00:19.0 eth0: 10/100 speed: disabling TSO
groucho@devuan:~$And from the video grab on shutdown:
I guess we now wait ....
Thanks in advance,
A.
#1229 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-03 12:54:30
Hello:
... added the numbering prefix to the patches.
That is the order to apply.
Right.
There's been a hitch.
Please tell me what/if I've missed something:
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch --dry-run -p0 -i /usr/src/e1000e-patch/0001-e1000e_387_param_eee_be_disabled.patch
[sudo] password for groucho:
checking file src/param.cPatch 0001 went well, so I ran it:
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch -p0 -i /usr/src/e1000e-patch/0001-e1000e_387_param_eee_be_disabled.patch
patching file src/param.c
groucho@devuan:/usr/src/e1000e-3.8.7$ No complaints.
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch --dry-run -p0 -i /usr/src/e1000e-patch/0002-e1000e_387_netdev_shutdown_debug_messages_v3.patch
checking file src/netdev.c
groucho@devuan:/usr/src/e1000e-3.8.7$ Patch 0002 went well, so I ran it:
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch -p0 -i /usr/src/e1000e-patch/0002-e1000e_387_netdev_shutdown_debug_messages_v3.patch
patching file src/netdev.c
groucho@devuan:/usr/src/e1000e-3.8.7$ No complaints.
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch --dry-run -p0 -i /usr/src/e1000e-patch/0003-e1000e_387_netdev_shutdown_no_pm_freeze.patch
checking file src/netdev.c
groucho@devuan:/usr/src/e1000e-3.8.7$Patch 0003 went well, so I ran it:
groucho@devuan:/usr/src/e1000e-3.8.7$ sudo patch -p0 -i /usr/src/e1000e-patch/0003-e1000e_387_netdev_shutdown_no_pm_freeze.patch
patching file src/netdev.c
groucho@devuan:/usr/src/e1000e-3.8.7$ No complaints.
I then ran make and got this output:
groucho@devuan:/usr/src/e1000e-3.8.7$ cd src
groucho@devuan:/usr/src/e1000e-3.8.7/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.7/src/netdev.o
/usr/src/e1000e-3.8.7/src/netdev.c: In function 'e1000e_pm_freeze':
/usr/src/e1000e-3.8.7/src/netdev.c:7413:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
int count = E1000_CHECK_RESET_COUNT;
^~~
/usr/src/e1000e-3.8.7/src/netdev.c: In function 'e1000_remove':
/usr/src/e1000e-3.8.7/src/netdev.c:8852:18: error: 'pdev' redeclared as different kind of symbol
struct pci_dev *pdev = adapter->pdev;
^~~~
/usr/src/e1000e-3.8.7/src/netdev.c:8847:42: note: previous definition of 'pdev' was here
static void e1000_remove(struct pci_dev *pdev)
~~~~~~~~~~~~~~~~^~~~
make[3]: *** [/usr/src/linux-headers-4.19.0-16-common/scripts/Makefile.build:309: /usr/src/e1000e-3.8.7/src/netdev.o] Error 1
make[2]: *** [/usr/src/linux-headers-4.19.0-16-common/Makefile:1562: _module_/usr/src/e1000e-3.8.7/src] Error 2
make[2]: Leaving directory '/usr/src/linux-headers-4.19.0-16-amd64'
make[1]: *** [Makefile:146: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-16-common'
make: *** [Makefile:73: default] Error 2
groucho@devuan:/usr/src/e1000e-3.8.7/src$ I think I got it right this time.
Thanks in advance,
A.
#1230 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-02 22:52:08
Hello:
... faster than for my own good.
Whatever time zone that is ... 8^D
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
Right ...
Sorry if I seem dumb:
These three patches are to be applied, successively one after the other to the original v. 3.8.7 downloaded from Intel.
Right?
So that ...
3.8.7 + P_param => 3.8.7p
3.8.7p + P_netdev => 3.8.7q
3.8.7q + P_freeze => 3.8.7r
Is this correct or have I missed something?
... reminder for me:
- Patch 0001 needs default disabled globally, default enabled for EEE featured devices.
- In the end, remove all debug messages again ...
Got it.
Thanks in advance,
A.
#1231 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-02 22:14:52
Hello:
... overlooked one function that is called in the shutdown process... in src/netdev.c.
Well ...
Looks fine to me. 8^)
... these functions involved: e1000e_close (netdev callback seen early in your screen capture), e1000_remove and e1000_shutdown (pci device callbacks).
OK.
... 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.
So ...
I see you're still discovering e1000e fun.
... do a V3 for debug messages, tomorrow.
Whenever you can.
Thanks in advance,
Best.
A.
#1232 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-02 21:33:00
Hello:
... not happening always ...
No.
I have never seen it happen twice in a row.
And like I mentioned, I have gone for well over a fortnight without one.
... most likely an issue with concurrent access to one resource.
I see.
In this case the netdev resource on shutdown.
If you say so.
We'll see when the next bad shutdown comes along.
... run a newer Kernel >= 5.5.0.
Just found: https://www.spinics.net/lists/stable/msg443520.html
Another netdev resource locking issue fixed.
Well ...
That's interesting.
I wonder if these patches will get backported to Beowulf?
BTW: I just noticed that this thread has had an unusual following.
Thank you very much for your help (and patience) in getting this sorted out.
Much obliged.
Hopefully, the next bad shutdown will give you the clues you are looking for to write a definite patch.
And maybe send it up for it to become e1000e v3.8.8. 8^)
I'll report results the moment I get them.
Best,
A.
#1233 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-02 19:06:51
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.
#1234 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-02 11:38:31
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.
#1235 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-01 22:16:55
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.
#1236 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-05-01 11:39:01
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.
#1237 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-30 22:01:22
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.
#1238 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-30 21:10:41
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
$ popdHmm ...
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.
#1239 Re: Devuan » As Debian 11 moves closer to Devuan. Is there any reason to stay on De » 2021-04-30 19:03:57
Hello:
... Debian's inclusion of alternate inits appears to be more window dressing than a viable and well-supported solution ...
Indeed.
https://forums.theregister.com/forum/al … e_spotted/
The association with systemd, a widely used system and session manager for Linux, may have been chosen by the malware authors to make the malicious code less likely to be noticed by administrators reviewing logs and process lists.
May?
systemd is the ideal vector for all sorts of nastry stuff, it is just the LInux version of the registry in MSOSs
This new discovery is just a trial run, the next one or the one after that will probably not be noticed.
I can't believe that this can even be considered a subject to be discussed.
But then that's just my $0.02.
A.
#1240 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-30 16:22:56
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.
#1241 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-30 11:34:41
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.cv2 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.7qIt 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 !
#1242 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-29 22:32:01
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.
#1243 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-29 22:11:01
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.
#1244 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-29 21:22:12
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.
#1245 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-29 20:37:14
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.
#1246 Re: Installation » [SOLVED] Piper and ratbag » 2021-04-29 20:15:00
Hello:
... just need to target backports explicitly so that the correct dependency is selected:
# apt install piper/beowulf-backports
I see ...
I would have though that apt would have done it.
It is quite clear that apt knows that the dependency is ratbagd >=0.13
... aptitude would have probably figured it out for you
I use aptitude for its why and why-not.
And synaptic for its search and residual functions.
But I like apt best.
Thanks a lot for making sense of this for me.
Best,
A.
Edit:
Unfortunately, Piper (piper/stable-backports 0.4-1~bpo10+1) does not support the Logitech M575.
It's really up to ratbagd (0.15-1~bpo10+1), as it seems that Piper is the front end.
Notwithstanding, parameters (in Xfce) can be adjusted via Applications -> Settings -> Mouse and Touchpad.
It recognises the device as Logitech ERGO M575 without any user intervention.
.
#1247 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-29 19:53:32
Hello:
... that stray EEE TX LPI TIMER: ... comes from function e1000e_flush_lpic in src/netdev.c and seems to be a harmless print.
Hmmm ...
The only harmless code is the well written code.
Who dares to care?!
Evidently it's only us (?)
Certainly not the hacks at Intel
The more fun I see in the function e1000e_pm_freeze.
Both functions are called last in shutdown/reboot.
Ahh ...
Then those are the ones screwing up my shutdowns.
... discussion about the sequence: https://netdev.vger.kernel.narkive.com/ … esume-flow
Can't make heads or tails from it.
I only know that my rig does not have any suspends enabled and the NIC does not support EEE of any sort.
present = netif_device_present(netdev); netif_device_detach(netdev); if (present && netif_running(netdev)) { int count = E1000_CHECK_RESET_COUNT; while (test_bit(__E1000_RESETTING, &adapter->state) && count--) usleep_range(10000, 11000); WARN_ON(test_bit(__E1000_RESETTING, &adapter->state)); /* Quiesce the device without resetting the hardware */ e1000e_down(adapter, false); e1000_free_irq(adapter); }
It seems to me that whoever slapped together the driver did not take into account that a great deal of the code was not to be run if the part was not EEE able or if there were no S states besides S0, S1 or S5 in play.
... should that detach not be within the if-block?
It seems you just have to wait for the counter+sleep to finish?
Seems that it is what the interruped shutdown is doing ...
But there's no sleep to finish although the counter (LX LPI Timer) is at 00000000.
It's a wonder that the damned driver works at all ...
Thanks for your input.
Best,
A.
#1248 Re: Installation » [SOLVED] Piper and ratbag » 2021-04-29 19:37:06
Can we see ...
groucho@devuan:~$ apt policy
Package files:
100 /var/lib/dpkg/status
release a=now
100 http://deb.devuan.org/merged beowulf-backports/main i386 Packages
release v=3.0.0,o=Devuan Backports,a=stable-backports,n=beowulf-backports,l=Devuan Backports,c=main,b=i386
origin deb.devuan.org
100 http://deb.devuan.org/merged beowulf-backports/main amd64 Packages
release v=3.0.0,o=Devuan Backports,a=stable-backports,n=beowulf-backports,l=Devuan Backports,c=main,b=amd64
origin deb.devuan.org
100 http://deb.devuan.org/merged beowulf-backports/contrib i386 Packages
release v=3.0.0,o=Devuan Backports,a=stable-backports,n=beowulf-backports,l=Devuan Backports,c=contrib,b=i386
origin deb.devuan.org
100 http://deb.devuan.org/merged beowulf-backports/contrib amd64 Packages
release v=3.0.0,o=Devuan Backports,a=stable-backports,n=beowulf-backports,l=Devuan Backports,c=contrib,b=amd64
origin deb.devuan.org
100 http://deb.devuan.org/merged beowulf-backports/non-free i386 Packages
release v=3.0.0,o=Devuan Backports,a=stable-backports,n=beowulf-backports,l=Devuan Backports,c=non-free,b=i386
origin deb.devuan.org
100 http://deb.devuan.org/merged beowulf-backports/non-free amd64 Packages
release v=3.0.0,o=Devuan Backports,a=stable-backports,n=beowulf-backports,l=Devuan Backports,c=non-free,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf-updates/main i386 Packages
release v=3.0.0,o=Devuan,a=stable-updates,n=beowulf-updates,l=Devuan,c=main,b=i386
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf-updates/main amd64 Packages
release v=3.0.0,o=Devuan,a=stable-updates,n=beowulf-updates,l=Devuan,c=main,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf-security/non-free i386 Packages
release v=3.0.0,o=Devuan,a=stable-security,n=beowulf-security,l=Devuan-Security,c=non-free,b=i386
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf-security/non-free amd64 Packages
release v=3.0.0,o=Devuan,a=stable-security,n=beowulf-security,l=Devuan-Security,c=non-free,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf-security/main i386 Packages
release v=3.0.0,o=Devuan,a=stable-security,n=beowulf-security,l=Devuan-Security,c=main,b=i386
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf-security/main amd64 Packages
release v=3.0.0,o=Devuan,a=stable-security,n=beowulf-security,l=Devuan-Security,c=main,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf/non-free i386 Packages
release v=3.0,o=Devuan,a=stable,n=beowulf,l=Devuan,c=non-free,b=i386
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf/non-free amd64 Packages
release v=3.0,o=Devuan,a=stable,n=beowulf,l=Devuan,c=non-free,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf/contrib i386 Packages
release v=3.0,o=Devuan,a=stable,n=beowulf,l=Devuan,c=contrib,b=i386
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf/contrib amd64 Packages
release v=3.0,o=Devuan,a=stable,n=beowulf,l=Devuan,c=contrib,b=amd64
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf/main i386 Packages
release v=3.0,o=Devuan,a=stable,n=beowulf,l=Devuan,c=main,b=i386
origin deb.devuan.org
500 http://deb.devuan.org/merged beowulf/main amd64 Packages
release v=3.0,o=Devuan,a=stable,n=beowulf,l=Devuan,c=main,b=amd64
origin deb.devuan.org
Pinned packages:
groucho@devuan:~$ groucho@devuan:~$ apt policy piper
piper:
Installed: (none)
Candidate: 0.4-1~bpo10+1
Version table:
0.4-1~bpo10+1 100
100 http://deb.devuan.org/merged beowulf-backports/main amd64 Packages
100 http://deb.devuan.org/merged beowulf-backports/main i386 Packages
groucho@devuan:~$ groucho@devuan:~$ apt install -s piper/stable-backports
NOTE: This is only a simulation!
apt needs root privileges for real execution.
Keep also in mind that locking is deactivated,
so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '0.4-1~bpo10+1' (Devuan Backports:3.0.0/stable-backports [all]) for 'piper'
Selected version '0.15-1~bpo10+1' (Devuan Backports:3.0.0/stable-backports [amd64]) for 'ratbagd' because of 'piper'
The following additional packages will be installed:
gir1.2-rsvg-2.0 python3-evdev ratbagd
Suggested packages:
python-evdev-doc
The following NEW packages will be installed:
gir1.2-rsvg-2.0 piper python3-evdev ratbagd
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Inst gir1.2-rsvg-2.0 (2.44.10-2.1 Devuan:3.0/stable [amd64])
Inst python3-evdev (1.1.2+dfsg-1+b10 Devuan:3.0/stable [amd64])
Inst ratbagd (0.15-1~bpo10+1 Devuan Backports:3.0.0/stable-backports [amd64])
Inst piper (0.4-1~bpo10+1 Devuan Backports:3.0.0/stable-backports [all])
Conf gir1.2-rsvg-2.0 (2.44.10-2.1 Devuan:3.0/stable [amd64])
Conf python3-evdev (1.1.2+dfsg-1+b10 Devuan:3.0/stable [amd64])
Conf ratbagd (0.15-1~bpo10+1 Devuan Backports:3.0.0/stable-backports [amd64])
Conf piper (0.4-1~bpo10+1 Devuan Backports:3.0.0/stable-backports [all])
groucho@devuan:~$ Thanks for your input.
Best,
A.
#1249 Re: Installation » Linux e1000e module removal and e1000e EEE timer - Part II » 2021-04-29 19:13:41
Hello:
... these guys ...
Hmm ....
No idea.
I cut my rock teeth on Beatles, CSN&Y, S&G, Joe C., J.Joplin, Stones, BS&T ...
My first album was Abbey Road, hot off the press.
Not that there's anything wrong with boobies. 8^D
Altoid wrote:... module has EEE set to Enabled by default on all the devices it is used on, irrespective of the hardware supporting EEE.
Yes, that is the fun - in context to the above ...
Ahh ...
I see.
... can we be sure that some routine/code within the module is not broadcasting something EEEish and causing the freeze?
eg: the autonegotiation part of the code that is needed for EEE to work.
Make sense?
Yes ...
I thought as much.
Happy to know I was not too far off the mark.
... looking for eee and lpi used without the catch of if (!eee_disable) ....
Let me know if you need me to help with some digging.
Thanks a lot for your input.
Best,
A.
#1250 Re: Installation » [SOLVED] Piper and ratbag » 2021-04-29 19:01:50
Hello:
... where did you attempt to obtain the piper package?
Piper 0.1-1-bpo+1 (stable-backports)
0.15-1-bpo10+1 (stable-backports)
and
0.9.905-1 (stable)
... but for some reason apt pulls in 0.9.905-1 (stable) when the dependency is the higher version.
Must be doing something wrong. (?)
Thanks for your input.
Best,
A.
Board footer
