RealTek RTL8111 listed but does not work

[ttcoder]

hrev45681

This is an RTL8111F onboard an Asus F2A55M motherboard. It seems to have nominal support since it's listed in /dev/net and in Network preferences but does not work either in DHCP or Static configuration.

Found 2 similar tickets for close-ish chipsets, #9131 and #8930 .

[ttcoder]

Some data gallore collected in "Static" IP mode, after setting it up with a correct IP..

~> listdev 
device Network controller (Ethernet controller) [2|0|0]
  vendor 10ec: Realtek Semiconductor Co., Ltd.
  device 8168: RTL8111/8168 PCI Express Gigabit Ethernet controller
      ......

~> ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto: No route to host
ping: wrote 192.168.1.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 192.168.1.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 192.168.1.1 64 chars, ret=-1
ping: sendto: No route to host
ping: wrote 192.168.1.1 64 chars, ret=-1
--- 192.168.1.1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
~> route
   192.168.1.19 mask                 /dev/net/rtl81xx/0, host local
      127.0.0.1 mask                 loop, host local
    192.168.1.0 mask 255.255.255.0   /dev/net/rtl81xx/0
      127.0.0.0 mask 255.0.0.0       loop
        0.0.0.0 mask 0.0.0.0         gateway 192.168.1.1     /dev/net/rtl81xx/0, default
            ::1/-2147454933 loop, host local
            ::1/128 loop

~> uname -a
Haiku shredder 1 hrev45681 May 14 2013 00:36:39 BePC Haiku


/boot/common/var/log> grep rtl syslog
KERN: rtl81xx: init_driver(0x8169bf88)
KERN: [rtl81xx] (re) bus_alloc_resource(3, [24], 0x0, 0xffffffff, 0x1,0x2)
KERN: [rtl81xx] (re) MSI count : 1
KERN: [rtl81xx] (re) MSI-X count : 0
KERN: [rtl81xx] (re) Using 1 MSI message
KERN: [rtl81xx] (re) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
KERN: [rtl81xx] (re) Chip rev. 0x48000000
KERN: [rtl81xx] (re) MAC rev. 0x00000000
KERN: [rtl81xx] rtl81xx: /dev/net/rtl81xx/0
KERN: [rtl81xx] () Found MII: rgephy
KERN: [rtl81xx] () OUI 0x00e04c, model 0x0011, rev. 5
KERN: [rtl81xx] ()  ifmedia_add: Adding Entry...
KERN: loaded driver /boot/system/add-ons/kernel/drivers/dev/net/rtl81xx
KERN: [net/rtl81xx/0] compat_open(0x2)
KERN: /dev/net/rtl81xx/0: media change, media 0x22 quality 1000 speed 10000000
KERN: /dev/net/rtl81xx/0: media change, media 0x900026 quality 1000 speed 10000000

[korli]

It would be nice to have a syslog.

[ttcoder]

Right I'll definitely post one when I get the computer back.

Appreciate you looking at this one korli; for each station sold we are stuck on using an extra network card (thus reserving the one and only PCI slot that this motherboard has) which makes life a bit less easy than it could be for us if we could simply use the integrated networking. And contrarily to the HDA driver, here I can't get started on this as I understand nothing about the network code, so help very appreciated.

The computer's at a customer for evaluation currently but in a few days/weeks I'll take it back to grab a syslog and try out custom builds of the driver following your directions.

Probably once I understand the driver's code a little I'll be more autonomous and provide good info.

[ttcoder]

syslog with rtl8xx driver failing to talk to DHCP server

[ttcoder]

@korli: syslog for Realtek problem posted. Next I'll prepare myself to compile the driver, so that I can do experimentations as needed. Thanks.

[korli]

Please add an ACPI dump (the output of "cat /dev/acpi/namespace"). It should be truncated in the revision you use, it probably doesn't matter, important things should be before anyway.

To be noticed, the Realtek network device is located behind a PCI bridge (in comparison with the HDA device which is on the bus 0).

[ttcoder]

result of 'cat /dev/acpi/namespace' (might need a more recent hrev for complete output?)

[korli]

ttcoder, I noticed the PCI bridge has only I/O and prefetchable memory windows configured, but that shouldn't be a problem because the network device only needs such resources. Do you have a Linux on this machine to check the PCI configuration?

[ttcoder]

Nope no linux, only Haiku installed on the partitions there.. I might have a 'live CD' linux from the early 2000's in my archives somewhere but not sure if I can find it or if it would be recent enough to boot this up and to give decent info..

I'll keep what you said in mind about the PCI bridge, I suppose it could be important for something else too: I'll file another ticket in a month or so about adding video support for this machine, seems Haiku does not recognize it (apparently the Radeon GPU is on the same chip as the AMD CPU, I didn't even know that was possible!).

Making progress toward compiling/building the driver here, a few days more.

[ttcoder]

@korli -- ok so the driver compiles, and... it behaves differently from the nightly image's driver: it complains about unsupported hardware and then bails out and unloads:

KERN: allocate_io_interrupt_vectors: allocated 1 vectors starting from 24
KERN: msi_allocate_vectors: allocated 1 vectors starting from 24
KERN: [rtl81xx] (re) Using 1 MSI message
KERN: [rtl81xx] (re) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
KERN: [rtl81xx] (re) Chip rev. 0x48000000
KERN: [rtl81xx] (re) MAC rev. 0x00000000
KERN: [rtl81xx] (re) Unknown H/W revision: 0x48000000
KERN: msi_free_vectors: freeing 1 vectors starting from 24
KERN: free_io_interrupt_vectors: freeing 1 vectors starting from 24
KERN: remove_memory_type_range(3086, 0xd0004000, 0x20000, 0)

I first thought it was my fault, maybe the freebsd compatibility layer has changed since I cloned the repository (I only updated the driver source, not the rest), but it seems my build of the driver is justified in complaining about unsupported hardware, as my Rtl8111 has ID 0x48000000 and that value is nowhere to be found in if_rlreg.h.. So I added some extra tracing, result attached down here. What I'm describing will be more clear when reading it.

Not sure if this all correlates or not with what you said about the PCI bridge as that is beyond my cognitive powers 8-)

I have a plan B for attempting to hack the driver if we don't make progress but it is barbaric and brutal *grin*.. and probably won't work..

[ttcoder]

my build of the driver, with extra tracing showing that none of the supported IDs match my NIC's ID (so why does the nightly's driver pretent it is supported ??)

[korli]

Your build seems incorrect, please review your changes :) 0x48000000 is found here: ​http://cgit.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/network/rtl81xx/pci/if_rlreg.h#n192

[ttcoder]

Situation back to normal! My "lack of support" mumbo-jumbo was just a ttcoder snafu as usual 8-) With my various experiments to compile the driver I ended up with an old copy of its code... Oops! I've now done a real "git pull" proper and recompiled and the driver behaves like the nightly one now.

It now produces the same syslog output. The Terminal testing as in comment:1 is slightly different though, but that's probably not significant: rather than ping: sendto: No route to host I instead get ping: sendto: Network is unreachable, and the 7 lines "route" output is replaced with just 4 lines, with 127.0.0.1 mask (..) and 127.0.0.0 mask 255.0.0.0 loop.

Sorry for providing hand-typed summaries rather than actual files, but well... That machine currently has no ethernet networking to transfer data out of it ;-) and as for USB, it's the same as most PCs I have here, writing to a USB thumbdrive crashes or misbehaves.. Anyway the changes are probably because I'm now testing in DHCP, whereas in comment:1 I was testing with Static IP.

[korli]

I've investigated a bit and it seems the PCIe bridge has the HyperTransport capability, which would require additional setup driver side to be able to use MSI. "Disable local APIC" would help to see if this is really the problem (this also disables MSI). Have you tried this option yet?

[ttcoder]

Interesting: "disable local APIC" prevents the machine from booting. See syslog00.txt: the last lines are related to usb-ehci, for some reason that's where it blocks...

There are other boot issues on this F2A55M motherboard but not critical so I didn't file any ticket on them yet. If I add this new issue, the list of issues then becomes:

• with "Disable Local APIC", the boot-up stops in the middle (4 icons lit, 3 icons unlit). Using an mkdos-created FAT32 partition to retrieve the syslog (since it's not written to its normal location for some reason in this case) I managed to retrieved it, see "syslog00.txt".

• without any safe-mode option, the machine boots most of the time.. But in around 20 or 30% of cases the boot-up stops in a similar way, with 4 icons lit and neither ctrl-alt-del nor the KDL key combo work, so I have to do a 'hard' reset.

• also noticed that sometimes the haiku boot menu (to choose which partition to boot to) is randomly exited as if I had typed 'enter'. No big deal.

To make things further... interesting, dsuden's reference machine (with the exact same motherboard) does not have issues # 2 and # 3 above like my reference machine has. I will ask him to try out the # 1 (disable local APIC) though.

[korli]

You can also eventually disable msi for the rtl81xx driver ​here

[ttcoder]

That did it! Thanks so much Jerome. Posting a syslog soon in case it's useful.

I now get successful pings of around 1.2 ms, 0% packet loss, route looks correct, WebPositive connects to haiku-os.org and I can download an image.xz file for a while with ca. 100KB/s downstream (which meets my expectations since my xDSL bandwidth tops out at 120 KB/s).

Leaving you no time to rest on your success ;-) I'll ask right away, what happens next to apply a change in HEAD/trunk: I guess MSI is a better mechanism for allocating resources (interrupts?) than no MSI at all, so you cannot apply this change as it is now and there is more to do?

Me and dsuden would be content with the 'hacked' driver as it is now, so no emergency anyhow.

[ttcoder]

MSI disabled: Everything works now, DHCP works, WebPositive connects ..etc

[korli]

Nice to read! Indeed, this change cannot be applied as is :) I'll dig a bit and test things locally. Hopefully I'll get something to test before next week.

[korli]

Could you have a try with hrev45842?

It's possible it doesn't work. In this case please try the following additional patch.

diff --git a/src/add-ons/kernel/bus_managers/pci/arch/x86/pci_msi.cpp b/src/add-ons/kernel/bus_managers/pci/arch/x86/pci_msi.cpp
index e87e852..f246001 100644
--- a/src/add-ons/kernel/bus_managers/pci/arch/x86/pci_msi.cpp
+++ b/src/add-ons/kernel/bus_managers/pci/arch/x86/pci_msi.cpp
@@ -219,7 +219,7 @@ pci_enable_msi(uint8 virtualBus, uint8 _device, uint8 function)
                info->control_value);
 
        // enable HT msi mapping (if applicable)
-       pci_ht_msi_map(device, info->address_value);
+       pci_ht_msi_map(device->parent->parent, info->address_value);
 
        dprintf("msi enabled: 0x%04" B_PRIx32 "\n",
                gPCI->ReadConfig(device, info->capability_offset + PCI_msi_control, 2));
@@ -251,7 +251,7 @@ pci_disable_msi(uint8 virtualBus, uint8 _device, uint8 function)
                return B_NO_INIT;
 
        // disable HT msi mapping (if applicable)
-       pci_ht_msi_map(device, 0);
+       pci_ht_msi_map(device->parent->parent, 0);
 
        // disable msi generation
        info->control_value &= ~PCI_msi_control_enable;
@@ -484,7 +484,7 @@ pci_enable_msix(uint8 virtualBus, uint8 _device, uint8 function)
                info->control_value);
 
        // enable HT msi mapping (if applicable)
-       pci_ht_msi_map(device, info->address_value);
+       pci_ht_msi_map(device->parent->parent, info->address_value);
 
        dprintf("msi-x enabled: 0x%04" B_PRIx32 "\n",
                gPCI->ReadConfig(device, info->capability_offset + PCI_msix_control, 2));
@@ -516,7 +516,7 @@ pci_disable_msix(uint8 virtualBus, uint8 _device, uint8 function)
                return B_NO_INIT;
 
        // disable HT msi mapping (if applicable)
-       pci_ht_msi_map(device, 0);
+       pci_ht_msi_map(device->parent->parent, 0);
 
        // disable msi-x generation
        info->control_value &= ~PCI_msix_control_enable;

[ttcoder]

With changes in 45842 (no-go)

[ttcoder]

With changes in 45842 plus the patch in comment:16 (no-go)

[ttcoder]

Summary:

• downloaded the latest nightly and ran it "as-is": DHCP fails
• applied the patch and replaced the file /boot/system/add-ons/kernel/boot/pci, but DHCP fails in that case too.
• restored the "disabled MSI" version of rtl81xx and went back to normal networking, which I used to transmit the syslogs (well networking is very good if not completely "normal" by the way, I had a bit of trouble in webpositive this morning trying to read my webmail at the same time I was downloading hrev45844, the web page seemed to interfere with the download, it was probably just an isolated glitch though).

[korli]

The expected log "ht msi mapping enabled" isn't showing up. This could mean this mapping is already enabled though.

Until we find the problem, a workaround would be to disable MSI for devices behind this bridge, although other OS don't blacklist it.

[ttcoder]

Replying to korli:

The expected log "ht msi mapping enabled" isn't showing up. This could mean this mapping is already enabled though.

Seems it is:

KERN: ====== inside pci_enable_msi()
KERN: ***** inside pci_ht_msi_map( 4276092928 )
KERN: info->ht_mapping_capable = 1
KERN: enabled=1
KERN: msi enabled: 0x0081 (ttcdr build)

The code path does not enter inside the if(), as per my brute-force tracing:

pci_ht_msi_map(PCIDev *device, uint64 address)
{
dprintf("***** inside pci_ht_msi_map( %Ld )\n", address);
	ht_mapping_info *info = &device->arch_info.ht_mapping;
dprintf("info->ht_mapping_capable = %d\n", info->ht_mapping_capable);
	if (!info->ht_mapping_capable)
		return;

	bool enabled = (info->control_value & PCI_ht_command_msi_enable) != 0;
dprintf("enabled=%d\n", enabled);
	if ((address != 0) != enabled) {
dprintf(" ..if\n");
		if (enabled) {
dprintf(" ..  if enabled\n");
			info->control_value &= ~PCI_ht_command_msi_enable;
		} else {
dprintf(" ..  else (with info->address_value=0x%Lx)\n", info->address_value);
			if ((address >> 20) != (info->address_value >> 20))
				return;
			dprintf("ht msi mapping enabled\n");

As a side node, I'm seeing something that was not there before, the rtl81xx driver output is now intertwined with mtrr lines; probably means nothing though:

KERN: [rtl81xx] (re) Using 1 MSI message
KERN:   mtrr:  0: base:    0x90000, size:    0x10000, type: 0
KERN: [rtl81xx] (re) bus_alloc_resource(1, [1], 0x0, 0xffffffff, 0x1,0x2)
KERN:   mtrr:  1: base:    0xa0000, size:    0x20000, type: 0

[Premislaus]

I have a similar problem. NetworkStatus shows that I have an internet connection, but webpages won't load.

[korli]

Premislaus, it would be helpful if you could check the situation on Linux (lspci -vvvv as root and syslog). Thanks.

[Premislaus]

Replying to korli:

Premislaus, it would be helpful if you could check the situation on Linux (lspci -vvvv as root and syslog). Thanks.

OK

BTW maybe this will be useful:

​http://wiki.osdev.org/RTL8139 ​http://wiki.osdev.org/RTL8169

[korli]

msi patch destination

[korli]

It would be nice if one of you could check the patch "msi patch destination" and provide a syslog.

[ttcoder]

Works like a champ!

Will do some more 'heavy' testing in the weeks to come, but after writing the new kernel_x86 file and rebooting, I was able to transmit a syslog through the wire, browse free.fr ..etc and it all worked fine. That was after I reverted to the "baseline" rtlxx driver of course ;-). Works great.

Maybe a minor change/additional cleanup has to be added to the patch: I've noticed that there's a ​redundant copy of the header's declaration of the msi_*() ​declarations, which should probably be kept in sync, or better yet deleted (or I might be blowing smoke out of ignorance, not sure).

[ttcoder]

The success does not show up much in the syslog... also minor issues (no "hrev" listing, boot screen icons are offset), obviously due to my expedited compile/build process

[korli]

Applied the patch in hrev45925. About the timer driver, I think it's for testing purposes.

Thanks a lot for your time and dedication!

[korli]

@ttcoder if you've some time available, I'll be interested you could test this patch for MSI-X enabling in the FreeBSD compat layer. My network card doesn't support that, and emulation doesn't help here. No hurry, be sure to update the PCI module to at least hrev45927 though.

[korli]

freebsd msi-x

[korli]

It's applied in hrev45932 anyway. Please shout in case of regression :)

[augiedoggie]

Replying to korli:

It's applied in hrev45932 anyway. Please shout in case of regression :)

THIS CAUSED A REGRESSION ;)

The driver no longer initializes the realtek chip on my motherboard.

From 'lspci -vnn' in linux:

04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168] (rev 06)
        Subsystem: ASUSTeK Computer Inc. P8P67 and other motherboards [1043:8432]
        Flags: bus master, fast devsel, latency 0, IRQ 44
        I/O ports at e800 [size=256]
        Memory at fdfff000 (64-bit, prefetchable) [size=4K]
        Memory at fdff8000 (64-bit, prefetchable) [size=16K]
        Expansion ROM at fe9e0000 [disabled] [size=128K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Endpoint, MSI 01
        Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
        Capabilities: [d0] Vital Product Data
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
        Kernel driver in use: r8169
        Kernel modules: r8169

[augiedoggie]

syslog showing failure to initiliaze due to MSI

[korli]

Replying to augiedoggie:

Replying to korli:

It's applied in hrev45932 anyway. Please shout in case of regression :)

THIS CAUSED A REGRESSION ;)

The driver no longer initializes the realtek chip on my motherboard.

Thanks for testing. There is a typo ​here and ​here: delete the ampersand. Sorry for the trouble.

[korli]

Hopefull fixed in hrev45935. Please check!

[augiedoggie]

Nope, still broken. I'll attach a new syslog but it appears to contain the same error setting up the irq.

[augiedoggie]

syslog from hrev45935

[korli]

Replying to augiedoggie:

Nope, still broken. I'll attach a new syslog but it appears to contain the same error setting up the irq.

Please check with hrev45938. Thanks.

[augiedoggie]

It appears to be working again. Thanks.

[ttcoder]

Success, and mentions msi-x

[ttcoder]

Just did a clean install of hrev45943 and everything works 'out of the box', no tweaking required! It's nailed for good, me thinks. Thanks to you guys for providing the lspci I was unable to provide.. And of course korli for all the heavy lifting :-), you've earned a place in the TT "about box" (least I could do!).