I get random disconnects constantly. I've tried swapping ports on the router and the problem persists. I grabbed this snippet from the logs as soon as I could reconnect. Possibly failing NIC? Thanks for any advice.

 

https://privatebin.net/?be62b314f24db319#FDoJCPPp444QHEmRtKfYcAWgi33gfKnoP7dSJnVaqf1b

Edited May 18, 20242 yr by Shomesomesho

Please go to unraid webui > tools > diagnostic and post that file here.

That looks like the macvaln bug trace either disable bridging under network settings and/or set docker custom network to ipvlan.

The kernel panic apears to start when the baord discovers a new interface? did you recently change hardware?

My motherboard has 2 NICs. I experienced the disconnects using the r8125/2.5gbps port. In my haste to troubleshoot this on my own, I attempted switching to the other 1gbps port on the board. I'm not sure if that's going to throw a lot of unrelated info into the attached Diagnostic.

 

I had my network and Docker settings with the "new method" outlined in the 6.12.4 release notes.

Settings > Network Settings > eth0 > Enable Bonding = Yes or No, either work with this solution

Settings > Network Settings > eth0 > Enable Bridging = No (this will automatically enable macvlan)

Settings > Docker > Host access to custom networks = Enabled

 

Per your advise, I have turned bridging back on, and set `Docker custom network type` to ipvlan. Should I also disable `Host access to custom networks` ?

 

I have not changed any hardware recently.

 

Thank you very much for your help. I'm hoping just the ipvlan change will stop the problem.

unraid-diagnostics-20240518-2149.zip

Edited May 19, 20242 yr by Shomesomesho

Enabling bond0 is ok... yes, I recommend host access to docker to be set to enable. That more a question of do you want your docker to talk to other thing on the lan. Some docker services would require this access others not so much.

To clarify, you now have bonding on, Bridging on Docker set to ipvlan and host access set to enable?

FYI:
there is a known issue with unraid kernal and those relteck nics.
Something on th lines of:
If you have br0 and bond0 there is a linux issues with MTU as a 2.5 GB nic may not support 1000 / 100 / 10 base-t.

Please install the realtek plugin and see if that helps. I believe you want the 1st option:

Edited May 19, 20242 yr by bmartino1

I have bonding disabled, so I now only have br0 as of making the bridging change 30 minutes ago.

 

I have that Realtek plugin installed already.

 

Thank you.

Just now, Shomesomesho said:

I have bonding disabled, so I now only have br0 as of making the bridging change 30 minutes ago.

 

I have that Realtek plugin installed already.

 

Thank you.

thank you for that clarification. The diagnostic didn't show that plugin instaled/enabled, but did show the modprobe of disabling Unraids realtek kernal driver.

Unless you need to use macvlan I recommend that you stick with ipvlan docker network driver. the kernel panic per past bin and log was indeed a macvlan trace bug.

If you want to use macvlan plese see the correct setup here.

The question now is, using the FCP (fix common plugin) tool do you have another trace or kernal panic?

I don't think I need macvlan, so unless that changes in the future, I'll leave it on ipvlan. Thank you for the link.

 

I'm not sure what you mean about the FCP plugin. I do already have it installed. Is there a tool included that I should run besides the "rescan" button?

Edited May 19, 20242 yr by Shomesomesho

Honesty not sure that a question for Squid the dev of FCP plugin.

For my use case when the macvlan trace bug happed to me: No, the rescan button is the option I use to double-check and confirm. Per diagnostic posted, I didn't see any other kernel panics. After you fixed the docker setting to use ipvlan.

When reading the log to tell if its macvlan issues the Modules linked will have macvlan:


Have fun and good luck.

Thank you for your help!