Attachments (17)
Change History (52)
comment:1 by , 11 years ago
comment:3 by , 11 years ago
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.
by , 11 years ago
Attachment: | syslog_dhcp_Realtek_8111F.txt added |
---|
syslog with rtl8xx driver failing to talk to DHCP server
comment:4 by , 11 years ago
@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 by , 11 years ago
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).
by , 11 years ago
Attachment: | acpi_Realtek8111F.txt added |
---|
result of 'cat /dev/acpi/namespace' (might need a more recent hrev for complete output?)
comment:6 by , 11 years ago
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 by , 11 years ago
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 by , 11 years ago
@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..
by , 11 years ago
Attachment: | syslog_rtl81xx_more_tracing.txt added |
---|
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 by , 11 years ago
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
comment:10 by , 11 years ago
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 by , 11 years ago
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?
by , 11 years ago
Attachment: | SYSLOG00.TXT added |
---|
comment:12 by , 11 years ago
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:14 by , 11 years ago
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.
by , 11 years ago
Attachment: | syslog_RTL8111F_success!.txt added |
---|
MSI disabled: Everything works now, DHCP works, WebPositive connects ..etc
comment:15 by , 11 years ago
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 by , 11 years ago
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;
by , 11 years ago
Attachment: | syslog_hrev45844-as-is_Failure.txt added |
---|
With changes in 45842 (no-go)
by , 11 years ago
Attachment: | syslog_hrev45844+patched-pci-manager_Failure.txt added |
---|
With changes in 45842 plus the patch in comment:16 (no-go)
comment:17 by , 11 years ago
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).
follow-up: 19 comment:18 by , 11 years ago
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 by , 11 years ago
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
comment:20 by , 11 years ago
I have a similar problem. NetworkStatus shows that I have an internet connection, but webpages won't load.
by , 11 years ago
by , 11 years ago
follow-up: 22 comment:21 by , 11 years ago
Premislaus, it would be helpful if you could check the situation on Linux (lspci -vvvv as root and syslog). Thanks.
comment:22 by , 11 years ago
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
by , 11 years ago
Attachment: | lspci_ubuntu_13.04.txt added |
---|
by , 11 years ago
Attachment: | syslog_ubuntu_13.04 added |
---|
by , 11 years ago
Attachment: | 0001-MSI-Use-the-effective-APIC-id-of-the-boot-CPU-for-th.patch added |
---|
msi patch destination
comment:23 by , 11 years ago
patch: | 0 → 1 |
---|
comment:24 by , 11 years ago
It would be nice if one of you could check the patch "msi patch destination" and provide a syslog.
comment:25 by , 11 years ago
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).
by , 11 years ago
Attachment: | syslog Success (MSI destination).txt added |
---|
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 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Applied the patch in hrev45925. About the timer driver, I think it's for testing purposes.
Thanks a lot for your time and dedication!
comment:27 by , 11 years ago
@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.
by , 11 years ago
Attachment: | 0001-FreeBSD-compat-layer-implement-MSI-X-support.patch added |
---|
freebsd msi-x
follow-up: 29 comment:28 by , 11 years ago
It's applied in hrev45932 anyway. Please shout in case of regression :)
follow-up: 30 comment:29 by , 11 years ago
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
comment:30 by , 11 years ago
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.
follow-up: 33 comment:32 by , 11 years ago
Nope, still broken. I'll attach a new syslog but it appears to contain the same error setting up the irq.
comment:33 by , 11 years ago
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:35 by , 11 years ago
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..