Every reboot results in Kernel Panic?

Post Reply
systemservice
Posts: 49
Joined: Wed Apr 10, 2019 4:39 pm
languages_spoken: english, german
ODROIDs: ODROID-N2
Location: Germany
Has thanked: 1 time
Been thanked: 1 time
Contact:

Every reboot results in Kernel Panic?

Unread post by systemservice » Tue Aug 13, 2019 6:33 pm

Hi,
I'm using ONDROID-N2 with Android PIE (20190812) rooted with Magisk and connected with USB-UART to my PC.
I tried different commands to reboot it, like su -c 'reboot', su -c 'svc power reboot', su -c 'am start -a android.intent.action.REBOOT' and it does work,
but on the serial console it looks like a Kernel Panic happens at this time - there are a lot of lines like these:

Code: Select all

  244.341423@5] [ffffff802031bcd0+  32][<ffffff80090869d8>] __switch_to+0xa0/0xc8
[  244.341425@5] [ffffff802031bcf0+ 112][<ffffff8009cc4560>] __schedule+0x250/0x7b0
[  244.341427@5] [ffffff802031bd60+  32][<ffffff8009cc4afc>] schedule+0x3c/0xa0
[  244.341430@5] [ffffff802031bd80+  80][<ffffff8009cc8380>] do_nanosleep+0x88/0x130
[  244.341433@5] [ffffff802031bdd0+ 160][<ffffff8009126af8>] hrtimer_nanosleep+0xa8/0x140
[  244.341435@5] [ffffff802031be70+   0][<ffffff8009147a90>] compat_SyS_nanosleep+0x88/0xf8
[  244.341437@5] [0000000000000000+   0][<ffffff80090838c0>] el0_svc_naked+0x34/0x38
[  244.341440@5] surfaceflinger  S    0  2843      1 0x00400000
[  244.341440@5] Call trace:
[  244.341443@5] [ffffff8020327b60+  32][<ffffff80090869d8>] __switch_to+0xa0/0xc8
[  244.341445@5] [ffffff8020327b80+ 112][<ffffff8009cc4560>] __schedule+0x250/0x7b0
[  244.341448@5] [ffffff8020327bf0+  64][<ffffff8009cc4afc>] schedule+0x3c/0xa0
[  244.341450@5] [ffffff8020327c30+ 272][<ffffff8009791d60>] binder_thread_read+0x5c8/0x1160
[  244.341453@5] [ffffff8020327d40+ 128][<ffffff8009797814>] binder_ioctl_write_read+0x184/0x348
[  244.341456@5] [ffffff8020327dc0+ 160][<ffffff8009797fb0>] binder_ioctl+0x5d8/0x868
[  244.341458@5] [ffffff8020327e60+   0][<ffffff800927a950>] compat_SyS_ioctl+0xd0/0xfa8
[  244.341460@5] [0000000000000000+   0][<ffffff80090838c0>] el0_svc_naked+0x34/0x38
[  244.341463@5] Binder:2843_1   S    0  2924      1 0x00400000
[  244.341464@5] Call trace:
[  244.341466@5] [ffffff8020437b60+  32][<ffffff80090869d8>] __switch_to+0xa0/0xc8
[  244.341469@5] [ffffff8020437b80+ 112][<ffffff8009cc4560>] __schedule+0x250/0x7b0
[  244.341471@5] [ffffff8020437bf0+  64][<ffffff8009cc4afc>] schedule+0x3c/0xa0
[  244.341474@5] [ffffff8020437c30+ 272][<ffffff8009791d60>] binder_thread_read+0x5c8/0x1160
[  244.341476@5] [ffffff8020437d40+ 128][<ffffff8009797814>] binder_ioctl_write_read+0x184/0x348
[  244.341479@5] [ffffff8020437dc0+ 160][<ffffff8009797fb0>] binder_ioctl+0x5d8/0x868
[  244.341482@5] [ffffff8020437e60+   0][<ffffff800927a950>] compat_SyS_ioctl+0xd0/0xfa8
[  244.341484@5] [0000000000000000+   0][<ffffff80090838c0>] el0_svc_naked+0x34/0x38
[  244.341487@5] Binder:2843_2   S    0  2925      1 0x00400000
[  244.341488@5] Call trace:
[  244.341490@5] [ffffff802043bb60+  32][<ffffff80090869d8>] __switch_to+0xa0/0xc8
[  244.341492@5] [ffffff802043bb80+ 112][<ffffff8009cc4560>] __schedule+0x250/0x7b0
[  244.341495@5] [ffffff802043bbf0+  64][<ffffff8009cc4afc>] schedule+0x3c/0xa0
[  244.341497@5] [ffffff802043bc30+ 272][<ffffff8009791d60>] binder_thread_read+0x5c8/0x1160
[  244.341500@5] [ffffff802043bd40+ 128][<ffffff8009797814>] binder_ioctl_write_read+0x184/0x348
[  244.341502@5] [ffffff802043bdc0+ 160][<ffffff8009797fb0>] binder_ioctl+0x5d8/0x868
[  244.341505@5] [ffffff802043be60+   0][<ffffff800927a950>] compat_SyS_ioctl+0xd0/0xfa8
[  244.341507@5] [0000000000000000+   0][<ffffff80090838c0>] el0_svc_naked+0x34/0x38
[  244.341511@5] DispSync        S    0  2928      1 0x00400000
[  244.341511@5] Call trace:
[  244.341514@5] [ffffff8020447af0+  32][<ffffff80090869d8>] __switch_to+0xa0/0xc8
[  244.341516@5] [ffffff8020447b10+ 112][<ffffff8009cc4560>] __schedule+0x250/0x7b0
[  244.341519@5] [ffffff8020447b80+  32][<ffffff8009cc4afc>] schedule+0x3c/0xa0
[  244.341521@5] [ffffff8020447ba0+  64][<ffffff80091381c8>] futex_wait_queue_me+0xc8/0x150
[  244.341523@5] [ffffff8020447be0+ 320][<ffffff8009139064>] futex_wait+0xe4/0x1e8
[  244.341525@5] [ffffff8020447d20+ 288][<ffffff800913b0c8>] do_futex+0x530/0xb60
[  244.341528@5] [ffffff8020447e40+   0][<ffffff800913bdcc>] compat_SyS_futex+0x104/0x130
[  244.341530@5] [0000000000000000+   0][<ffffff80090838c0>] el0_svc_naked+0x34/0x38
[  244.341533@5] appEventThread  S    0  2929      1 0x00400000
[  244.341534@5] Call trace:
[  244.341536@5] [ffffff802044baf0+  32][<ffffff80090869d8>] __switch_to+0xa0/0xc8
[  244.341539@5] [ffffff802044bb10+ 112][<ffffff8009cc4560>] __schedule+0x250/0x7b0
[  244.341541@5] [ffffff802044bb80+  32][<ffffff8009cc4afc>] schedule+0x3c/0xa0
[  244.341544@5] [ffffff802044bba0+  64][<ffffff80091381c8>] futex_wait_queue_me+0xc8/0x150
[  244.341546@5] [ffffff802044bbe0+ 320][<ffffff8009139064>] futex_wait+0xe4/0x1e8
[  244.341548@5] [ffffff802044bd20+ 288][<ffffff800913b0c8>] do_futex+0x530/0xb60
[  244.341550@5] [ffffff802044be40+   0][<ffffff800913bdcc>] compat_SyS_futex+0x104/0x130
[  244.341552@5] [0000000000000000+   0][<ffffff80090838c0>] el0_svc_naked+0x34/0x38
[  244.341555@5] sfEventThread   S    0  2930      1 0x00400000
[  244.341556@5] Call trace:
[  244.341558@5] [ffffff802044faf0+  32][<ffffff80090869d8>] __switch_to+0xa0/0xc8
[  244.341561@5] [ffffff802044fb10+ 112][<ffffff8009cc4560>] __schedule+0x250/0x7b0
[  244.341563@5] [ffffff802044fb80+  32][<ffffff8009cc4afc>] schedule+0x3c/0xa0
[  244.341565@5] [ffffff802044fba0+  64][<ffffff80091381c8>] futex_wait_queue_me+0xc8/0x150
[  244.341567@5] [ffffff802044fbe0+ 320][<ffffff8009139064>] futex_wait+0xe4/0x1e8
[  244.341569@5] [ffffff802044fd20+ 288][<ffffff800913b0c8>] do_futex+0x530/0xb60
[  244.341572@5] [ffffff802044fe40+   0][<ffffff800913bdcc>] compat_SyS_futex+0x104/0x130
[  244.341574@5] [0000000000000000+   0][<ffffff80090838c0>] el0_svc_naked+0x34/0x38
[  244.341576@5] mali-mem-purge  S    0  2966      1 0x00400000
[  244.341577@5] Call trace:
[  244.341580@5] [ffffff80204afcd0+  32][<ffffff80090869d8>] __switch_to+0xa0/0xc8
[  244.341582@5] [ffffff80204afcf0+ 112][<ffffff8009cc4560>] __schedule+0x250/0x7b0
I have scheduled a daily reboot to free up memory, etc. but now I fear that one day it won't boot because the filesystem may be corrupted if such things happen.

Is it possible to fix it or do these lines not mean anything dangerous?

User avatar
tobetter
Posts: 3764
Joined: Mon Feb 25, 2013 10:55 am
languages_spoken: Korean, English
ODROIDs: X, X2, U2, U3, XU3, C1
Location: Paju, South Korea
Has thanked: 28 times
Been thanked: 128 times
Contact:

Re: Every reboot results in Kernel Panic?

Unread post by tobetter » Tue Aug 13, 2019 7:08 pm

Do all 3 commands make the same crash logs?
Do you have the same error when you reboot or shutdown from Settings or Power menu?

systemservice
Posts: 49
Joined: Wed Apr 10, 2019 4:39 pm
languages_spoken: english, german
ODROIDs: ODROID-N2
Location: Germany
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Every reboot results in Kernel Panic?

Unread post by systemservice » Tue Aug 13, 2019 8:44 pm

Yes, I executed these 3 commands on SSH. But now I tried "adb reboot" and it's the same, a lot of kernel stack trace lines on the serail port are scrolling down quickly before the device reboots.
Can you tell me if you see the same when doing "adb reboot" for example? Because otherwise I would think I did something wrong. Thank you.

systemservice
Posts: 49
Joined: Wed Apr 10, 2019 4:39 pm
languages_spoken: english, german
ODROIDs: ODROID-N2
Location: Germany
Has thanked: 1 time
Been thanked: 1 time
Contact:

Re: Every reboot results in Kernel Panic?

Unread post by systemservice » Thu Aug 15, 2019 4:00 pm

Could anybody please just do what I did - test what you see on the serial console (via USB-UART) when doing "adb reboot", do you see these kernel stack traces like me?
Thank you.

Post Reply

Return to “Android”

Who is online

Users browsing this forum: gsgs and 2 guests