text: Opened 6 years ago
  Closed 6 years ago
  Last modified 6 years ago
  #9807 closed bug (fixed)
  RealTek RTL8111 listed but does not work
  Attachments (17)
  Change History (52)
  comment:1 Changed 6 years ago by
  comment:2 Changed 6 years ago by
  It would be nice to have a syslog.
  comment:3 Changed 6 years ago by
  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.
  Changed 6 years ago by
  syslog with rtl8xx driver failing to talk to DHCP server
  comment:4 Changed 6 years ago by
  @korli: syslog for Realtek problem posted. Next I'll prepare myself to compile the driver, so that I can do experimentations as needed. Thanks.
  comment:5 Changed 6 years ago by
  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).
  Changed 6 years ago by
  result of 'cat /dev/acpi/namespace' (might need a more recent hrev for complete output?)
  comment:6 Changed 6 years ago by
  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?
  comment:7 Changed 6 years ago by
  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.
  comment:8 Changed 6 years ago by
  @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..
  Changed 6 years ago by
  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 ??)
  comment:9 Changed 6 years ago by
  Your build seems incorrect, please review your changes :) 0x48000000 is found here:
  comment:10 Changed 6 years ago by
  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.
  comment:11 Changed 6 years ago by
  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?
  comment:12 Changed 6 years ago by
  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.
  comment:13 Changed 6 years ago by
  comment:14 Changed 6 years ago by
  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.
  Changed 6 years ago by
  MSI disabled: Everything works now, DHCP works, WebPositive connects ..etc
  comment:15 Changed 6 years ago by
  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.
  comment:16 Changed 6 years ago by
  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;
  Changed 6 years ago by
  With changes in 45842 (no-go)
  Changed 6 years ago by
  With changes in 45842 plus the patch in comment:16 (no-go)
  comment:17 Changed 6 years ago by
  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).
  comment:18 follow-up: 19 Changed 6 years ago by
  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.
  comment:19 Changed 6 years ago by
  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
  comment:20 Changed 6 years ago by
  I have a similar problem. NetworkStatus shows that I have an internet connection, but webpages won't load.
  comment:21 follow-up: 22 Changed 6 years ago by
  Premislaus, it would be helpful if you could check the situation on Linux (lspci -vvvv as root and syslog). Thanks.
  comment:22 Changed 6 years ago by
  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:
  Changed 6 years ago by
  msi patch destination
  comment:23 Changed 6 years ago by
  comment:24 Changed 6 years ago by
  It would be nice if one of you could check the patch "msi patch destination" and provide a syslog.
  comment:25 Changed 6 years ago by
  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).
  Changed 6 years ago by
  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
  comment:26 Changed 6 years ago by
  comment:27 Changed 6 years ago by
  Changed 6 years ago by
  freebsd msi-x
  comment:28 follow-up: 29 Changed 6 years ago by
  comment:29 follow-up: 30 Changed 6 years ago by
  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=128 Kernel modules: r8169
  Changed 6 years ago by
  syslog showing failure to initiliaze due to MSI
  comment:30 Changed 6 years ago by
  Replying to augiedoggie:
  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.
  comment:31 Changed 6 years ago by
  comment:32 follow-up: 33 Changed 6 years ago by
  Nope, still broken. I'll attach a new syslog but it appears to contain the same error setting up the irq.
  Changed 6 years ago by
  comment:33 Changed 6 years ago by
  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.
  comment:34 Changed 6 years ago by
  It appears to be working again. Thanks.
  Changed 6 years ago by
  Success, and mentions msi-x
  comment:35 Changed 6 years ago by
  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!).
  Some data gallore collected in "Static" IP mode, after setting it up with a correct IP..