Only one is necessary. USB_DENYLIST just directs it to a single item. Whereas USB_AUTOSUSPEND is global.
1 Like
thank you everybody. now it works. tlp and ethernet. what a journy. i was confused because everything has a #. so nothing on the conf file is being working. have a lot to learn. i am suprised that i was the first one with a post about that. since the ethernet card is available for some time and tlp seems to be a standard installation.
2 Likes
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.
Happy it worked out for you.
3 Likes
Absolutely correct, great response.
1 Like
Late reply here, but @anarcat 's fix above with powertop worked for me. (Ethernet expansion card is not connecting - #11 by anarcat)
Thanks a ton for the help!
2 Likes
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 not USB_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_DENYLIST with the kernel commandline usbcore.quirks setting does work correctly, which is encouraging.
1 Like
the following worked for me too
- modify
/etc/default/grub
# GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX_DEFAULT="usbcore.quirks=0bda:8156:k quiet splash"
- modify
/etc/tlp.conf
#USB_DENYLIST="1111:2222 3333:4444"
USB_DENYLIST="0bda:8156"
-
run
sudo update-grub -
reboot
haven’t tried any of the other suggestions. this is on Ubuntu 22.04.1 LTS
1 Like
Two users here reporting this solved. Marking solved. If unsolved for anyone else, feel free to share your findings.
1 Like
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.
Dino
Appreciate the feedback. Thanks for this. 
Hi,
unfortunately the Ethernet card is still not working for me. Here is what I did/what my setup is:
Output from uname
Linux DN-Laptop 6.1.11-arch1-1
/etc/default/grub:
# GRUB boot loader configuration
GRUB_DEFAULT=0
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="usbcore.quirks=0bda:8156:k quiet splash mem_sleep_default=deep"
GRUB_CMDLINE_LINUX="rootflags=subvol=/@ rootfstype=btrfs"
ip addr show:
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
Settings from TLP-UI:
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.
Any help appreciated
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.
Dino
Yes, this is the best course of action.
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.
1 Like
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.
hope this helps.
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.
So if the errors I indicated above are present, it’s a bad card. If not, barring regressions, it should work just fine.
1 Like