Kernel Issues even after completely rebuilding server with new mobo, CPU, and RAM

[Mattaton]

I've been having issues for the past couple weeks where my server would crash and on the connected monitor there would be references to Kernel panic. See this thread: https://forums.unraid.net/topic/146044-past-two-days-server-crashes-with-kernel-panic/

 

 

I had checked all drive SMART data, several parity checks were perfect, so I assumed it had to be hardware issue. So, I replaced the motherboard, CPU, and RAM with an Intel-based setup to rule out AMD-based issues.

 

Now today I tried to log in to my server and it took forever to load the GUI. I also couldn't SSH into it. After 5 minutes or so, the webGUI finally came up. I checked the logs and it's full of kernel lines. Diagnostics attached.

Lines like this with a bunch of other stuff that means nothing to me:

Oct 11 09:54:00 TyreeMedia kernel: CPU: 13 PID: 6398 Comm: kworker/u40:0 Tainted: P        W  O       6.1.49-Unraid #1
Oct 11 09:54:00 TyreeMedia kernel: CPU: 5 PID: 15710 Comm: kworker/u40:4 Tainted: P        W  O       6.1.49-Unraid #1

 

Any help is appreciated here. I hate to think I spent all that money to switch to Intel just to have it still do these kernel errors.

 

Thanks!

Matt

tyreemedia-diagnostics-20231011-0955.zip

[Mattaton]

Not sure if this is connected, but I'm seeing this one core pegged for several minutes now.

[Mattaton]

....AAANNNDDD it just went unresponsive again. I think full crash this time.

Uuuggghhh, I feel sick.

Edited October 11, 2023 by Mattaton

[JorgeB]

Oct 11 01:21:46 TyreeMedia kernel: macvlan_broadcast+0x10a/0x150 [macvlan]
Oct 11 01:21:46 TyreeMedia kernel: ? _raw_spin_unlock+0x14/0x29
Oct 11 01:21:46 TyreeMedia kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]

Macvlan call traces will usually end up crashing the server, swit to ipvlan (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)).

[Mattaton]

I'll have to get my server back up, but I'm pretty sure I had already switched to ipvlan given the warnings/instructions in the latest release info.

I'll give it a look as soon as I get things running again.

Thanks

[JorgeB]

10 minutes ago, Mattaton said:

I'll have to get my server back up, but I'm pretty sure I had already switched to ipvlan

You can only get macvlan call traces if macvlan is being used.

[Mattaton]

1 minute ago, JorgeB said:

You can only get macvlan call traces if macvlan is being used.

Makes total sense. Just surprised me since I remember going through the release notes and those settings. Maybe I didn't save the changes. I have no idea. 😄

I hope that's the problem because it's an easy fix!

[Mattaton]

2 hours ago, JorgeB said:

You can only get macvlan call traces if macvlan is being used.

It was indeed set to macvlan. I don't know what my reasoning was for keeping it on macvlan other than thinking this was important,

Quote

The macvlan type of network allows direct connection to the physical network.

since I do access things on the local network from some of my containers.

 

At any rate, we'll see if this gets rid of the frequent crashes. 

 

Thanks!

[JorgeB]

ipvlan should also allow that, but you can use macvaln without the problems with v6.12.4, see the release notes.

[Mattaton]

8 minutes ago, JorgeB said:

but you can use macvaln without the problems with v6.12.4, see the release notes.

I am on 6.12.4, but I hadn't done the disable bridging settings and all that. I'll see if ipvlan causes any issues and only switch if I have to.

If there's no real advantage to being on macvlan, I don't need to stir the water. 🙂 

Thanks!