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).
Found a new interesting issue. Haven’t spent the time reproducing it thoroughly to confirm, but:
Linux Mint, ethernet port + wifi
-Pressed the airplane mode button, deactivating bluetooth and wifi
-Returning from other activities, pressing airplane mode would NOT return wifi, including through reboot/shut down
-The solution was to do a hard shut down, remove the ethernet port, and boot up again. Wifi would then resume normally.
While wifi was down, it was not listed on rfkill or iwconfig. However it DID appear on lspci.
I’ve not spent time dissecting it, but if you hit a similar issue of the wifi not being visible as an option after airplane mode, see if removing the ethernet card and a hard shut down (not reboot) resolves it.
This is Linux Mint, so your mileage may vary as this is a community support distro with limited testing done with it.
If a wireless device is showing up in lspci, but not working otherwise or being blocked, it’s worth checking the module status.
You indicated pressing Airplane mode, are you using the keyboard key? If so, I assume you also didn’t have success with turning on or off the network settings themselves?
Assuming it’s one our provide Intel cards:
Is the module loaded when this is happening? lsmod | grep iwlwifi
If it’s not, load it: sudo modprobe iwlwifi
Then check again: lsmod | grep iwlwifi
If this still doesn’t work, check the logs:
sudo dmesg | grep iwlwifi
Additional tools can be found here that works for Ubuntu and should also work with Mint:
Hi @Matt_Hartley
I stumbled upon this post when diagnosing Ethernet troubles of my own. I am running NixOs and my issues seem very similar to the others in this thread; The ethernet will work for a few seconds to half a minute, then shut down then restart ad infinitum.
In my case, however, I am not running TLP. My system uses power-profiles-daemon. NixOs has a hardware specification for my laptop that also includes udev rules for the ethernet card:
I have tried turning off the power management by setting power/autosuspend=“-1” and by setting power/control=“on”, neither of which solved my problem.
I tried removing power-profiles-daemon from my system and installing TLP to do power management and then setting USB_DENYLIST, however I did not manage to get the card working with any of these potential solutions.
Finally, I tested the card on both Fedora and Ubuntu live CDs and the problem persists there as well.
On Ubuntu I get the following error in journalctl:
Apr 05 05:54:43 ubuntu kernel: usb 2-3: USB disconnect, device number 6
Apr 05 05:54:43 ubuntu kernel: xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep s>
Apr 05 05:54:43 ubuntu kernel: cdc_ncm 2-3:2.0 enx9cbf0d001462: unregister ‘cdc_ncm’ usb-0000:00:0d.0-3, CDC NCM
Apr 05 05:54:43 ubuntu kernel: xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep s>
Apr 05 05:54:43 ubuntu kernel: xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep s>
On NixOs I get a similar message:
apr 05 08:01:27 D-135 kernel: usb 4-3: USB disconnect, device number 3
apr 05 08:01:27 D-135 kernel: xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
apr 05 08:01:27 D-135 kernel: cdc_ncm 4-3:2.0 enp0s13f0u3c2: unregister ‘cdc_ncm’ usb-0000:00:0d.0-3, CDC NCM (NO ZLP)
I have tried multiple ports for the ethernet card, but have not logged errors for all the ports. Both errors above were on the same lower left USB-C port. My laptop is a 12th generation intel.
One interesting behaviour that I could observe is that when the laptop lid is closed the activity lights blink rapidly, but when I open the lid the lights cease blinking as soon as linux comes online.
Can you help me with this or should I contact customer support?
Thank you for the suggestion, unfortunately restarting xhci did not fix my problem.
The ethernet will work for a little while, but when pulling data through it the adapter will still fail after a short while before restarting, same as before.
I included about 5 minutes of logs because otherwise they were too big for Pastebin, in these 5 minutes I also executed the commands in your previous comment:
Because of the xhci commands you may see some more USB activity than would otherwise be expected.
Tonight I could also make some fresh logs where I execute specific commands, if that helps.
One thing that sticks out to me is that every instance of ep state failure seems to be preceded by my system starting up Name Service Cache Daemon (nscd) and once the Ethernet fails with an ep state error, nscd stops caching and shuts down.
Oftentimes networkmanager-dispatcher.service shuts down just before the failure, but not always.
The ethernet adapter also keeps being registered under a new id.
This morning I decided to see what would happen if I were to disable nscd, and unfortunately this does not fix my problems either. It does, however, make for a cleaner log: journal2.txt - Google Drive
Thank you for the suggestion, unfortunately, this does not seem to affect anything.
Firstly, I am only able to run the modprobe commands after a fresh boot without having the ethernet dongle connected. Otherwise the system reports that the module is in use even with the dongle is disconnected. After a fresh boot, the module can be reloaded just fine.
With the dongle connected, I can only run the ifconfig command targeting the enp0. interface. The ifconfig command targeting the eth0 interface fails with a “no such device” error.
As far as I can see in the system logs, the dongle initially registers as eth0 for only a fraction of a second before getting reassigned to enp0. I also do not believe the error stems from this reassignment as to me it seems that eth0 is simply an intermediate identification during the start-up process of the dongle. The dongle works fine on the enp0 interface until it reaches an “incorrect slot or ep state”. It just so happens that it can only let through a very small amount of data before reaching that state.
Because the ncm module cannot be reloaded, it seems that any registration of the dongle before reaching the incorrect state sticks around, even though this does not seem to clog up ethernet port registrations. The usb device number assigned to the dongle goes up every cycle, however lsusb does not show any of these “ghost registrations”. It just shows that the device number of any current registration is higher than the device number of previous registrations in previous invocations of lsusb.
By the way, as I described previously, these problems also exist on live USBs of Fedora and Ubuntu, might I just have a faulty card as Matt suggests here?
Hi @Max_Hendriks Let’s rule out anything odd with the card itself by testing a live Fedora or Ubuntu USB flash drive.
In journalctl, we’re making sure we do not see:
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.
Realizing you may have seen this in Nix, I want to make sure this isn’t a bad card.
I have already tested the card under both Fedora and Ubuntu.
As I described in my original post, I received the following entries in my system log on Ubuntu:
Tomorrow I can generate fresh Ubuntu or Fedora logs for you if that’s still necessary.
Hi Mac, please open a ticket. If that error happen on installed and Live USB (not just installed), then it may be the card. If it has not been tested on a Live USB, this would be what we’d ask then if the card still shows that error, we’d go from there.