OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bug Report
  • Category Kernel
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by n8v8R - 30.06.2019
Last edited by Petr Štetiar - 03.07.2019

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

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/0×714 [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

 


Closed by  Petr Štetiar
03.07.2019 08:03
Reason for closing:  Different project
n8v8R commented on 30.06.2019 18:43

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.

n8v8R commented on 01.07.2019 06:58

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

moeller0 commented on 01.07.2019 07:09

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.

n8v8R commented on 01.07.2019 07:21

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
Toke Høiland-Jørgensen commented on 01.07.2019 10:59

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?

n8v8R commented on 01.07.2019 11:12

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
Toke Høiland-Jørgensen commented on 01.07.2019 11:20

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

n8v8R commented on 01.07.2019 11:23

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
Toke Høiland-Jørgensen commented on 01.07.2019 12:19

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?

n8v8R commented on 01.07.2019 12:32

# 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

   tc (6.9 KiB)
Toke Høiland-Jørgensen commented on 01.07.2019 14:29

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...

Project Manager
Kevin 'ldir' Darbyshire-Bryant commented on 01.07.2019 14:55

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?

n8v8R commented on 01.07.2019 15:41

this instance it is not vanilla OW but Turris distribution

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing