Call traces in 6.12.4

[wayner]

I have received an error for macvlan call traces.  I was going to make the change from macvlan to ipvlan, but I have a Ubiquiti router and other networking hardware. 

 

The release notes say: 

Quote

However, some users have reported issues with port forwarding from certain routers (Fritzbox) and reduced functionality with advanced network management tools (Ubiquity) when in ipvlan mode.

What sort of reduced functionality is this referring to?  And does this affect all Ubiquiti users or some?

 

My system is fairly simple, I have one NIC, and I use br0 for a few dockers, bridge and host for a few others.  What should I be looking for when it comes to network issues?

[sonic6]

6 hours ago, wayner said:

What should I be looking for when it comes to network issues?

try the simplest solution now:
read the 6.12.4 changelog, to the manually steps, update to 6.4.12 and use eth0 instead of br0.

[wayner]

3 hours ago, sonic6 said:

try the simplest solution now:
read the 6.12.4 changelog, to the manually steps, update to 6.4.12 and use eth0 instead of br0.

Sorry, but it isn't clear what the simplest solution is from the changelog.

 

According to the changelog Isn't the first step to change from macvlan to ipvlan?

 

But are you saying to stay with macvlan and change from br0 to eth0?  And if I do this then do I have to change the bonding, bridging and access to host network settings for eth0?

 

Which should I try first? Or should I do both?

[sonic6]

15 minutes ago, wayner said:

Sorry, but it isn't clear what the simplest solution is from the changelog.

you are right, the first try is the change to ipvlan, but of your hardware need a seperated MAC-Address per device, or had other conflicts with ipvlan, then use "eth0".

(i am using a fritzbox, which needs seperated MAC-Addresses per device).

 

 

10 hours ago, wayner said:

but I have a Ubiquiti router

with your hardware i would strait go to the "eth0" solution.

 

18 minutes ago, wayner said:

But are you saying to stay with macvlan and change from br0 to eth0?

yes, i would do that. read carefully the changelog.
in short: stop docker, disable array autostart, update unraid, reboot unraid, disable bridging in network settings, activate "host access" in docker settings, start docker, check if all br0 container are started.

if not all container started, check if they changed from br0 to eth0. if some container disapeared go to "add container" on docker page, choose your template. change from br0 to bridge, start the container, edit the container again and change it to eth0.

 

after all runs activate the array autostart again.

 

now you should check you router etc, because the MAC-Addresses of your container could be change, also there is a second MAC-Address with the same IP address like your unraid host. this is normal.

[wayner]

Thanks.  I am already upgraded to 6.12.4, so I just need to follow the other steps.  I am getting the macvlan trace errors, but as far as I can determine it has not caused any problems - yet.

 

I have had problems with my cache disk getting corrupted that happened with 6.12.4, but not with 6.11.5, but I have changed the cache disk from BTRFS to XFS, so hopefully that issue is now stable.  

[thecode]

5 minutes ago, wayner said:

Thanks.  I am already upgraded to 6.12.4, so I just need to follow the other steps.  I am getting the macvlan trace errors, but as far as I can determine it has not caused any problems - yet.

 

I have had problems with my cache disk getting corrupted that happened with 6.12.4, but not with 6.11.5, but I have changed the cache disk from BTRFS to XFS, so hopefully that issue is now stable.  

You should not get any macvlan errors on 6.12.4 as far as I understand, can you post a sample log trace here? or diagnostics?

 

[wayner]

4 minutes ago, thecode said:

You should not get any macvlan errors on 6.12.4 as far as I understand, can you post a sample log trace here? or diagnostics?

 

I will do that later tonight when I get home as I don't have access right now to my server.  FCP was highlighting these issues in its report.

[JorgeB]

27 minutes ago, thecode said:

You should not get any macvlan errors on 6.12.4

You still get them if bridging is enabled and docker network is set to macvlan, should not get them with ipvlan or bridging disabled.

[sonic6]

also the fix common problem plugin  reported nearly every trace as a "mac macvlan trace". don't know if that is fixed.

[wayner]

What problems will these macvlan errors cause?  I am getting these errors in my logs, but so far I don't know if it has caused any functional problems with my system.

[JorgeB]

4 minutes ago, wayner said:

What problems will these macvlan errors cause?

In same cases they can make the server crash, and can be one or two days after the call traces.

[wayner]

This is from my log.  Are these the macvlan call trace errors?

 

Sep 13 07:57:06 Portrush kernel: CPU: 10 PID: 12285 Comm: rpcd_lsad Tainted: P    B D W  O       6.1.49-Unraid #1
Sep 13 07:57:06 Portrush kernel: Hardware name: ASUS System Product Name/PRIME B560-PLUS, BIOS 0820 04/27/2021
Sep 13 07:57:06 Portrush kernel: Call Trace:

 

[thecode]

13 minutes ago, wayner said:

This is from my log.  Are these the macvlan call trace errors?

 

Sep 13 07:57:06 Portrush kernel: CPU: 10 PID: 12285 Comm: rpcd_lsad Tainted: P    B D W  O       6.1.49-Unraid #1
Sep 13 07:57:06 Portrush kernel: Hardware name: ASUS System Product Name/PRIME B560-PLUS, BIOS 0820 04/27/2021
Sep 13 07:57:06 Portrush kernel: Call Trace:

 

I think this is related to Samba, it is definitely not the famous macvlan call trace

[wayner]

OK thanks.  Perhaps FCP is warning me about old errors that are no longer present since I upgraded to 6.12.4?  But my system has only been up and running for 16 hours.  But FCP gives my five occurrences of "macvlan call traces found" that would indicate errors.  But I don't see anything in my log about macvlan call traces found other than those Call Trace issues shown above or entries generated by FCP.  And they show up in red.

[wayner]

Here is my diagnostics file  if that helps

portrush-diagnostics-20230913-1758.zip

[ljm42]

2 hours ago, wayner said:

OK thanks.  Perhaps FCP is warning me about old errors that are no longer present since I upgraded to 6.12.4?  But my system has only been up and running for 16 hours.  But FCP gives my five occurrences of "macvlan call traces found" that would indicate errors.  But I don't see anything in my log about macvlan call traces found other than those Call Trace issues shown above or entries generated by FCP.  And they show up in red.

 

Your system is getting call traces, and they implicate macvlan. Bridging is still enabled so it doesn't look like you've made the changes recommended for 6.12.4?

 

Note that upgrading to 6.12.4 is not enough, you need to read the release notes and make some changes in order to avoid call traces and the eventual crash they cause

 

Quote

What sort of reduced functionality is this referring to?  And does this affect all Ubiquiti users or some?

 

For most systems, switching from macvlan to ipvlan is the simplest option and is a good place to start.  If you later discover your Ubiquity isn't doing everything you want, then you can investigate the other option mentioned in the release notes.  This may help too:

https://forums.unraid.net/topic/144798-ipvlan-unifi-need-help-understanding-this-statement/#comment-1304184

 

 

If you continue having issues, please start a new thread. This thread is specifically for people who want to use two NICs to avoid the call traces. It is still a viable solution, but in 6.12.4 there is a better way. NVM I moved all your posts to a new thread

 

Edit: sorry I updated this reply a few times. Think I'm done now : ) 

[wayner]

I wasn't sure exactly what changes to make so I hadn't made any yet.  I have now changed to ipvlan, Set Bridging to No, and kept Bonding at Yes.  Dockers were already set to allow Custom Networks.

 

My dockers are now using bond0 as the custom network interface.  I do not have an option to user eth0.  Is that OK?  Is the reason that I don't see the eth0 option because Enable Bonding is set to Yes.  If I select No then will the Bond0 option disappear and the eth0 option appear?

 

Does it matter what I use for Bonding as the release notes says either work.

[ljm42]

21 hours ago, wayner said:

I wasn't sure exactly what changes to make so I hadn't made any yet.  I have now changed to ipvlan, Set Bridging to No, and kept Bonding at Yes.  Dockers were already set to allow Custom Networks.

 

It seems that you are trying both fixes from the release notes rather than just one:

• Fix 1: change macvlan to ipvlan. If you are happy with that then you are done.
• Fix 2: if you want to use macvlan then disable bridging. This removes the option for ipvlan and always enables macvlan

At this point you are using the second fix. That is fine.

 

I modified the release notes to try and make it more clear that if you change macvlan to ipvlan, you are done! No more changes needed.

 

21 hours ago, wayner said:

My dockers are now using bond0 as the custom network interface.  I do not have an option to user eth0.  Is that OK? 

 

If bonding is enabled you will see bond0, if bonding is disabled you will see eth0. Either works fine.

 

 

[wayner]

I have Ubiquiti hardware, including as my router (USG) and I use the Ubiquiti Unifi hardware.  So I thought that I needed to also do the second fix as well.