hrev56140 - NIC doesn't configure/enable anymore

[cocobean]

After doing 'pkgman full-sync' to hrev56140, NIC doesn't auto-configure anymore in OS after reboot Had to manually disable/re-enable it in desktop GUI.

• Vendor - 10ec: Realtek Semiconductor Corp
• Device - 8168: RTL8111/8168/8411 PCIe Gigabit Ethernet Controller

Test:

1. ifconfig - (Result: 0 packets)
2. pkgman full-sync - (Result: Could not resolve host issue)

Note: May work after manually reconfiguring/re-enabling NIC.

[bipolar]

Similar issue, same hardware, except that on some boots network does never works. In others, it gets up and ready without intervention, but... network perfomance is horrendous: ping 1.1.1.1 failures, downloads stalls, Webpositve loads one page, but hangs with the next, etc... until nothing works.

Selecting a previous state on the bootmanager (in my case, booting hrev56112) solves the issue.

Attempting to use hrev56112's rtl81xx driver on hrev56140 (after blacklisting the newer version on boot) sends me to KDL (so much for me trying to be find a workaround :-P)

I'll boot again with hrev56140 to get a "clean" syslog and I'll upload one for hrev56140 and one from hrev56112 (writing this while on the latter).

[bipolar]

Syslog of RTL81xx working on hrev56112

[bipolar]

Syslog of RTL81xx "working" (very poorly, unusable, really) on hrev56140

[cocobean]

See: ​https://git.haiku-os.org/haiku/log/?qt=range&q=hrev56138..hrev56139

I was able to get it working and update to hrev56141. Reading syslog, I saw this note:

hrev56141: KERN: [rtl81xx] (re) No memory for jumbo RX buffers

If you restart net-server, you should see the stall issue during 'Network Configuration' to 'Network Ready' status within the desktop. You can also do 'ifconfig <net device> auto-config up' and see if it works correctly (i.e. 'Network configuring' to 'Network Ready' status) and returns to the command prompt.

[waddlesplash]

Attempting to use hrev56112's rtl81xx driver on hrev56140 (after blacklisting the newer version on boot) sends me to KDL

If you use one from hrev56131+ it should work.

Syslog of RTL81xx "working"

Do you have one of it not working? (Do you see the same error messages cocobean does in any of them?)

[bipolar]

Replying to waddlesplash:

Do you have one of it not working?

I'll attach one (I found it on syslog.old, I split that one into the three different boots logs it contained, will upload the one where it didn't work).

On *this* cold-boot, hrev56140 networking got "Ready" without intervention, and seems to be working so far after browsing a couple of pages at least). Really weird. I'll triple check to see if there's any pattern related to warm vs cold boots.

(Do you see the same error messages cocobean does in any of them?)

I definitively remember seing that KERN: [rtl81xx] (re) No memory for jumbo RX buffers at least once.

And... it is present on the syslog that I'll attach next.

Hope that help. Again, really weird that (for) now seems to be working.

[bipolar]

Syslog of hrev564140 with "no memory for jumbo RX buffers"

[bipolar]

For what it's worth: can't find any pattern regarding cold or warm boots. Today the cold boot ended on a "Ready" but not responsive network, and after trying disabling/enabling it, those "no memory for jumbo RX buffers" message appeared on the syslog (there were none up to that point).

But... warm-rebooting somehow worked this time (didn't the other days), and now I have working network, good enough as to update to hrev56141 (haven't rebooted yet).

BTW... nightly images and .hpkgs seem to be stuck at hrev56141... I was expecting to update at least to hrev56145 (almost 2 days old, to see if it helped with this issue).

[cocobean]

@bipolar - You can update to hrev56147 as of today. Fix pending (mentioned in forum). Seemingly, my download speed averages 2x faster <= hrev56138. Youtube video streaming seems pretty solid and memory usage using Web+ seems flat - once established, No TX/RX packet errors/drops/mcasts after four hours streaming several YouTube videos. No memory thrashing or any high memory leaks/usage.

In ifconfig, the MTU setting is 9004 vs 9000. Now, I can manually set the MTU from 1500->9004, but not any higher - like up to the 9014->9216 range. Just an experiment.

Note: Interestingly, earlier revisions of the Realtek 8110S, 8111, 8168, 8169, and 8169S chips are hardware capable of transmitting jumbo frames up to 7440 bytes in size. Specs says drivers should handle jumbo franes up to 9000 bytes. The TX/RX buffer size default driver settings might cause the syslog issue.

[waddlesplash]

Please retest after hrev56149.

[bipolar]

Updated to hrev56151.

• First reboot ended up with no network (stuck at "Configuring"). Deleted syslog to get a clean one on the next boot...

• Second boot: network seems to be pretty functional this time (saved this syslog, just in case). Deleted syslog and rebooted...

• Third boot: no network. The error regarding jumbo frames appears on syslog. Will attach it.

FWIW, MTU value as reported by ifconfig went from 1500 in hrev56112, to 4082 in hrev56141 and now in hrev56151. Same 4082 value appears with and without working network.

In both a hrev56112 with default MTU and when hrev56151 works with MTU = 4082, I manage to reach the limit of my internet connection (tested with www.speedtest.net on Falkon): around 25 Mbps down / 30 Mbps up (same values I get on Win/Lin, and yes, I get faster uploads than downloads).

I guess my internet is too slow to notice a difference on MTUs.

Now on hrev56112... will attach the syslogs. The "not-working" includes that mention of "no memory for jumbo frames" while the "working" does not.

[bipolar]

hrev56151 working network

[bipolar]

hrev56151 network not working

[cocobean]

1. Bumpoed to hrev56151, shutdown -r (warm reboot). Result: Auto-config didn't complete properly.

After a second reboot, network auto-config worked and Internet connectivity worked as expected.

This is not reliable yet (i.e. 5-10 consistent warm reboots with working network auto-config successes) - compared to Haiku R1B3.

DHCP client - I noticed the DHCP_DISCOVER spamming to my DHCP server. Possibly, this caused another issue. Shut down the computer, waited 1-2 hours, cold started the computer and network auto-config worked with a proper DHCP handshake. 'DHCP status = No error'

No 'no memory for jumbo RX buffers' error appearing in syslog when everything works. This error appears when the NIC does not properly initialize correctly during a network disable/re-enable.

[waddlesplash]

Thanks for testing. I missed a case, hrev56152 should hopefully resolve the intermittent "jumbo frames" errors and fully fix this, I hope. Updates should be available in a few hours.

[cocobean]

Bumped to hrev56154. Issue resolved. Tested: NIC & DHCP disabled/re-enabled 10 times -

Result: All successful.

The only issue is the display of the link speed when the NIC is enabled. The link speed info disappears in network GUI when the NIC is enabled versus disabled. I can make that a separate ticket.

Ex. ifconfig - /dev/net/<driver>: "Media type: 1 GBit, 1000BASE-T"

Otherwise, you can close this ticket.

[bipolar]

Reporting back after updating to hrev56154:

In the following four reboots network got auto-configured properly, and I was able to do some light web browsing without much problems (other than the usual ones due to the browsers themselves) in each one of them.

No more "no memory for jumbo RX frames" in the syslog files until now, nor network stuck at "Configuring".

Thanks for your work Augustin!

[waddlesplash]

Very good. Thanks for testing!