Diagnostics attached.

 

And copy of the error there.

 

I have been dealing with drives failing, most recently my cache drives have been replaced and I think another drive is on the way out, but not entirely sure.

 

I have been seeing a random kernel panic here and there, but nothing really seems to come from it. I haven't noticed a big problem. Anything y'all could find would be super helpful.

 

I am on the latest release version of UnRAID.

 

 Feb 05 16:20:40 Tower kernel ------------[ cut here ]------------
Feb 05 16:20:40 Tower kernel WARNING: CPU: 10 PID: 14705 at net/netfilter/nf_conntrack_core.c:1208 __nf_conntrack_confirm+0xa5/0x2cb [nf_conntrack]
Feb 05 16:20:40 Tower kernel Modules linked in: nvidia_uvm(PO) xt_mark xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle iptable_mangle vhost_net tun vhost vhost_iotlb tap macvlan veth xt_nat xt_tcpudp xt_conntrack nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype br_netfilter xfs md_mod i2c_dev it87 hwmon_vid efivarfs ip6table_nat iptable_nat xt_MASQUERADE nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha ip6table_filter ip6_tables iptable_filter ip_tables x_tables bridge stp llc mlx4_en mlx4_core igb i2c_algo_bit nvidia_drm(PO) nvidia_modeset(PO) edac_mce_amd edac_core nvidia(PO) kvm_amd btusb drm_kms_helper btrtl btbcm kvm gigabyte_wmi wmi_bmof crct10dif_pclmul mxm_wmi crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel btintel drm crypto_simd cryptd mpt3sas bluetooth i2c_piix4 backlight nvme tpm_crb raid_class rapl ahci ecdh_generic
Feb 05 16:20:40 Tower kernel syscopyarea k10temp ccp scsi_transport_sas sysfillrect tpm_tis ecc i2c_core libahci sysimgblt tpm_tis_core nvme_core fb_sys_fops thermal tpm wmi button acpi_cpufreq unix [last unloaded: mlx4_core]
Feb 05 16:20:40 Tower kernel CPU: 10 PID: 14705 Comm: kworker/10:0 Tainted: P           O      5.19.17-Unraid #2
Feb 05 16:20:40 Tower kernel Hardware name: Gigabyte Technology Co., Ltd. X570 AORUS ULTRA/X570 AORUS ULTRA, BIOS F36 12/26/2022
Feb 05 16:20:40 Tower kernel Workqueue: events macvlan_process_broadcast [macvlan]
Feb 05 16:20:40 Tower kernel RIP: 0010:__nf_conntrack_confirm+0xa5/0x2cb [nf_conntrack]
Feb 05 16:20:40 Tower kernel Code: c6 48 89 44 24 10 e8 dd e2 ff ff 8b 7c 24 04 89 da 89 c6 89 04 24 e8 56 e6 ff ff 84 c0 75 a2 48 8b 85 80 00 00 00 a8 08 74 18 <0f> 0b 8b 34 24 8b 7c 24 04 e8 16 de ff ff e8 2c e3 ff ff e9 7e 01
Feb 05 16:20:40 Tower kernel RSP: 0018:ffffc90000428da0 EFLAGS: 00010202
Feb 05 16:20:40 Tower kernel RAX: 0000000000000188 RBX: 0000000000000000 RCX: 2e41999267242af4
Feb 05 16:20:40 Tower kernel RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa033d360
Feb 05 16:20:40 Tower kernel RBP: ffff88810699bd00 R08: 297ecf2452eb7055 R09: 8933e6503df58c8a
Feb 05 16:20:40 Tower kernel R10: c6454499f3281efa R11: 91002ba426123045 R12: ffffffff82909480
Feb 05 16:20:40 Tower kernel R13: 0000000000026048 R14: ffff88860bd62800 R15: 0000000000000000
Feb 05 16:20:40 Tower kernel FS:  0000000000000000(0000) GS:ffff888ffea80000(0000) knlGS:0000000000000000
Feb 05 16:20:40 Tower kernel CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 05 16:20:40 Tower kernel CR2: 000030f7395a2030 CR3: 00000003fcb22000 CR4: 0000000000750ee0
Feb 05 16:20:40 Tower kernel PKRU: 55555554
Feb 05 16:20:40 Tower kernel Call Trace:
Feb 05 16:20:40 Tower kernel <IRQ>
Feb 05 16:20:40 Tower kernel nf_conntrack_confirm+0x25/0x54 [nf_conntrack]
Feb 05 16:20:40 Tower kernel nf_hook_slow+0x3d/0x96
Feb 05 16:20:40 Tower kernel ? ip_protocol_deliver_rcu+0x164/0x164
Feb 05 16:20:40 Tower kernel NF_HOOK.constprop.0+0x79/0xd9
Feb 05 16:20:40 Tower kernel ? ip_protocol_deliver_rcu+0x164/0x164
Feb 05 16:20:40 Tower kernel __netif_receive_skb_one_core+0x77/0x9c
Feb 05 16:20:40 Tower kernel process_backlog+0x8c/0x116
Feb 05 16:20:40 Tower kernel __napi_poll.constprop.0+0x2b/0x124
Feb 05 16:20:40 Tower kernel net_rx_action+0x159/0x24f
Feb 05 16:20:40 Tower kernel __do_softirq+0x129/0x288
Feb 05 16:20:40 Tower kernel do_softirq+0x7f/0xab
Feb 05 16:20:40 Tower kernel </IRQ>
Feb 05 16:20:40 Tower kernel <TASK>
Feb 05 16:20:40 Tower kernel __local_bh_enable_ip+0x4c/0x6b
Feb 05 16:20:40 Tower kernel netif_rx+0x52/0x5a
Feb 05 16:20:40 Tower kernel macvlan_broadcast+0x10a/0x150 [macvlan]
Feb 05 16:20:40 Tower kernel macvlan_process_broadcast+0xbc/0x12f [macvlan]
Feb 05 16:20:40 Tower kernel process_one_work+0x1ab/0x295
Feb 05 16:20:40 Tower kernel worker_thread+0x18b/0x244
Feb 05 16:20:40 Tower kernel ? rescuer_thread+0x281/0x281
Feb 05 16:20:40 Tower kernel kthread+0xe7/0xef
Feb 05 16:20:40 Tower kernel ? kthread_complete_and_exit+0x1b/0x1b
Feb 05 16:20:40 Tower kernel ret_from_fork+0x22/0x30
Feb 05 16:20:40 Tower kernel </TASK>
Feb 05 16:20:40 Tower kernel ---[ end trace 0000000000000000 ]---

 

tower-diagnostics-20230205-1737.zip

Macvlan docker network type is the likely cause of your kernel panics, this is a known issue and such a common problem in recent releases that it is no longer a default setting.

The fix in this case is to change docker network type from macvlan to ipvlan, which involves stopping the docker service:

• go to SETTINGS > DOCKER
• with advanced view toggled (top right), set Enable Docker: No,
• then set Docker custom network type: ipvlan

Once complete:

• set Enable Docker: Yes to restart docker service.

Report back with fresh diagnostics if kernel panics continue.

Thanks, @tjb_altf4

 

Appreciate the reply. Will give it a go and see how it does.