FS#2346 - [kmod-sched-cake] infrequent kernel crashes and unknown symbol errors

[openwrt-bot]

n8v8R:

Supply the following if possible:

• 19.07
• 4.14.131 armv7l (arm_cortex-a9_vfpv3)
• kmod-sched-cake 4.14.131+2019-03-12-057c7388-1-d7317cbbddf2a7868a9735d59f4d4520.0

---

during boot time

sch_cake: Unknown symbol nf_conntrack_find_get (err 0)
sch_cake: Unknown symbol nf_ct_get_tuplepr (err 0)

not sure about potential correlation but observing infrequent crashed with what seems to be a common dominator:

• Unable to handle kernel paging request at virtual address
• PC is at nf_conntrack_in+0xdc/0x714 [nf_conntrack]

---

• debug data/info

opkg list-installed conntrack

conntrack - 2018-05-01-88610abe-1.0
iptables-mod-conntrack-extra - 1.8.2-3.51
kmod-ipt-conntrack - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
kmod-ipt-conntrack-extra - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
kmod-nf-conntrack - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
kmod-nf-conntrack-netlink - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
kmod-nf-conntrack6 - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
libnetfilter-conntrack - 2018-05-01-3ccae9f5-2.0

sysctl -a | grep track -> output attached

crash logs -> attached

[openwrt-bot]

n8v8R:

quite some time (some hours) after the boot the log is also displaying:

nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead.

[openwrt-bot]

n8v8R:

adding another (fresh) crash log which again hints @ nf_conntrack_in+0x14c/0x714

[openwrt-bot]

moeller0:

I took the liberty to post a reference to this on the cake repository, see [[https://github.com/dtaht/sch_cake/issues/119]] That might be a better place for discussing this issue.

[openwrt-bot]

n8v8R:

The last crash log 3 happened also after an attempt to weed out a culprit by removing non-essential conntrack modules, being left with:

iptables-mod-conntrack-extra - 1.8.2-3.51
kmod-ipt-conntrack - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
kmod-ipt-conntrack-extra - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
kmod-nf-conntrack - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0
kmod-nf-conntrack6 - 4.14.131-1-d7317cbbddf2a7868a9735d59f4d4520.0

[openwrt-bot]

tohojo:

I'm a bit puzzled by this part:

sch_cake: Unknown symbol nf_conntrack_find_get (err 0) sch_cake: Unknown symbol nf_ct_get_tuplepr (err 0)

I would expect this would keep sch_cake from loading. Are you using it?

[openwrt-bot]

n8v8R:

opkg whatdepends kmod-sched-cake

Root set:
kmod-sched-cake
What depends on root set
sqm-scripts 1.3.0-1.51 depends on kmod-sched-cake

[openwrt-bot]

tohojo:

But you are not using it? Is sch_cake in lsmod?

[openwrt-bot]

n8v8R:

lsmod | grep sch_cake

nf_conntrack 77824 31 sch_cake,ipt_MASQUERADE,xt_state,xt_nat,xt_helper,xt_conntrack,xt_connmark,xt_connlimit,xt_connbytes,xt_REDIRECT,xt_CT,nft_redir_ipv6,nft_redir_ipv4,nft_redir,nft_nat,nft_masq_ipv6,nft_masq_ipv4,nft_masq,nft_flow_offload,nft_ct,nf_nat_masquerade_ipv6,nf_nat_masquerade_ipv4,nf_conntrack_ipv6,nf_nat_ipv6,nf_conntrack_ipv4,nf_nat_ipv4,nf_nat_ftp,nf_nat,nf_flow_table,nf_conntrack_rtcache,nf_conntrack_ftp
sch_cake 36864 0

[openwrt-bot]

tohojo:

And what is the output of tc -s qdisc ?

Also, did you build this yourself, and did you add any patches to the current openwrt master?

[openwrt-bot]

n8v8R:

tc -s qdisc -> attached

Not of the self-compiling/builder sort ;), i.e. I did not build or patch it.

Having said that, the device though is on a downstream repo and I would not know if there is a potential patch that could cause this, I am just an end-user with no coding skills.

Commonly the downstream repo builds on the upstream feeds and just patches on top for the OS specific needs, but basically under the hood it is the same as upstream.

Nevertheless, a downstream ticket has been opened too https://gitlab.labs.nic.cz/turris/turris-build/issues/56

[openwrt-bot]

tohojo:

Ah, you're on the downstream Turris distribution. That is sufficiently different from upstream that I think it is better to handle it there. Especially since I suspect this is a build issue more than anything else; I'll go comment on that issue and request that this one be closed...

[openwrt-bot]

ldir:

This seems worrying - n8v8r are you running true openwrt releases or are you running some manufacturer franken-release?

Is this the same situation for all your tickets?

[openwrt-bot]

n8v8R:

this instance it is not vanilla OW but Turris distribution