Kernel Panics

H

haagch

Member
Original poster
1 Dezember 2018
43
Ich hatte unter https://forum.shiftphones.com/threads/shift6m-sos-1-1-l-20190320.1942/post-14948 schonmal ein log mit einer kernel panic gepostet. Seitdem hat sich nicht viel geändert und es gab noch keinen anderen Thread, deshalb mache ich mal einen neuen Thread hier.

Aktuell habe ich das SHIFT6M.SOS.1.1.L.20201126. Die version mit google play habe ich nicht ausprobiert.

Es gab schon Zeiten, in denen es fast keine kernel panics gab (z.B. direkt nach Updates, deshalb vermute ich mehr ein Software als ein Hardware Problem), aber es dauert dann meistens nicht lange, bis sie sich wieder häufen, so ungefähr 1-3 pro Tag.

Kürzlich bin ich in einen fast-Bootloop gekommen, das 6m hat sich ein paar Sekunden nach erfolgreichem Hochfahren neu gestartet, teilweise am Boot Screen mehrmals hintereinander vibriert, oder ist direkt in den Warnhinweis gegangen, dass die Daten Partition beschädigt ist und ich einen Factory Reset machen soll. Ich vermute mal, dass es nur eine Frage der Zeit ist, bis eine Kernel Panic einen wichtigen Schreibvorgang unterbricht... Einen Factory Reset habe ich dann auch gemacht und seitdem bootet es wieder normal, die Kernel Panics hat das aber nicht behoben.

Unter Anderem deswegen habe ich auch das Rückerstattungsangebot für ein Upgrade auf das 6mq angenommen, aber weil es bis dahin noch eine Weile dauert dachte ich, ich mache mal einen Thread.

Wer wissen will, ob er/sie auch betroffen ist, kann den Inhalt von /proc/last_kmsg (mit einem Texteditor) überprüfen. Wenn darin so etwas wie
Code: 
Kernel panic - not syncing: Fatal exception
vorkommt, dann wurde das Smartphone zuletzt wegen eines Kernel Crashes neu gestartet.

Mit dem shell Befehl
Code: 
settings get global boot_count
kann man auch überprüfen, wie oft das Smartphone neu gestartet wurde. Bei mir ist das Momentan 7, weil ich erst vor wenigen Tagen den Factory Reset gemacht habe.

Apps die ich verdächtige, das Problem zu verstärken.: home assistant, kdeconnect, linphone.
 

Anhänge

Eigentlich nicht
Code: 
SHIFT6m:/ $ df
Filesystem      1K-blocks    Used Available Use% Mounted on
/dev/root         2499580 1127624   1355572  46% /
tmpfs             1892584     864   1891720   1% /dev
/dev/block/dm-1    640468  364856    262388  59% /vendor
tmpfs             1892584       0   1892584   0% /mnt
/dev/block/dm-2  52136080 1032872  51070440   2% /data
/data/media      52136080 1032872  51070440   2% /storage/emulated
SHIFT6m:/ $ mount
rootfs on / type rootfs (rw,seclabel)
/dev/root on / type ext4 (ro,seclabel,relatime,data=ordered)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime,gid=3009,hidepid=2)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
/dev/block/dm-1 on /vendor type ext4 (ro,seclabel,relatime,data=ordered)
debugfs on /sys/kernel/debug type debugfs (rw,seclabel,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt type tmpfs (rw,seclabel,relatime,mode=755,gid=1000)
none on /config type configfs (rw,relatime)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
none on /dev/cpuset type cgroup (rw,relatime,cpuset,noprefix,release_agent=/sbin/cpuset_release_agent)
pstore on /sys/fs/pstore type pstore (rw,seclabel,relatime)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,seclabel,relatime)
/dev/block/mmcblk0p5 on /vendor/etc/nvcfg type ext4 (rw,seclabel,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
/dev/block/mmcblk0p6 on /vendor/etc/nvdata type ext4 (rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered)
/dev/block/mmcblk0p8 on /vendor/etc/protect_f type ext4 (rw,seclabel,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
/dev/block/mmcblk0p9 on /vendor/etc/protect_s type ext4 (rw,seclabel,nosuid,nodev,noatime,nodelalloc,noauto_da_alloc,commit=1,data=ordered)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
tmpfs on /storage type tmpfs (rw,seclabel,relatime,mode=755,gid=1000)
/dev/block/dm-2 on /data type ext4 (rw,seclabel,nosuid,nodev,noatime,discard,nobarrier,noauto_da_alloc,resuid=10010,data=ordered)
/data/media on /mnt/runtime/default/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6)
/data/media on /storage/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6)
/data/media on /mnt/runtime/read/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23)
/data/media on /mnt/runtime/write/emulated type sdcardfs (rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7)

Mal kurz geschaut
Code: 
PC is at __of_find_property+0x30/0x68
ist im devicetree code https://github.com/torvalds/linux/blob/v3.18/drivers/of/base.c#L214

Code: 
[ 1042.810813] Call trace:
[ 1042.810825] [<ffffffc000b46d78>] __of_find_property+0x30/0x68
[ 1042.810835] [<ffffffc000b47878>] __of_device_is_compatible+0xb0/0x128
[ 1042.810845] [<ffffffc000b479a8>] of_find_compatible_node+0x50/0x90
[ 1042.810857] [<ffffffc000ab7634>] mtk_wdt_restart+0x34/0x128
[ 1042.810867] [<ffffffc000ab5f90>] wk_cpu_callback+0x48/0x108
[ 1042.810880] [<ffffffc00024bc9c>] notifier_call_chain+0x84/0x2c0
[ 1042.810890] [<ffffffc00024bee4>] __raw_notifier_call_chain+0xc/0x18
[ 1042.810901] [<ffffffc000229878>] cpu_notify_nofail+0x28/0x70
[ 1042.810912] [<ffffffc000def0b8>] _cpu_down+0x2a0/0x7f8
[ 1042.810921] [<ffffffc000def6ac>] cpu_down+0x9c/0x2b8
[ 1042.810933] [<ffffffc0005d19e4>] hps_algo_do_cluster_action+0x174/0x1a0
[ 1042.810942] [<ffffffc0005d2570>] hps_algo_main+0x6c8/0xc10
[ 1042.810955] [<ffffffc0005cecc8>] _hps_task_main+0xe0/0x250
[ 1042.810966] [<ffffffc00024a8cc>] kthread+0xe4/0xf8
hps gehört wohl zum mediatek power management und cpu_down zum cpu hotplugging das wohl bei diesen big.LITTLE cpus zum strom sparen verwendet wird.

Linux schedule 4, load balancing - Programmer Sought

Linux schedule 4, load balancing, Programmer Sought, the best programmer technical posts sharing site.
www.programmersought.com
 

Anhänge

haagch schrieb:
Code: 
[ 1042.810813] Call trace:
[ 1042.810825] [<ffffffc000b46d78>] __of_find_property+0x30/0x68
[ 1042.810835] [<ffffffc000b47878>] __of_device_is_compatible+0xb0/0x128
[ 1042.810845] [<ffffffc000b479a8>] of_find_compatible_node+0x50/0x90
[ 1042.810857] [<ffffffc000ab7634>] mtk_wdt_restart+0x34/0x128
[ 1042.810867] [<ffffffc000ab5f90>] wk_cpu_callback+0x48/0x108
[ 1042.810880] [<ffffffc00024bc9c>] notifier_call_chain+0x84/0x2c0
[ 1042.810890] [<ffffffc00024bee4>] __raw_notifier_call_chain+0xc/0x18
[ 1042.810901] [<ffffffc000229878>] cpu_notify_nofail+0x28/0x70
[ 1042.810912] [<ffffffc000def0b8>] _cpu_down+0x2a0/0x7f8
[ 1042.810921] [<ffffffc000def6ac>] cpu_down+0x9c/0x2b8
[ 1042.810933] [<ffffffc0005d19e4>] hps_algo_do_cluster_action+0x174/0x1a0
[ 1042.810942] [<ffffffc0005d2570>] hps_algo_main+0x6c8/0xc10
[ 1042.810955] [<ffffffc0005cecc8>] _hps_task_main+0xe0/0x250
[ 1042.810966] [<ffffffc00024a8cc>] kthread+0xe4/0xf8
hps gehört wohl zum mediatek power management und cpu_down zum cpu hotplugging das wohl bei diesen big.LITTLE cpus zum strom sparen verwendet wird.

Linux schedule 4, load balancing - Programmer Sought

Linux schedule 4, load balancing, Programmer Sought, the best programmer technical posts sharing site.
www.programmersought.com
Zum Vergrößern anklicken....
Hm, das kommt aber in deinem ersten Log nicht vor. Wenn es der Grund für den Absturz wäre sollte es doch immer vorkommen, oder nicht?
 
So genau habe ich mir die panics noch nicht angeschaut. Ich sammle mal weiter. Vielleicht sieht man ja irgendwann etwas. Wenn nicht ist es vielleicht der ram defekt oder so.
 
@haagch kannst du die Crashes verlässlich reproduzieren? Gibt es Situationen in denen es auftritt oder kannst du es irgendwie provozieren? Eine genaue Beschreibung würde uns da sehr helfen
 
Nein, ich habe noch überhaupt kein Muster bemerkt.

Hin und wieder ist schon beim Drücken auf die power taste der bildschirm nicht angegangen und stattdessen gab es nach ein paar Sekunden ein reboot. Zumindest in diesen Fällen scheint es vom power management ausgelöst zu werden. Aber die reboots passieren auch komplett zufällig, z.b. das Smartphone liegt ein paar Stunden bewegungslos auf dem Tisch vor mir, plötzlich rebootet es.

Ich habe das Gefühl, dass es hauptsächlich bei mir zu Hause passiert, wo es mit meinem wlan verbunden ist, aber das kann auch ein falsches Gefühl sein.
 

Anhänge

Da mein 6mq jetzt angekommen ist und ich das 6m jetzt zurückschicken werde, hier meine letzte Ladung von Kernel Panic logs. Es sind wieder ganz unterschiedliche dabei, aber ich habe immer noch im Gefühl, dass es mit dem Power Management und meinem WLAN zusammenhängt. Nummer 9 ist speziell wie beschrieben, Smartphone war im Standby, kurzer Druck auf den Powerknopf bringt keine Reaktion / Bildschirm geht nicht an, ein paar Sekunden später reboot.
 

Anhänge

Ist dann zwar jetzt zu spät.
Solche Abstürze können sehr viele Ursachen haben. Ich habe hier etwas zu möglichen Ursachen geschrieben.
Auf jeden Fall viel Spaß mit dem 6mq!
 
Ein mechanisches Problem vermute ich nicht, weil die panics auch passieren, wenn das Smartphone komplett still auf dem Tisch liegt, und Erschütterungen keine Probleme verursachen. Es kann aber durchaus sein, dass WLAN/Bluetooth oder ein anderer Chip ein technisches Problem hat oder der Akku schwächelt (Akkulaufzeit ist aber noch normal).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben Unten