Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
openwrt-bot opened this issue Jun 30, 2019 · 13 comments
Labels

Comments

@openwrt-bot
Copy link

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
Copy link
Author

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
Copy link
Author

n8v8R:

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

@openwrt-bot
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

tohojo:

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

@openwrt-bot
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

n8v8R:

this instance it is not vanilla OW but Turris distribution

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant