A lot of people just use the deafult power-profiles-daemon however it lacks a lot of optimization options. It works reasonably well, however in anything more complicated than a lone laptop setup it tends ot quickly fail miserably. Another issue I have with it is that instead of trying to work with other projects it decided to go the Gnome does what Gnome does route. The systemd unit conflicts with every other power saving tool, and at one point distros were packaging it as a dependency. Thankfully many have rolled that back making it optional. So you can now remove power-profiles-daemon rather than masking it at least on Fedora.
Interestingly, I did not know about power-profiles-daemon at allā¦ thereās a Debian package, but I donāt have it installedā¦ another thing to mess with I guess?
Also, I have just tested with just:
USB_DENYLIST="0bda:8156"
ā¦ and notUSB_AUTOSUSPEND=0 in my tlp.conf and it seems the NIC still goes to sleep the wrong way.
So Iām not sure thatās a valid workaround hereā¦ which is unfortunate because I now have the distinct feeling that disabling autosuspend across all USB hurts my suspend performance quite a bitā¦ Still needs to do benchmarks on that.
Update: seems like USB_DENYLISTwith the kernel commandline usbcore.quirks setting does work correctly, which is encouraging.
Iāve been afflicted by this problem too and found this thread while searching the forum for ideas (in parallel with an open support ticket). The reported behaviour of the NICās LEDs struck me as significantly similar to my own observations.
I understand that the subject is closed as solved however a new reader might not appreciate that several different solutions are canvassed and that they have each had different outcomes. This suggests that there are unidentified factors peculiar to each manifestation of the fault and that there is no universal solution.
In my particular caseāLinux Mint Cinnamon 21.1 with kernels in the 5.15 seriesāthe installation of TLP renders the NIC unusable. Using the NIC with vanilla Mint 21.1 (i.e. without TLP) just works. Battery performance might be sub-optimal in the latter case (which is why I installed TLP in the first place).
I found that it was not necessary to add usbcore.quirks to the commandline of kernel 5.15.0-58-generic.
I trialed both of the suggested changes to /etc/tlp.conf; both allowed the NIC to function correctly. Ultimately I decided to use the USB_DENYLIST because it restricts the change in TLPās behaviour to a single device.
6: enp0s13f0u3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 9c:bf:0d:00:19:38 brd ff:ff:ff:ff:ff:ff
sudo lsusb:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 002: ID 27c6:609c Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
Bus 003 Device 003: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G LAN
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I have not installed powertop, tried installing r8152-dkms from the AUR. The LEDs on the ethernet card are permanently on with an occasional short blink. I also tried other USB-C slots. At boot there is some more flashing going on, but after a few seconds, the LEDs are as described almost permanently on. I confirmed that the cable + router is working, as other devices can connect with it flawlessly.
When I was investigating the NICās apparent failure I booted a live distro to confirm that the NIC worked with an out-of-the-box configuration. I used both Ubuntu 22.04.1 LTS and Linux Mint 21.1 ISOs with success. Might be worth a try to eliminate module failure.
So in a live Arch (2022.10.01) or Manjaro KDE (21.3.7) iso everything is working fine and I am also receiving the desired speeds.
However in my current arch installation it is not working, despite all mentioned solutions. Although I could reinstall arch and thus avoid the problem, I would rather not prefer to as I donāt want to reconfigure everything and maybe other people will encounter the same issue.
Is there anymore detailed information I can give you?
Honestly, with rolling distros and no snapshots to roll back to, youāre absolutely best off backing up your home data, fresh install, then immediately setup a rollback option. Because itās Arch and there could be endless factors, itās a of a time vacuum.
If we know this is working on Live ISOs, then Iād start fresh, then set up that restore option. Rolling distros will absolutely break stuff occasionally. Wish I had a better solution. This is what I would do on my own system.
Well, I have BTRFS snapshots as well as regular backups with borg, but as I only recently acquired the ethernet card and thus have no clue, when the system has gone bad, I unfortunately canāt just set it back.
I will further investigate this issue, as ethernet connectivity isnāt a top priority for me. In addition, my system does not have too many crazy customizations, no custom kernel or kernel modules etc. This will make it a bit easier.
If you have any tips on how to approach this issue, maybe useful commands, debugging tools, I would be very grateful.
In the meantime, we can look for errors similar to this in the journalctl:
usb 2-3: USB disconnect, device number 74 xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. cdc_ncm 2-3:2.0 enx9cbf0d000e38: unregister 'cdc_ncm' usb-0000:00:0d.0-3, CDC NCM xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
If youāre seeing them, post them back, we may have a bad card. But we can only speculate when weāre not able to compare behavior with a new install. At the very least, Iād compare behavior between your install and that of a Live ISO of Ubuntu or Fedora. As indicated, if itās works there, we may need to consider an update did something creative.
If it also fails there, then we likely have a hardware (expansion card) issue. Itās a bit of A and B testing.
As there have been many posts talking about each person method to fix the issue, I wanted to stress again the suggestions from @Matt_Hartley with the LIVE ISO.
I had a situation which caused my current install to have an issue after Linux kernel 6.1.x was installed on a routine system update. To capture the state of the OS (and its install), I booted my laptop from clonezillaās LIVE option. The Framework Network Expansion Card worked without issue allowing me to backup/clone the NVMe to a Proxmox Virtual Guest. In the end I got my laptop back to a working state by cleaning up (removing) all the old kernel versions I had within /boot (that were installed/upgrade from last Summer when I purchased the laptop).
As a number of us purchase the laptop to run Linux, the unit was called DIY.
There are options to help preserve your personal settings (or home directory) using techniques such as RSYNC.
If you have a limited number of applications your running (or are more methodological with that you load on your laptop), then there are options such as bash script or anisble to rebuilt the laptop and restore the files saved via RSYNC.
Just wanted to chip in on here, wonāt be of any use but just wanted to say that this seems to be a common thing with realtek based Ethernet devices.
Is there a possibility Framework will use a non-Realtek Ethernet chipset for future expansion cards?
It seems Realtek compatibility with linux systems is lacking severely. I had no end of issues with the 8152/53 chipset doing the same thing under Linux. Ditched my Anker USB hub, and switched to an Amazon basics hub, and it works without issue.
The Amazon hub is using an AX88179A. Pop OS detects even without a network connection whereas with the Realtek based one, it wouldnāt add it until it detected a connection through it.
I can also echo that the card did not work on my Mint box, even at the most current versions. However, it did run normally on the ISO and with a fresh install. Not ideal, but probably less headache then the other route.
Anytime I have hardware run great in an live USB and fail on the installed distro, something differs. 99% of the time, TLP needs to be configured if installed (and some distros have it pre-installed).
