NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Issues with Realtek ethernet card - NetBSD 11



Luis Falcon <falcon%gnuhealth.org@localhost> 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



Home | Main Index | Thread Index | Old Index