Mattaton Posted October 11, 2023 Share Posted October 11, 2023 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 Quote Link to comment
Mattaton Posted October 11, 2023 Author Share Posted October 11, 2023 Not sure if this is connected, but I'm seeing this one core pegged for several minutes now. Quote Link to comment
Mattaton Posted October 11, 2023 Author Share Posted October 11, 2023 (edited) ....AAANNNDDD it just went unresponsive again. I think full crash this time. Uuuggghhh, I feel sick. Edited October 11, 2023 by Mattaton Quote Link to comment
Solution JorgeB Posted October 11, 2023 Solution Share Posted October 11, 2023 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)). Quote Link to comment
Mattaton Posted October 11, 2023 Author Share Posted October 11, 2023 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 Quote Link to comment
JorgeB Posted October 11, 2023 Share Posted October 11, 2023 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. Quote Link to comment
Mattaton Posted October 11, 2023 Author Share Posted October 11, 2023 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! Quote Link to comment
Mattaton Posted October 11, 2023 Author Share Posted October 11, 2023 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! Quote Link to comment
JorgeB Posted October 11, 2023 Share Posted October 11, 2023 ipvlan should also allow that, but you can use macvaln without the problems with v6.12.4, see the release notes. Quote Link to comment
Mattaton Posted October 11, 2023 Author Share Posted October 11, 2023 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! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.