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

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

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

Uuuggghhh, I feel sick.

Edited October 11, 20232 yr by Mattaton

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)).

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

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.

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!

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!

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

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!