Hello,

 

I've noticed a strange kernel error appearing in my syslog. I haven't noticed anything abnormal occuring, but I'm curious what the error is.

 

Jan  7 22:24:00 Beast kernel: ------------[ cut here ]------------
Jan  7 22:24:00 Beast kernel: WARNING: CPU: 13 PID: 10302 at net/netfilter/nf_conntrack_core.c:1210 __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack]
Jan  7 22:24:00 Beast kernel: Modules linked in: xt_mark nft_chain_nat nft_compat nf_tables tun xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype br_netfilter xfs nvidia_uvm(PO) md_mod tcp_diag inet_diag nct6687(O) nct6683 ip6table_filter ip6_tables iptable_filter ip_tables x_tables efivarfs bridge stp llc macvtap macvlan tap r8168(O) r8125(O) nvidia_drm(PO) nvidia_modeset(PO) zfs(PO) edac_mce_amd intel_rapl_msr zunicode(PO) edac_core intel_rapl_common iosf_mbi zzstd(O) kvm_amd nvidia(PO) zlua(O) video zavl(PO) kvm icp(PO) drm_kms_helper drm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel sha512_ssse3 sha256_ssse3 zcommon(PO) sha1_ssse3 aesni_intel znvpair(PO) spl(O) crypto_simd cryptd wmi_bmof backlight rapl i2c_piix4 nvme i2c_core syscopyarea k10temp sysfillrect ccp joydev ahci sysimgblt fb_sys_fops nvme_core libahci wmi tpm_crb tpm_tis tpm_tis_core tpm acpi_cpufreq
Jan  7 22:24:00 Beast kernel: button unix [last unloaded: r8168(O)]
Jan  7 22:24:00 Beast kernel: CPU: 13 PID: 10302 Comm: kworker/u64:16 Tainted: P           O       6.1.64-Unraid #1
Jan  7 22:24:00 Beast kernel: Hardware name: Micro-Star International Co., Ltd. MS-7C91/MAG B550 TOMAHAWK (MS-7C91), BIOS A.F0 10/19/2023
Jan  7 22:24:00 Beast kernel: Workqueue: events_unbound macvlan_process_broadcast [macvlan]
Jan  7 22:24:00 Beast kernel: RIP: 0010:__nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack]
Jan  7 22:24:00 Beast kernel: Code: 44 24 10 e8 e2 e1 ff ff 8b 7c 24 04 89 ea 89 c6 89 04 24 e8 7e e6 ff ff 84 c0 75 a2 48 89 df e8 9b e2 ff ff 85 c0 89 c5 74 18 <0f> 0b 8b 34 24 8b 7c 24 04 e8 18 dd ff ff e8 93 e3 ff ff e9 72 01
Jan  7 22:24:00 Beast kernel: RSP: 0018:ffffc90000504d98 EFLAGS: 00010202
Jan  7 22:24:00 Beast kernel: RAX: 0000000000000001 RBX: ffff888818b38500 RCX: 0a456f776ef229c0
Jan  7 22:24:00 Beast kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888818b38500
Jan  7 22:24:00 Beast kernel: RBP: 0000000000000001 R08: 36ddc1f5a452312d R09: b62cdf918747119d
Jan  7 22:24:00 Beast kernel: R10: a5cbddf44a7024a8 R11: ffffc90000504d60 R12: ffffffff82a14d00
Jan  7 22:24:00 Beast kernel: R13: 0000000000024374 R14: ffff8887daad8700 R15: 0000000000000000
Jan  7 22:24:00 Beast kernel: FS:  0000000000000000(0000) GS:ffff888fdeb40000(0000) knlGS:0000000000000000
Jan  7 22:24:00 Beast kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jan  7 22:24:00 Beast kernel: CR2: 00001458844f769c CR3: 0000000295fde000 CR4: 0000000000350ee0
Jan  7 22:24:00 Beast kernel: Call Trace:
Jan  7 22:24:00 Beast kernel: <IRQ>
Jan  7 22:24:00 Beast kernel: ? __warn+0xab/0x122
Jan  7 22:24:00 Beast kernel: ? report_bug+0x109/0x17e
Jan  7 22:24:00 Beast kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack]
Jan  7 22:24:00 Beast kernel: ? handle_bug+0x41/0x6f
Jan  7 22:24:00 Beast kernel: ? exc_invalid_op+0x13/0x60
Jan  7 22:24:00 Beast kernel: ? asm_exc_invalid_op+0x16/0x20
Jan  7 22:24:00 Beast kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack]
Jan  7 22:24:00 Beast kernel: ? __nf_conntrack_confirm+0x9e/0x2b0 [nf_conntrack]
Jan  7 22:24:00 Beast kernel: ? nf_nat_inet_fn+0x126/0x1a8 [nf_nat]
Jan  7 22:24:00 Beast kernel: nf_conntrack_confirm+0x25/0x54 [nf_conntrack]
Jan  7 22:24:00 Beast kernel: nf_hook_slow+0x3d/0x96
Jan  7 22:24:00 Beast kernel: ? ip_protocol_deliver_rcu+0x164/0x164
Jan  7 22:24:00 Beast kernel: NF_HOOK.constprop.0+0x79/0xd9
Jan  7 22:24:00 Beast kernel: ? ip_protocol_deliver_rcu+0x164/0x164
Jan  7 22:24:00 Beast kernel: __netif_receive_skb_one_core+0x77/0x9c
Jan  7 22:24:00 Beast kernel: process_backlog+0x8c/0x116
Jan  7 22:24:00 Beast kernel: __napi_poll.constprop.0+0x2b/0x124
Jan  7 22:24:00 Beast kernel: net_rx_action+0x159/0x24f
Jan  7 22:24:00 Beast kernel: __do_softirq+0x129/0x288
Jan  7 22:24:00 Beast kernel: do_softirq+0x7f/0xab
Jan  7 22:24:00 Beast kernel: </IRQ>
Jan  7 22:24:00 Beast kernel: <TASK>
Jan  7 22:24:00 Beast kernel: __local_bh_enable_ip+0x4c/0x6b
Jan  7 22:24:00 Beast kernel: netif_rx+0x52/0x5a
Jan  7 22:24:00 Beast kernel: macvlan_broadcast+0x10a/0x150 [macvlan]
Jan  7 22:24:00 Beast kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan]
Jan  7 22:24:00 Beast kernel: process_one_work+0x1ab/0x295
Jan  7 22:24:00 Beast kernel: worker_thread+0x18b/0x244
Jan  7 22:24:00 Beast kernel: ? rescuer_thread+0x281/0x281
Jan  7 22:24:00 Beast kernel: kthread+0xe7/0xef
Jan  7 22:24:00 Beast kernel: ? kthread_complete_and_exit+0x1b/0x1b
Jan  7 22:24:00 Beast kernel: ret_from_fork+0x22/0x30
Jan  7 22:24:00 Beast kernel: </TASK>
Jan  7 22:24:00 Beast kernel: ---[ end trace 0000000000000000 ]---

 

Please find the diagnostics zip file attached below.

 

beast-diagnostics-20240107-2249.zip

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

8 minutes ago, JorgeB said:

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

 

Hi JorgeB,

 

I use macvlan as it seems to work better with Ubiquity, specifically my UDM-PRO. I find that ipvlan doesn't allow the UDM-PRO to properly identify client information for my dockers.

 

Is there possibly another way around this? Thank you for your prompt response too!

 

 

Just now, mchristo said:

 

Hi JorgeB,

 

I use macvlan as it seems to work better with Ubiquity, specifically my UDM-PRO. I find that ipvlan doesn't allow the UDM-PRO to properly identify client information for my dockers.

 

Is there possibly another way around this? Thank you for your prompt response too!

 

 

If you want to continue using macvlan make sure that bridging is disabled on eth0 (as mentioned in Release notes).

23 minutes ago, itimpi said:

If you want to continue using macvlan make sure that bridging is disabled on eth0 (as mentioned in Release notes).

 

Perfect! Thank you for this - completely forgot that was still enabled.