[Bloat] Debugging a crash

[Bloat] Debugging a crash

[Rich Brown]

Folks,

I was running OpenWrt 19.07-rc2 on my Archer C7v2, and experienced a potentially-repeatable crash under heavy network traffic load.

I was uploading several long videos to Youtube (> 5GBytes each) and watching Netflix on my 7mbps/768kbps DSL connection. Things were working fine (latency remained acceptable - YAY SQM!) My upstream pipe (slow as it is) was totally filled by the three competing uploads, and Netflix was doing its best to show me the West Wing.

A couple times during the evening, the Netflix stream just crapped out and I lost the connection. (Infinite buffering message on-screen, couldn't get to Google, etc. The LuCI GUI showed uptime of a minute or so, and then things were fine again.)

I now have OpenWrt 19.07.1 installed, and have a little bandwidth for repeating the experiment.

What debugging information should I turn on/look for in case this happens again? Thanks.

Rich

PS The new Youtube uploader facility is excellent. If you keep the window open, it automagically resumes the transfer after interruption. It's great for people like me who have large files to upload on a slow link, where the likelihood of a link failure (or needing to move my laptop to a different location) is high.

Re: [Bloat] Debugging a crash

[Toke Høiland-Jørgensen]

Rich Brown <richb.hanover@gmail.com> writes:

> Folks,
>
> I was running OpenWrt 19.07-rc2 on my Archer C7v2, and experienced a
> potentially-repeatable crash under heavy network traffic load.
>
> I was uploading several long videos to Youtube (> 5GBytes each) and
> watching Netflix on my 7mbps/768kbps DSL connection. Things were
> working fine (latency remained acceptable - YAY SQM!) My upstream pipe
> (slow as it is) was totally filled by the three competing uploads, and
> Netflix was doing its best to show me the West Wing.
>
> A couple times during the evening, the Netflix stream just crapped out
> and I lost the connection. (Infinite buffering message on-screen,
> couldn't get to Google, etc. The LuCI GUI showed uptime of a minute or
> so, and then things were fine again.)
>
> I now have OpenWrt 19.07.1 installed, and have a little bandwidth for
> repeating the experiment.
>
> What debugging information should I turn on/look for in case this
> happens again? Thanks.

If the box reboots, this sounds like a kernel oops. In which case, we'd
really need a kernel stack dump to debug it. Which I'm not sure there's
a good way to get on OpenWrt without attaching a serial console :(

Unless of course you can find a reliable way to reproduce it without too
much delay, in which case someone with a serial console can take a look,
I guess :)

-Toke

Re: [Bloat] Debugging a crash

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 1971 bytes --]

Have a look at https://forum.openwrt.org/t/crashlog-retrieval-mips/19731. It seems cat /sys/kernel/debug/crashlog after a reboot caused by a crash mightcreveal some more details.

Good luck
        Sebastian

On February 18, 2020 7:35:31 PM GMT+01:00, "Toke Høiland-Jørgensen" <toke@toke.dk> wrote:
>Rich Brown <richb.hanover@gmail.com> writes:
>
>> Folks,
>>
>> I was running OpenWrt 19.07-rc2 on my Archer C7v2, and experienced a
>> potentially-repeatable crash under heavy network traffic load.
>>
>> I was uploading several long videos to Youtube (> 5GBytes each) and
>> watching Netflix on my 7mbps/768kbps DSL connection. Things were
>> working fine (latency remained acceptable - YAY SQM!) My upstream
>pipe
>> (slow as it is) was totally filled by the three competing uploads,
>and
>> Netflix was doing its best to show me the West Wing.
>>
>> A couple times during the evening, the Netflix stream just crapped
>out
>> and I lost the connection. (Infinite buffering message on-screen,
>> couldn't get to Google, etc. The LuCI GUI showed uptime of a minute
>or
>> so, and then things were fine again.)
>>
>> I now have OpenWrt 19.07.1 installed, and have a little bandwidth for
>> repeating the experiment.
>>
>> What debugging information should I turn on/look for in case this
>> happens again? Thanks.
>
>If the box reboots, this sounds like a kernel oops. In which case, we'd
>really need a kernel stack dump to debug it. Which I'm not sure there's
>a good way to get on OpenWrt without attaching a serial console :(
>
>Unless of course you can find a reliable way to reproduce it without
>too
>much delay, in which case someone with a serial console can take a
>look,
>I guess :)
>
>-Toke
>_______________________________________________
>Bloat mailing list
>Bloat@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 2454 bytes --]