Luis Falcon <[email protected]> writes: > Reading the re man page, "The 8169S and 8110S are single-chip devices > containing both a 10/100/1000 MAC and 10/100/1000 copper PHY, which is > supported by rgephy(4)". > > Could it be that the kernel is assigning the "re" driver to the > device instead of "rgephy"? dmesg shows "RTL8169SBL".
I have a 2019 Dell with a similar but different realtek chip. re0 at pci1 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x15) re0: interrupting at msix2 vec 0 re0: RTL8168H/8111H (0x5400) re0: Ethernet address [something reasonable; not all ff!] re0: using 256 tx descriptors rgephy0 at re0 phy 7: RTL8251 1000BASE-T media interface, rev. 0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto You can see how the ethernet chip (MAC) is attached as re0, and the PHY part of it is a child rgephy0 attached to re0. In my case, despite it being realteak instead of an Intel i8254x, it works fine. > PS: The error "reset never completed!" is immediately triggered whenever > I do ifconfig re0 up. I see in your dmesg: [ 1.019032] re0 at pci3 dev 0 function 0: RealTek 8100E/8101E/8102E/8102EL PCIe 10/100BaseTX (rev. 0x07) [ 1.019032] re0: interrupting at msix3 vec 0 [ 1.019032] re0: RTL8169SBL (0x7cc0) It seems the driver is deciding it's a different part number than the one printed by the PCI discovery. *This is a huge clue.* [ 1.019032] re0: reset never completed! Without reading the driver code, obviously the driver is trying to do some initial setup and reset to get it into a known state as the first thing. (Inferring!!!) After writing the codes to do that, it didn't get an acknowledgement. It's probably a bug that the driver continued to do anything after that. [ 1.019032] re0: Ethernet address ff:ff:ff:ff:ff:ff That's obviously a buggy read, because the broadcast address is invalid for an interface. [ 1.019032] re0: using 256 tx descriptors Surely driver internal, so irrelevant. I would suggest test-booting other operating systems to see how it's probed and attached, and reading the re driver sources. I'm guessing that the reset/setup goes badly and that this is fatal. See (I'm looking at netbsd-11) src/sys/dev/ic/rtl8169.c main driver src/sys/dev/pci/if_re_pci.c pci glue
