I have a weird issue I can't find out why it is happening. I was using a 19-snapshot without issue however when I installed the stable 21.02 version, the USB-Ethernet adapter doesn't survive reboots - it says the device is not connected. If I unplug-plug it starts working again. So every time the device reboots I have to unplug-plug the device to get it to work. Any ideas what might be causing it? The adapter is RTL-8152 Cable Matters 202013.
BTW - I installed 21.02 from scratch - didn't upgrade.
I installed from scratch the current 20-snapshot and it works great! Things are back to normal. But I would really like to be on a STABLE release since this is my work account. I have a 1GB/1GB connection and I am getting the full throughput. Oh well I guess for now I will stay on a beta release - although I am REALLY curious about what caused it and how to mitigate it in the future. The kernel I am running now is 5.10.64 and it is working fine. I also ordered a TP-Link UE300 as a backup since everyone says it works great with these devices.
Yes, I have been testing snapshots for usb connectivity and the UE300 is inconsistent. I thought I would post here and see if the reason could be found since so many use this adapter with RPI's and Openwrt.
Of the last 2 dozen or so snapshots, the UE300 has worked on about 40% of them - with the rest the device is ignored.
Thanks for your response. I have several USB adapters that I purchased for testing. The one that is the most reliable is an Insignia brand that I bought from Best Buy. I have to say it has never failed!
I've seen the issue with several brands of Realtek adapters, they will disappear on reboot but if you unplug/replug the device, it connects. The issue is boiled down to surviving a reboot.
I have not seen the issue with the ASIX chipset. It appears to be very reliable. I have several of them as well and they connect each time.
Sorry I didn't notice your last edit. The RPI is over clocked to 2GHz which is safe for the 64bit version, however I will reload the latest snapshot and disable over clocking to see if that changes anything.
the only time i've seen odd behavior from these adaptors similar to what you describe was when power (lack of it) was involved... but my dmesg output was substantially different...
do you have any 2.5-ssd or other power hungry thing connected? is the UE in a hub? describe your psu? (edit: see you mention overclock... quite possible this is draining/stressing out either the PSU or onboard regulator/s at boot time)
So you think the problem is power......hmmmm.very interesting. I am using a 5V-3amp power supply for the RPI 4. I have the device in an Argon case with a SSD M.2 drive. Perhaps I will disconnect the case and use an SD card to load the latest snapshot and see what happens
Here is the result - your are correct, my friend!! The problem was power. I disconnected the SSD M.2 drive and installed Openwrt on an SD card. I installed Luci and the driver RTL8152 (wish there was a rtl8153), rebooted several times and the UE300 comes up each time.
I did some searching and there is a power supply 5.25V-3.5A, so I'm going to order it. I think that will fix the problem for good - it may also cause the other RTL8152's I have to start working consistently.
my understanding is the issue is downstream of the rpi4 regulator... possibly a slightly better specced psu may help... but
as I understand it, you'd need to pipe the nvme(well as the other nics are working ok maybe the UE300 instead) through a powered hub(beware: many powered hubs also have backpower issues which prevent the pi from rebooting at all!) ( or inject 5v directly at the usb port bypassing the regulator ) to resolve the root cause...
perhaps get in touch with the Argon case / usb3-nvme-chipset / nvme drive itself people re: current draw... / recommendations / quirks re: power first... pretty sure they'd be aware of the root limitations here...
Thanks for the info. Perhaps I should just stick with the recommendation from Argon. I'm sure they know their products and their supply is designed for their M.2 cases. The other one is a knockoff so it may not be good quality.