You don’t happen to have a config in /etc/tlp.d/00-yourhostname?
I was wondering if they had anything configured in there, in which case they might overrride any changes you made. That and if you just made changes to the main tlp.conf they might not stick since the recommended method is to add file in /etc/tlp.d with your modified config.
Hello, i just got my new 11th gen laptop today, put ubuntu on it, everything was great and no problems whatsoever. but for some reason now, my ethernet is not working anymore. at the start i just needed to plug in the cable and it was done. now it is gone. i am new to ubuntu so i dont really know how to troubleshoot connection problems. it is just weird that for hours it works flawlessly and now it doesnt anymore. the card sometimes gives a milisecond a orange LED flash, so it gets power. but any idea how i can fix this? i already restarted but nothing. wifi works fine. but i want to use the cable.
under network in the settings, it says cable unplugged and in that setting, “connect automatically” is checked. so any ideas what i could do? thanks
EDIT: it seems to be an ubuntu problem. the card is regonized but many others had this bug on their ubuntu on different versions. i cant find a solution to mine yet. help is still appreciated, if someone else with a fw laptop had this issue on his 22.04 ubuntu desktop.it really sucks, that i bought the ethernet card to use it and then the software doesnt work with it.
This is operating under the understanding this is happening while resuming from suspend. Even if it isn’t. I’d try this anyway.
This is a variation of a fix used on Fedora for suspend powering off the Ethernet expansion card on resume. This won’t be using grubby though, instead:
sudo lsusb
Look for ID 0bda:8156 Realtek Semiconductor Corp. USB 10/100/1G/2.5G, we want 0bda:8156.
sudo gedit /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="usbcore.quirks=0bda:8156:k quiet splash"
Save the file, then sudo update-grub
Then reboot.
1 Like
@Matt_Hartley I think the usbcore.quirks used here disables link power management on the network expansion card.
Do you know if this is materially different from blacklisting the device in TLP (which also worked for me)? I know it didn’t resolve the issue for everyone, but I’d like to understand which is optimal, in my case.
It does. And what I have seen in there are cases where some distros do well with this being disabled with some kernels.
Most often, this is true with suspend/resume. In those instances, the idea is to prevent the module from failing to resume at all (which was happening on Fedora).
In the case of it not connecting, I want to make sure this isn’t a power saving thing. Once that’s shown not to be a thing, then we can dive into loaded modules, kernel bugs, etc.
This will feel super counter-intuitive. However, I’ve seen power saving do weird, weird things in the past and 8 times out of 10, it’s the culprit for stuff like this.
Regardling blacklist TLP stuff - there is a bit of confusion about this. Despite what you see here, it won’t help with power saving. That said, one could try usbcore.autosuspend=-1 instead of usbcore.quirks. But quirks targets what we want, autosuspend is only helpful with resume.
1 Like
That doesn’t work for me. After boot, TLP kicks in and forcibly enables power saving on the ethernet card anyways and boom, link is gone again.
So re-reading that GitHub thread, it seems like USB_AUTOSUSPEND=1 is the culprit. Adding:
USB_AUTOSUSPEND=0
to my /etc/tlp.conf completely fixed the issue for me. What sold me on that idea is this quote from that bug report you mentioned:
By default, USB power saving is active in the kernel, but not force-enabled for incompatible drivers. That is, devices that support suspension will suspend, drivers that do not, will not.
So TLP is basically being too aggressive here and needlessly breaking that poor NIC.
That said, the question remains: why isn’t this driver compatible with power saving? That would be a nice addition… 
I guess I can’t ask too much, it’s quite rare to find a NIC that works out of the box without firmware blobs, so kudos on that.
I’ll tell support to close my ticket, this solves the issue for me to satisfaction.
5 Likes
Interesting and great that you were able to deduce what was happening. I closed the ticket, so you’re good there. I’ll do some more poking around with this on my own. But what is wild is that this shouldn’t be a thing (at the OS level). Crazy weird, but good outcome. 
2 Likes
Yeah it would be nice to figure out if the kernel could enable power savings on that card… I haven’t done my suspend/runtime/busy power tests on that card, but I suspect it’s taking quite a bit of juice… I don’t keep it plugged in because of this right now.
Not sure what you mean here…
Sorry, to clarify the distro in question and it’s TLP installation should not behave this way. But as I am sure you know, get everything running great then whammo - kernel update or an update to TLP does something creative.
I say this as my only challenge with the card was during suspend/resume and it disappearing. Now it looks like we have another challenge that you’ve done great work on and finding a workaround.
The driver module, would be an OS thing. The chipset itself is as it is. But the driver module’s interactions with TLP or how TLP in general interacts with the module is doing creative things. So this provides me with a jumping off point. And knowing the Linux ecosystem, will likely be fixed in a kernel update.
Hopefully that made more sense. I need more coffee, it’s been a dial tone sort of morning for me.
2 Likes
The better way to get it working with tlp is to use lsusb to discover the ID of the device and then use the USB_DENYLIST='IDHERE" to exclude it from autosuspend. Some devices play well with autosuspend Thunderbolt docks usually don’t and a lot of networking items as well.
Another issue is that TLP just had a major version change to 1.5.0 and with it came a number of changes that made life interesting until I did the right thing and read the changelog. Also with any Gnome desktop distro masking the power-profiles-daemon is vital since it conflicts with TLP. Why they ever integrated it, still makes no sense since it has miniscule number of features compared to tlp, and does not do nearly as well in the power saving department.
From what I understand, USB_AUTOSUSPEND is just a plain bad idea because the kernel itself already does autosuspend when the driver supports it. What TLP does is enable autosuspend when the driver does NOT support it, which seems like a … questionable idea.
In fact, so much so that I wonder if I won’t rerun my power tests with and without TLP to figure out if it really gives me anything at all… Or I could just uninstall it and live my life: I tend to think that things should just work “out of the box”: if my OS doesn’t ship with TLP, why would I need it?
If the Linux kernel defaults are incorrect, they should be fixed at the source, and not need duck tape like this to behave correctly and hide those problems (or, in this very case, create new ones).
1 Like
Ah, fair point.
Agreed, honestly. I wish this was done right at the Linux kernel source.
1 Like
I wish the kernel did it as well. TLP gains me about 2 hours of battery life by doing the little things the kernel should be doing, and has in many cases made devices usable for me that would otherwise not behave correctly. It provides an easy to use user configurable interface for correcting what amount to misbehaving devices. A dock with a network connection that continually disconnects because the kernel thinks it should just suspend is worthless. I can at least get it to stop doing this with TLP with minimal effort.
Also in many cases the driver does not support it simply because linux is an afterthought for most manufacturers particularly when it comes to laptops and desktop accessories. If it is not an Enterprise grade part or device it just does not matter to them.
1 Like
i am sorry, maybe i am doing smth wrong, but nothing works for me here.
i changed the number of USB_AUTOSUSPEND=1 to 0.
still ethernet doesnt work. and in my file it is #USB_AUTOSUSPEND=0
do i delete the # ?
i changed tlp.conf with “sudo gnome-text-editor /etc/tlp.conf”
because i am not good enough to use vi/vim
do i still have to add "#USB_DENYLIST=“id” too?
Yes, delete the #. That marks the line as a “comment” which makes TLP ignore it. So you want this line:
USB_AUTOSUSPEND=0
… without the leading #.
And you’re not dumb.
THe DENYLIST bit also won’t work until you remove the # before it. I think you don’t need both, only one of those should be sufficient.
3 Likes
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