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#277 - Linksys EA8500 crashes after few seconds on reboot #5319

Closed
openwrt-bot opened this issue Nov 9, 2016 · 0 comments
Closed

FS#277 - Linksys EA8500 crashes after few seconds on reboot #5319

openwrt-bot opened this issue Nov 9, 2016 · 0 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Nov 9, 2016

eTomm:

I setup my EA8500 with the latest LEDE branch. Configured some wifi networks, some OpenVPN connections, SQM, DDNS, UPNP and MWNA3.

After few seconds from the reboot (but yesterday it lasted 12 hours) the router crashes. Everything doesn't work. I can't ping it from the lan, from the wan, from the wifi. If I connect to the router lan directly and examine packets with Wiresharks it "seems" the router is doing something because I see packets originating from it (or at least from its mac address).

I tried to collect the log, but really I don't know how I should do it to be helpful. This is what I collected and it seems compatible with the crash time.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 9, 2016

mkresin:

Looks like this issue you are reporting is already tracked in FS#9.

Am I right?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 9, 2016

eTomm:

I really didn't think it could be a SQM problem but reading at the FS#9 thread it seems highly related.

Can you merge this there or should I post the log.txt there?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 9, 2016

mkresin:

Wed Nov 9 00:49:49 2016 kern.warn kernel: [ 305.843014] WARNING: CPU: 0 PID: 3 at net/sched/sch_hfsc.c:1426 hfsc_dequeue+0x188/0x568 sch_hfsc

At least you have a problem with hfsc as well.

But you might be right. FS#9 don't mention that the device gets inaccessible afterwards. I guess the real crash isn't included in the logfile.

Where does your log come from? Is it from logread/dmesg before the device is inaccessible? Do you have access to the serial console of the EA8500?

Would you please paste the output of

cat /proc/sys/kernel/debub/crashlog

after you had to reboot the EA8500 because of the issue.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 10, 2016

eTomm:

So I reproduced the problem on the first run, rebooted but there was no /proc/sys/kernel/debug/crashlog (and just in case even not a debub/crashlog ahah).

The log that I posted was copied directly from the html window. After it I tried to keep the log with a logread -f but obviously after 4 hours still nothing.

I read all the thread in FS#9 and someone mention a device inaccessible, but it is not in the opening post. So I will let you choose if to merge or not this bug report.

I am going to reset the SQM to the default values, to see if the crashes that I was having disappears... in this case I can think the problem is related to the SQM and thus it is a duplicate of FS#9.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 10, 2016

eTomm:

Just before resetting SQM it happened again.

This is the log

Thu Nov 10 02:06:40 2016 kern.warn kernel: [ 4874.187647] ------------[ cut here ]------------ Thu Nov 10 02:06:40 2016 kern.warn kernel: [ 4874.187738] WARNING: CPU: 1 PID: 0 at net/sched/sch_hfsc.c:1426 hfsc_dequeue+0x188/0x568 [sch_hfsc]() Thu Nov 10 02:06:41 2016 kern.warn kernel: [ 4874.191368] 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 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_policy xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_id xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY slhc nf_rThu Nov 10 02:06:41 2016 kern.warn kernel: [ 4874.381178] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W 4.4.30 #0 Thu Nov 10 02:06:41 2016 kern.warn kernel: [ 4874.381443] Hardware name: Qualcomm (Flattened Device Tree) Thu Nov 10 02:06:41 2016 kern.warn kernel: [ 4874.388588] [] (unwind_backtrace) from [] (show_stack+0x14/0x20) Thu Nov 10 02:06:41 2016 kern.warn kernel: [ 4874.393960] [] (show_stack) from [] (dump_stack+0x8c/0xa0) Thu Nov 10 02:06:41 2016 kern.warn kernel: [ 4874.401948] [] (dump_stack) from [] (warn_slowpath_common+0xa4/0xd0)

And again o log under /proc/sys/kernel/debug/crashlog

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 10, 2016

mkresin:

I am going to reset the SQM to the default values, to see if the crashes that I was having disappears... in this case I can think the problem is related to the SQM and thus it is a duplicate of FS#9.

Please report back if the issue is gone. Since your log might not show the actually crash, I don't like to mark this ticket as duplicate as long as it isn't confirmed that it's an SQM related issue.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 11, 2016

eTomm:

More than one day passed without any problem. Seems that the problem in F#9 makes the router crash too (or at least you are not able to ping or connect to it in any way but the router sends out packets).

Would you prefer me to repost the log or just a comment... or will you close and its fine like that?

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented Nov 11, 2016

mkresin:

Would you prefer me to repost the log or just a comment...

If your comment provides missing (not duplicate) informations to FS#9, post it. I've now seen the comment that the device might get inaccessible. Missed that the last time I had a log.

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