On 8/21/2024 8:09 AM, Jiri Slaby wrote:
On 20. 08. 24, 23:30, Bjorn Helgaas wrote:
On Tue, Aug 20, 2024 at 11:13:54PM +0200, Petr Valenta wrote:
Dne 20. 08. 24 v 20:09 Bjorn Helgaas napsal(a):
On Mon, Aug 19, 2024 at 07:23:42AM +0200, Jiri Slaby wrote:
On 19. 08. 24, 6:50, Jiri Slaby wrote:
CC e1000e guys + Jesse (due to 75a3f93b5383) + Bjorn (due to
b2c289415b2b)
Bjorn,
I am confused by these changes:
==========================================
@@ -291,16 +288,13 @@ static int e1000_set_link_ksettings(struct
net_device
*net
dev,
* duplex is forced.
*/
if (cmd->base.eth_tp_mdix_ctrl) {
- if (hw->phy.media_type != e1000_media_type_copper) {
- ret_val = -EOPNOTSUPP;
- goto out;
- }
+ if (hw->phy.media_type != e1000_media_type_copper)
+ return -EOPNOTSUPP;
if ((cmd->base.eth_tp_mdix_ctrl !=
ETH_TP_MDI_AUTO) &&
(cmd->base.autoneg != AUTONEG_ENABLE)) {
e_err("forcing MDI/MDI-X state is not
supported when
lin
k speed and/or duplex are forced\n");
- ret_val = -EINVAL;
- goto out;
+ return -EINVAL;
}
}
@@ -347,7 +341,6 @@ static int e1000_set_link_ksettings(struct
net_device
*netde
v,
}
out:
- pm_runtime_put_sync(netdev->dev.parent);
clear_bit(__E1000_RESETTING, &adapter->state);
return ret_val;
}
==========================================
So no more clear_bit(__E1000_RESETTING in the above fail paths. Is
that
intentional?
Not intentional. Petr, do you have the ability to test the patch
below? I'm not sure it's the correct fix, but it reverts the pieces
of b2c289415b2b that Jiri pointed out.
I tested the patch below but it didn't help. After the first boot
with new
kernel it looked promising as the irq storm only appeared for a few
seconds,
but with subsequent reboots it was the same as without the patch.
Thank you very much for testing that!
To be sure, I also send the md5sum of ethtool.c after applying the
patch:
a25c003257538f16994b4d7c4260e894 ethtool.c
Thanks, that matches what I get when applying the patch on v6.10.
I'm at a loss. You could try reverting the entire b2c289415b2b commit
(patch for that is below).
FWIW he already tested with b2c289415b2b reverted (I provided him with
a built kernel). It behaves the same. So you are not the breaker.
If that doesn't help, I guess you could try reverting the other
commits Jiri mentioned:
76a0a3f9cc2f e1000e: fix force smbus during suspend flow
c93a6f62cb1b e1000e: Fix S0ix residency on corporate systems
bfd546a552e1 e1000e: move force SMBUS near the end of enable_ulp
function
6918107e2540 net: e1000e & ixgbe: Remove PCI_HEADER_TYPE_MFD
duplicates
1eb2cded45b3 net: annotate writes on dev->mtu from ndo_change_mtu()
b2c289415b2b e1000e: Remove redundant runtime resume for ethtool_ops
75a3f93b5383 net: intel: implement modern PM ops declarations
If you do this, I would revert 76a0a3f9cc2f, test, then revert
c93a6f62cb1b in addition, test, then revert bfd546a552e1 in addition,
etc.
Or perhaps easier to do:
git bisect v6.10 v6.9 -- drivers/net/ethernet/intel/e1000e/
directly. But that assumes one of the above commits broke it. If they
did not, as a last resort, you can still do full bisect (without the
"-- drivers" part).
I would take v6.10 suses config.
Would boot 6.10.
do lsmod > /tmp/lsmod
make LSMOD=/tmp/lsmod localyesconfig
make bzImage
and use that bzImage.
Note that graphics, wireless and other stuff will be defunct unless
you build in firmwares for them (EXTRA_FIRMWARE config). Alternatively
use localmodconfig and build and install also modules (now limited to
your machine).
thanks,
From all the data in the Suse Bugzilla I understood that the issue
happens with a cable disconnected.
Does it reproduce with a connected cable?
Also, I suspect that it might be related to wake up interrupts that the
I219 device gets which might cause the IRQ storm.
I would like to ask you to enable the debug prints in the e1000e driver
and share the dmesg log. I would like to see if we can get the values of
WUFC and WUS on on resume.
For getting these values please comment out the following in
__e1000_resume function in netdev.c file:
/* report the system wakeup cause from S3/S4 */
// if (adapter->flags2 & FLAG2_HAS_PHY_WAKEUP) {
u16 phy_data;
e1e_rphy(&adapter->hw, BM_WUS, &phy_data);
if (phy_data) {
e_info("PHY Wakeup cause - %s\n",
phy_data & E1000_WUS_EX ? "Unicast Packet" :
phy_data & E1000_WUS_MC ? "Multicast
Packet" :
phy_data & E1000_WUS_BC ? "Broadcast
Packet" :
phy_data & E1000_WUS_MAG ? "Magic Packet" :
phy_data & E1000_WUS_LNKC ?
"Link Status Change" : "other");
}
e1e_wphy(&adapter->hw, BM_WUS, ~0);
// } else {
u32 wus = er32(WUS);
if (wus) {
e_info("MAC Wakeup cause - %s\n",
wus & E1000_WUS_EX ? "Unicast Packet" :
wus & E1000_WUS_MC ? "Multicast Packet" :
wus & E1000_WUS_BC ? "Broadcast Packet" :
wus & E1000_WUS_MAG ? "Magic Packet" :
wus & E1000_WUS_LNKC ? "Link Status
Change" :
"other");
// }
ew32(WUS, ~0);
To enable the debug prints you can run:
echo "module e1000e +p" | sudo tee /sys/kernel/debug/dynamic_debug/control
