That's why mainline r8169 disables ASPM completely. Users still have the option
to re-enable individual ASPM states per sysfs, but that's at own risk.
It's not known why and which combinations of board chipset / BIOS / NIC chipset
version have an issue when ASPM L1 is enabled. All three component
Blacklist for what? ASPM L1? In mainline this wouldn't be needed because
L1 is disabled per default. Downstream this could be an option, of
course.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1874464
For mainline that's too risky, because there has been a number of
different symptoms of ASPM-related problems. And it would take time to
assemble a blacklist, in the meantime users would complain about network
problems.
--
You received this bug notification because you are a member of Ubuntu
Bugs
ASPM issues come with quite different symptoms. Sometimes there's just a
number of rx_missed errors and performance is significantly reduced, w/o
tx timeout. Therefore at least in mainline I'd like to keep ASPM
disabled per default. But every user or distro can use sysfs to enable
selected ASPM sta
Well, reason could by anything. Most users of this chip version don't
have this problem, so it may be the BIOS. Is known meanwhile whether any
(mainline) kernel version is fine on this system (so that issue can be
bisected)? Also interesting would be whether the issue happens with
r8168 too.
--
Y
This sounds more like a platform issue (especially as WiFi seems to be affected
too). Few months ago we had something similiar and it turned out to be a
problem with Intel PCI bridge code.
The only way I see for now is to find a working version and then bisect.
--
You received this bug notifica
Few chip versions of RTL810xE missed a dedicated PHY driver. This was fixed in
mainline in 5.4.32.
Please update your kernel.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1873512
Title:
Ubuntu 20.
Main reason of missed rx packets is ASPM issues. Helpful would be the
output of "lspci -vv" to see whether the ASPM L1 sub-states are enabled.
What you can also try:
- Change ASPM settings in BIOS
- Comment out the following in rtl_hw_start_8168h_1:
rtl_hw_aspm_clkreq_enable(tp, true);
- Play wi
The "lspci -vv" output misses the relevant part. Please execute the command as
root.
The firmware hasn't changed for years, so this should not be the reason.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/b
L1SubCtl1: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1-
This means ASPM sub-state 1.2 is enabled. This should not be the case
because the driver disables ASPM at probe time. Also there's no message
in dmesg that ASPM can't be controlled by OS. So this might be a BIOS
bug. This could also explai
In addition you can try to set kernel command line parameter pcie_aspm=off.
Or set pcie_aspm.policy=performance.
In general it's a tradeoff: Older kernels didn't allow to enable ASPM at
all, resulting in less battery life on notebooks. Newer kernels disable
ASPM per default, but allow to re-enable
Also before the generic PHY driver was loaded as fallback, the actual PHY
driver would be RTL8211B.
Did you check what the error message says? Do you have r8169.ko and/or
realtek.ko in your initramfs?
And to be sure: In the good case, please report the PHY ID (search for phy_id
under /sys).
--
Thanks, this phy_id value is not a valid Realtek PHY ID. You seem to be
affected by a known BIOS bug (few Gigabyte boards from 2009/2010 seem to be
affected).
See here: https://bugzilla.kernel.org/show_bug.cgi?id=202275#c7
Please try to enable "LAN Boot ROM" option in BIOS.
** Bug watch added: L
Seems your BIOS was never updated, see
https://www.gigabyte.com/Motherboard/GA-890GPA-UD3H-rev-20/support
#support-dl-bios. Versions FD and FE include some LAN fixes. Best update
to latest version FF and re-test.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Typically it helps to do a rmmod r8169 + modprobe r8169 to work around the BIOS
bug.
Maybe also a PHY soft reset helps to make the PHY behave sanely again.
Can you test whether the following fixes the issue for you?
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/re
Interesting. Did you switch off the machine after flashing the updated
BIOS (and before re-testing) or did you just reboot? In the latter case
this may be an explanation. Often a BIOS initializes certain things on
cold boot only.
--
You received this bug notification because you are a member of U
Changed status to invalid, because issue was caused by a BIOS bug.
** Changed in: linux-signed (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876593
Title:
Et
Apart from switching to a more up-to-date API after this commit MSI-X
will be used if available. Maybe your system has a problem with MSI-X.
If you keep the commit and just do the following change, does it fix the
issue?
Replace
flags = PCI_IRQ_ALL_TYPES;
with
flags = PCI_IRQ_LEGACY | PCI_IRQ_MSI;
One more hint: I found few reports where people had problems
(independent of what is being discussed here) with MSI-X when VT-d is
disabled in the BIOS. Could you check this as well?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
http
Good that it's fixed for you. Indeed your BIOS seems to be broken with
regard to MSI-X. According to the vendor part of the MAC address your
mini PC is some no-name China product?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
Whether other systems suffer from the same MSI-X incompatability we'll
know only once I get more such bug reports. So far your report is the
only one.
You said if MSI-X is enabled it doesn't even boot. Any error message or
does it just silently stop?
And no, I'm not aware of any way to disable MS
@Steve, there's some resistance amongst kernel maintainers against additional
module parameters. Each new parameter increases complexity and makes
maintenance harder.
Most likely it would result in a NAK when trying to fix an issue with one
broken exotic (sorry..) system in the kernel, especiall
22 matches
Mail list logo
