Link rapidly goes UP and DOWN

baaz

baaz

Hi
Out of no where when i booted my pc i notice that it was stuck in the init and evrey 2 to 3 seconeds it was pirnting
re0: link state changed to UP re0: link state changed to DOWN
Over and over
And the (green) link light on the ethernet port blinked in sync with these meseges

And then
after few cycels of this loop it was printing these lines (not consistently) betwen those lines that i said at top

re0: link state changed to UP re0 link state down -> up DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval (a random number from 3 to 8) DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPOFFER from 192.168.1.1 re0: link state changed to DOWN


it would do this when the lan cable is connected to my adsl router
I also tried booting without the cable connected and it boots all fine but as soon as i connect the cable to router it all begins again(not printing the messages but the link light on the port still blinks)

There is a win10 laptop connrrcted to the router working fine and on the same machine l have both linux and win 10 and they work fine too but in freebsd in both multi and single user mode it dose this wird thing

Also my mother board is Gigabyte GA-P75-D3 with a on board realtek RTL8111/8168/8411 network card

The wierd part is that it was working all fine for a long time and suddenly this happened

Thanks in advance!
 
Its really weird , now after meny reboots (and doing nothing) its now working ? thats good i will install covacat's suggestion . But maybe the nic is really dying and showing it here on freebsd ?
 
A long time ago I had some issue with a re(4) interface too. See if shutting down (power off) the computer helps.

Whenever I rebooted from Windows to FreeBSD the re(4) wouldn't work. It was detected but never seemed to get an IP address, even static addresses didn't work. For some reason Windows left the interface in some weird state that FreeBSD didn't handle. Powering off and then booting FreeBSD made the card work properly. I only had this issue when dualbooting from Windows to FreeBSD. The other way around (FreeBSD to Windows) wasn't an issue.
 
SirDice said:
A long time ago I had some issue with a re(4) interface too. See if shutting down (power off) the computer helps.

Whenever I rebooted from Windows to FreeBSD the re(4) wouldn't work. It was detected but never seemed to get an IP address, even static addresses didn't work. For some reason Windows left the interface in some weird state that FreeBSD didn't handle. Powering off and then booting FreeBSD made the card work properly. I only had this issue when dualbooting from Windows to FreeBSD. The other way around (FreeBSD to Windows) wasn't an issue.
Click to expand...
I think thats it!
Because all of this happend after i had booted into my windows drive after a long time.
But after some testing and booting from windows to freebsd five times it didn't happen again !?
For now its working well but i will keep a eye on it to see whats causing it.
Thanks !
 
Got the same problem with 14.0 RELEASE, when dual booting with windows. During boot I get into loop and need to press ctrl-c to log in.

The „solution” is to boot freebsd with cable disconnected, plug cable, reboot and it works.
 
REFS:
FreeBSD-14-p4
USB Ethernet dongle
idVendor = 0x0bda
idProduct = 0x8153
bcdDevice = 0x3100
iManufacturer = 0x0001 <Realtek>
iProduct = 0x0002 <USB 10/100/1000 LAN>
Realtek USB LAN / USB C

Facing the same trouble with a Realtek USB dongle, I can confirm that a fresh start with the ethernet usb controller plugged in lead to the up/down behavior, but restarting - shutdown -r - fixes the issue for a moment, but it could rise again if you don7t use the if for a long time. To me, it sounds like a bios problem, putting the if down after some time, and in my case, I didn't see any switch in the bios to disabled this behavior.
I notice whether you put the if in down state or not, you still see the "link state" led active, the usb controller works on its own, whatever state you require from the OS. I have to say that the same behavior occurs with Windows11, so I guess it is not an OS side trouble, but a BIOS side one, but I could be wrong...
A workaround is to monitor the state of the device via devd, and apply an action rule accordingly.
The same dongle on a different laptop worked fine, so it depends on the laptop and the way the bios manage the port.
My 2 cents.
 
You must log in or register to reply here.
Back
Top