Modify

Opened 2 years ago

Closed 2 years ago

#20857 closed defect (fixed)

Kernel crash, when using native IPV6

Reported by: johnnysl Owned by: developers
Priority: normal Milestone: Designated Driver (Trunk)
Component: kernel Version: Trunk
Keywords: IPV6, paging request Cc:

Description

Device: Linksys WRT1900ACV2
OpenWrt Version:
DISTRIB_RELEASE='Bleeding Edge'
DISTRIB_REVISION='r47373'
DISTRIB_CODENAME='designated_driver'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_TAINTS='no-all busybox'

Issue: actual (native) IPV6 usage will cause the router to crash after between 15 and 60 minutes of normal usage. Issue is reproducable.
(Workaround is to bring the wan6 interface down, to prevent IPV6 usage.)

crash message in log:
Wed Nov 4 16:29:41 2015 kern.alert kernel: [ 4162.623720] Unable to handle kernel paging request at virtual address 0000258c
Wed Nov 4 16:29:41 2015 kern.alert kernel: [ 4162.630986] pgd = c0004000
Wed Nov 4 16:29:41 2015 kern.alert kernel: [ 4162.633714] [0000258c] *pgd=00000000
Wed Nov 4 16:29:41 2015 kern.emerg kernel: [ 4162.637314] Internal error: Oops: 17 #1 SMP ARM
Wed Nov 4 16:29:41 2015 kern.warn kernel: [ 4162.642036] Modules linked in: pppoe ppp_async iptable_nat pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE
Wed Nov 4 16:29:41 2015 kern.warn kernel: [ 4162.733832] Workqueue: phy0 ieee80211_iface_work [mac80211]

relevant network config:
config interface 'wan'

option ifname 'eth0.6'
option _orig_ifname 'eth0'
option _orig_bridge 'false'
option proto 'pppoe'
option password 'some-password'
option ipv6 '1'
option peerdns '0'
option username 'some-user'
option dns '31.220.43.191 62.141.38.230'

config interface 'wan6'

option ifname '@wan'
option proto 'dhcpv6'
option reqaddress 'try'
option reqprefix 'auto'

please let me know if you need more details

Attachments (0)

Change History (21)

comment:1 Changed 2 years ago by nbd

In your kernel log output you left out most of the useful bits. Please post something that is more complete

comment:2 Changed 2 years ago by anonymous

Which bits do you need? Kernel log doesn't seem to show more relevant data.
If i need to increase logging, tel me how and i'm happy to supply.

comment:3 Changed 2 years ago by nbd

so it's cut off after that last line?

comment:4 Changed 2 years ago by Johnnysl

Correct, after that i get logs from the next boot, so no more entries logged :-(

comment:5 Changed 2 years ago by nbd

Is there a file /sys/kernel/debug/crashlog afterwards?

comment:6 Changed 2 years ago by Johnnysl

No. Wil trigger another crash/reboot, but do not expect it to appear.

comment:7 Changed 2 years ago by anonymous

@nbd, just read i need swap space to store a kernel dump. Adding a swap partition now.

comment:8 Changed 2 years ago by nbd

you don't need swap space for that one

comment:9 Changed 2 years ago by Johnnsl

@nbd: triggered a few more crashes, but am unable to get more information about the crash than:

Thu Nov 5 09:22:22 2015 kern.alert kernel: [43218.829028] Unable to handle kernel paging request at virtual address 0000258c
Thu Nov 5 09:22:22 2015 kern.alert kernel: [43218.836289] pgd = dd4f4000
Thu Nov 5 09:22:22 2015 kern.alert kernel: [43218.839015] [0000258c] *pgd=1d95f831, *pte=00000000, *ppte=00000000
Thu Nov 5 09:22:22 2015 kern.emerg kernel: [43218.845339] Internal error: Oops: 17 #1 SMP ARM

again: if you could give me pointers how to improve the logs or add dumps, please let me know and 'm more than happy to compile or install something, and make it happen.

comment:10 Changed 2 years ago by mystica555

Hi,

I also have the exact same issue, but with 6rd and not just native IPv6 via DHCPv6.

wrt1200ac
Linux OpenWrt 3.18.21 #1 SMP Fri Oct 30 22:04:58 UTC 2015 armv7l GNU/Linux

DESIGNATED DRIVER (Bleeding Edge, r47280)

from the trunk builds on openwrt.org - have not yet started compiling my own.

[14055.160660] Unable to handle kernel paging request at virtual address 0000258c
[14055.167928] pgd = c0004000
[14055.170656] [0000258c] *pgd=00000000
[14055.174258] Internal error: Oops: 17 #1 SMP ARM

and then soon after, it reboots.

I only caught that with:

while true; do dmesg; done

and after about 3 hours, boom, it spit that out, one more half iteration of dmesg ran, and reboot.

I will hook a serial console to it this week to try and debug the issue further, while the roommate isnt here and wanting to use the internet in a stable fashion.

Please note, that with ipv6 enabled, I am seeing reboots sporadically between 5 minutes and 7 hours of uptime. I've not seen it stay longer than 7 hours, but I presume that was during the time neither myself nor my roommate were accessing the internet.

ifdown 6rd and I havent seen a spontaneous reboot since.

The prior flash I was running from trunk, while with mwlwifi 10.3.0.8 I was gettting massive wifi issues, I do not believe I saw the specific ipv6 issue. I however do not know for certain, as the wifi was crashing nearly as much as ipv6 was causing reboots after the newer flash of 10.3.0.12 fixed wifi 98%.

comment:11 Changed 2 years ago by mystica555

Hm still getting spontaneous reboots from the wifi driver; updating that ticket...

comment:12 Changed 2 years ago by JohnnySL

At least mine doesn't crash on the wifi driver :-#

Might it be that these crashes are due to the wifi driver as well?

comment:13 Changed 2 years ago by JohnnySL

I've finally got a full dump from another user:

Nov 15 20:17:39 192.168.200.1 kernel: [ 4229.928188] Unable to handle kernel paging request at virtual address 0000258c
Nov 15 20:17:39 192.168.200.1 kernel: [ 4229.935453] pgd = cd59c000
Nov 15 20:17:40 192.168.200.1 kernel: [ 4229.938231] [0000258c] *pgd=0d4f3831, *pte=00000000, *ppte=00000000
Nov 15 20:17:40 192.168.200.1 kernel: [ 4229.944585] Internal error: Oops: 17 #1 SMP ARM
Nov 15 20:17:40 192.168.200.1 kernel: [ 4229.949314] Modules linked in: pppoe ppp_async iptable_nat pptp pppox ppp_mppe ppp_generic nf_nat_ipv4 nf_conntrack_ipv6 nf_conntrack_ipv4 ipt_REJECT ipt_MASQUERADE armada_thermal xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota xt_pkttype xt_physdev xt_owner xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_addrtype xt_TCPMSS xt_REDIRECT xt_N
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.095518] CPU: 1 PID: 2104 Comm: hostapd Not tainted 3.18.20 #1
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.101648] task: cf313000 ti: ccaf2000 task.ti: ccaf2000
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.107078] pc : [<bf29d508>] lr : [<bf29d4f8>] psr: 60000153
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.107078] sp : ccaf3ac0 ip : ccaf3ac0 fp : ccaf3af4
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.118603] r10: 00000000 r9 : ceb4273c r8 : cd594e2c
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.123854] r7 : cd594e20 r6 : ceb42730 r5 : ceb41840 r4 : 0000258c
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.130415] r3 : ffffffff r2 : 00000000 r1 : 00000000 r0 : ceb4273c
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.136980] Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment user
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.144244] Control: 10c5387d Table: 0d59c06a DAC: 00000015
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.150029] Process hostapd (pid: 2104, stack limit = 0xccaf2238)
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.156159] Stack: (0xccaf3ac0 to 0xccaf4000)
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.160559] 3ac0: c007b374 ffffffff 00000003 ceb432d4 ceb40b40 ceb432e0 cd594e20 cd594e2c
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.168788] 3ae0: 00000004 00000004 ccaf3b34 ccaf3af8 bf2955e0 bf29d4cc 00000003 00000000
Nov 15 20:17:40 192.168.200.1 kernel: [ 4230.177006] 3b00: cf26fca8 00000004 ccaf3b24 cd594800 cd7fda00 cd7fda80 00000000 cd59485c

comment:14 Changed 2 years ago by nbd

It's still missing the call trace, which is important for analyzing this issue

comment:15 Changed 2 years ago by creiners

how do I get a call trace? I was the user he pulled this from. I have no issues assisting with this.

comment:16 Changed 2 years ago by nbd

It's usually the part in the log that comes right after the lines you posted.

comment:17 Changed 2 years ago by JohnnySL

i'm trying to grab the log via a wired host putty session doing a cat/proc/kmsg.
With this I get a few more lines, but it still reboots before it is done spitting out all the lines. is serial a better/ only option? any ideas on how to grab the whole dump would be appreciated.

comment:18 follow-up: Changed 2 years ago by bittorf@…

unsure if mvebu support crashlog via /sys/kernel/debug/crashlog.
after reboot, check with 'cat /sys/kernel/debug/crashlog'

comment:19 in reply to: ↑ 18 Changed 2 years ago by JohnnySL

Replying to bittorf@…:

unsure if mvebu support crashlog via /sys/kernel/debug/crashlog.
after reboot, check with 'cat /sys/kernel/debug/crashlog'

Nope, no crashlog :(

comment:20 Changed 2 years ago by JohnnySL

Fixed wit R47677. This one can be closed :-)

comment:21 Changed 2 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.