Random reboots und eine (!) Erklärung dafür

[0cram72]

Hallo ihrs,
der Thread dient mehr der Verbreitung einer Information als einer Fehlersuche. Man kennt's von manchen Geräten, "Random Reboots"- mich hat's auch erwischt.
Kurz zu meinem Gerät:
Galaxy Nexus 4.3 Stock (unlocked/root/cwm)
gekauft im Oktober 2012
nie viel gebastelt, nur mal zwischen takju und yakju gewechselt

Worum es eigentlich geht:
Vorletzten Samstag fing das Gerät willkürlich selbst neuzustarten. Es gab vorher keinerlei Symptome.
Ich dachte mir "machst noch schnell ein paar Backups, cwm, Titanium..", resetten und schauen was passiert. Beim Backup brach das Gerät immer irgendwo ab und startete neu. Irgendwie hab ich's mit vielen Anläufen geschafft valide Backups zu erzeugen.
Also neu die 4.3 geflasht, lief alles total superstens, keine Probleme. Ich fing dann nach und nach die App-Updates einzuspielen, teils Backups wiederherzustellen und den Speicher zu füllen. Batsch, reboot- Sche!ße. Am laufenden Band, völlig willkürlich, keine konkrete Aktion erkennbar, die den Fehler verursachen könnte - Oder etwa doch? Eins tat ich immer als es passierte - Daten schreiben und wenn es nur das senden einer Email war! Wir haben ein ext4-FS mit Mountoption error=panic, heißt kernelpanic, heißt reboot/shutdown - Aha! Irgendwo muss es ja ein Kernel-Log geben. Achja, /proc/last_kmsg
Was ham wir denn da:

[ 5406.506042] mmcblk0: error -110 transferring data, sector 2437328, nr 80, cmd response 0x900, card status 0xd00
[ 5406.506561] end_request: I/O error, dev mmcblk0, sector 2437328
[ 5406.506652] end_request: I/O error, dev mmcblk0, sector 2437336
[ 5406.506835] end_request: I/O error, dev mmcblk0, sector 2437344
[ 5406.506988] end_request: I/O error, dev mmcblk0, sector 2437352
[ 5406.507080] end_request: I/O error, dev mmcblk0, sector 2437360
[ 5406.507263] end_request: I/O error, dev mmcblk0, sector 2437368
[ 5406.507354] end_request: I/O error, dev mmcblk0, sector 2437376
[ 5406.507507] end_request: I/O error, dev mmcblk0, sector 2437384
[ 5406.507629] end_request: I/O error, dev mmcblk0, sector 2437392
[ 5406.507781] end_request: I/O error, dev mmcblk0, sector 2437400
[ 5406.508331] Aborting journal on device mmcblk0p12-8.
[ 5406.513732] journal commit I/O error
[ 5406.518829] EXT4-fs error (device mmcblk0p12): ext4_journal_start_sb:296: Detected aborted journal
[ 5406.519165] EXT4-fs (mmcblk0p12): Remounting filesystem read-only
[ 5406.524169] Kernel panic - not syncing: EXT4-fs panic from previous error
[ 5406.524200] 
[ 5406.524414] Backtrace: 
[ 5406.524627] [<c005c598>] (dump_backtrace+0x0/0x10c) from [<c060c07c>] (dump_stack+0x18/0x1c)
[ 5406.524780]  r6:c062ad38 r5:c07f253c r4:c08275c0 r3:00000000
[ 5406.525207] [<c060c064>] (dump_stack+0x0/0x1c) from [<c060c484>] (panic+0x80/0x1b8)
[ 5406.525390] [<c060c404>] (panic+0x0/0x1b8) from [<c01ce7a0>] (__ext4_abort+0xd8/0xec)
[ 5406.525543]  r3:88024840 r2:00000000 r1:c6be3bc4 r0:c074ec9c
[ 5406.525970]  r7:c6be2000
[ 5406.526214] [<c01ce6cc>] (__ext4_abort+0x4/0xec) from [<c01ceb38>] (ext4_journal_start_sb+0x84/0x128)
[ 5406.526306]  r6:00000002 r5:c6de2800 r4:c6ef3600
[ 5406.526733] [<c01ceab4>] (ext4_journal_start_sb+0x0/0x128) from [<c01bb198>] (ext4_dirty_inode+0x1c/0x48)
[ 5406.526885]  r8:c6be3d38 r7:c16555a0 r6:c5f02d40 r5:c5f02d40 r4:c5f02d40
[ 5406.527404] [<c01bb17c>] (ext4_dirty_inode+0x0/0x48) from [<c01709fc>] (__mark_inode_dirty+0x34/0x1d8)
[ 5406.527557]  r5:00000001 r4:c5f02d40
[ 5406.527832] [<c01709c8>] (__mark_inode_dirty+0x0/0x1d8) from [<c0164988>] (file_update_time+0xbc/0x138)
[ 5406.528015]  r8:c6be3d38 r7:c16555a0 r6:c5f02d40 r5:c5f02d40 r4:0000000c
[ 5406.528564] r3:c5f02ddc
[ 5406.528839] [<c01648cc>] (file_update_time+0x0/0x138) from [<c011629c>] (__generic_file_aio_write+0x23c/0x4a4)
[ 5406.529022] [<c0116060>] (__generic_file_aio_write+0x0/0x4a4) from [<c0116568>] (generic_file_aio_write+0x64/0xdc)
[ 5406.529205] [<c0116504>] (generic_file_aio_write+0x0/0xdc) from [<c01aedc4>] (ext4_file_write+0xd4/0x2b0)
[ 5406.529388] [<c01aecf0>] (ext4_file_write+0x0/0x2b0) from [<c014c0b8>] (do_sync_write+0xac/0xdc)
[ 5406.529479] [<c014c00c>] (do_sync_write+0x0/0xdc) from [<c014c190>] (vfs_write+0xa8/0x14c)
[ 5406.529663] [<c014c0e8>] (vfs_write+0x0/0x14c) from [<c014c430>] (sys_pwrite64+0x74/0x98)
[ 5406.529815]  r8:c00586a8 r7:612ce7b0 r6:0000000c r5:00000000 r4:c16555a0
[ 5406.530334] [<c014c3bc>] (sys_pwrite64+0x0/0x98) from [<c0058500>] (ret_fast_syscall+0x0/0x30)
[ 5406.530426]  r7:000000b5 r6:00000000 r5:00000000 r4:00000000
[ 5406.530944] CPU0: stopping
[ 5406.531036] Backtrace: 
[ 5406.531219] [<c005c598>] (dump_backtrace+0x0/0x10c) from [<c060c07c>] (dump_stack+0x18/0x1c)
[ 5406.531372]  r6:c07cf518 r5:fa240100 r4:00000000 r3:00000000
[ 5406.531829] [<c060c064>] (dump_stack+0x0/0x1c) from [<c0052490>] (do_IPI+0x190/0x1c4)
[ 5406.531982] [<c0052300>] (do_IPI+0x0/0x1c4) from [<c0057f48>] (__irq_svc+0x48/0xe4)
[ 5406.532165] Exception stack(0xc34cff68 to 0xc34cffb0)
[ 5406.532257] ff60:                   000000f0 5e7f2b34 000000ff 00000000 5ad9f3a8 5e7f2b34
[ 5406.532409] ff80: 93d00009 00000003 200f0010 5cea6568 ef000000 00000000 10c5387d c34cffb0
[ 5406.532592] ffa0: 40176040 c0058600 600f0013 ffffffff
[ 5406.532684] Rebooting in 5 seconds..
[ 5410.814727] Restarting Linux version 3.0.72-gfb3c9ac (android-build@vpbs1.mtv.corp.google.com) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Fri Jun 7 12:00:19 PDT 2013
[ 5410.814758] 

No errors detected
Boot info:
Last reset was warm software reset (PRM_RSTST=0x2)

Da ham wir den Salat! Extremst hässlich. Kaputte, irreparable Blöcke nach zehn Monaten alltagsgebrauch. Was ist da für ein Schrott verbaut? Ausschuss?
Keine fünf Minuten lang gefackelt, Online-Auftrag beim w-support fertig gemacht und ab damit in die Packstation. Heute kam das gute Stück wieder - scheint viel los oder im Momenz schlecht besetzt zu sein - hängt allerdings noch bei der Post und ich kann es morgen abholen.
Nach der Onlineverfolgung wurde das komplette Board getauscht. Ich stell mir vor, ich hätte das Ding am Freitag verkauft, den Käufer hätte ich heute noch an den Hacken.

 

[gokpog]

Schöne Analyse. Das könnte all denen helfen, die hier schon von ihren unerklärlichen Abstürzen berichtet haben. https://www.android-hilfe.de/forum/google-galaxy-nexus.405/absturz-neustart.300935-page-41.html

Auch da half idR nur ein Mainboard Tausch. Nur konnten es wenige für den Support so genau analysieren und hatten eine Menge Ärger mit nicht reparierten Geräten, da der Fehler beim Test durch den Service Partner nicht auftrat.

Vielleicht kannst du noch "Laien tauglich" erklären, wie du /proc/last_kmsg ausliest. Damit die Leute, die auf diesen Beitrag stoßen, ebenfalls nachschauen können ob ihr Speicher defekte Blöcke hat.

 

[0cram72]

Wow, ich wusste nicht, dass so viele davon betroffen sind.

Nochmal ganz konkret. Das Auslesen ist sehr einfach.
Man kann mit jedem beliebigen Dateimanager die Datei last_kmsg im Verzeichnis /proc/ entweder direkt mit einem Texteditor öffnen oder auf die interne sdcard (Verzeichnis /sdcard/0) kopieren und dann auf seinen Rechner kopieren.
Die Datei durchsucht man einfach nach "Kernel panic", unabhängig davon ob sich tatsächlich um den gleichen Fehler handelt, sollte man bei random reboots dort etwas finden können - Es sei denn es ist sowas wie eine abrupte Unterbrechung der Stromversorgung.

*edit*
Sch@tti hat mich darauf hingewiesen, dass das File /proc/las_kmsg wohl nur für root lesbar ist, ich dachte es sei world-readable, wenn dem aber so ist, muss euer Gerät zumindest gerootet sein, um die Datei auslesen zu können.

 

[grossernagus]

Müßte das nicht eigentlich ähnlich wie bei einer SSD funktionieren, daß defekte Zellen deaktiviert werden?

 

[0cram72]

Müßte das nicht eigentlich ähnlich wie bei einer SSD funktionieren, daß defekte Zellen deaktiviert werden?

Grundsätzlich denke ich das auch, ja.
Mir fiel auf, dass nach zehn I/O-Errors der Reboot kommt (siehe Log).
Entweder kann der Speicher das von den SSDs bekannte Verfahren nicht oder der dafür zuständige Controller ist defekt oder aber sie sind aufgebraucht. Das wäre alles vermutlich nicht in den logs erkennbar, da das normalerweise alles der Speicher selbst intern regelt. Wie das aber allgemein bei Smartphones funktioniert oder besser funktionieren sollte, ist mir nicht bekannt. Ich finde es nur äußerst ärgerlich, dass die Geräte scheinbar nur für ein Jahr ordentliche Alltagsnutzung ausgelegt sind.

Mein geliebtes Stück ist übriges wieder da und schon fleißig am arbeiten. Bisher hatte ich keine Probleme, ich hoffe das bleibt auch so, ich würde es irgendwann doch gerne guten Gewissens verkaufen können.

 

[HAL 9000]

Ich hab auch die Probleme mit random reboots und vor allem (viel häufiger als die reboots, ca alle 15min bei Benutzung des Handys) wahnsinnige lags (>10sec teilweise).

Ich denke fast, dass mein Handy jetzt auch seinen letzten Gang antritt (ist schon lange aus der Garantie raus), möchte mir aber sicher sein, dass es kein Software oder einfach zu behebender Hardware-Defekt ist.

Daten zu meinem Handy:

- AOKP stable jb-mr2 (aktuelle stable) mit lean-Kernel JB 4.3
- data und cache mit discard-Option gemountet, trim schon diverse Male durchgeführt
- mehr als 4 GB frei im internen Speicher

- im logcat finde ich keine I/O Fehler o.ä. (mittels "logcat > logcat.log && cat logcat.log | egrep '<suchbegriff>'" mit den Suchbegriffen "panic", "error" und "I/O")
- eine proc/last_kmsg ist nicht vorhanden (!)

Kennt jemand eine Methode, wie ich den Speicher prüfen kann oder welche logs ich noch auslesen könnte oder wie ich die vermuteten I/O-Fehler provozieren könnte? Ich möchte wie gesagt kein "noch gutes" Handy in die Schublade legen, nur weil ich irgendeinen SW-Fehler für einen HW-Defekt halte. Ich möchte aber auch nicht auf Verdacht alles neu installieren und einrichten, nur um dann rauszukriegen, dass es sehr wohl ein HW-Defekt war und ich mir die ganze Arbeit umsonst gemacht hab.

Viele Grüße
HAL

 

[rolli-d]

Hallo,

hast Du schon mal das Tool emmc Brickbug check installiert/ausgeführt?

Wenn du dann den Chip V3U00M hast dann auf jeden Fall mal lagfix free ausführen.

das hat bei mir alles perfekt geholfen. Seit dem ist Ruhe!
Bitte gib mal Feedback.

Gruß Rolli-d

 

[HAL 9000]

Dankeschön für den Tipp. Hab nicht den betroffenen V3U00M, sondern VYL00M. Die App kann auch die Blöcke prüfen und hat da mal keinen Fehler gefunden. Weiß jemand wie aussagekräftig der Test von der App ist und was genau der macht? Hatte nämlich kürzlich auch einen Festplatten-Ausfall, bei dem SMART steif und fest behauptete, die Festplatte wäre ok trotz 60 defekter Blöcke.

Und lagfix free hab ich auch. Das führt ja auch nur den trim-Befehl aus, so wie ich es in der Konsole auch selbst machen kann. Hab beide Varianten (Selbst mit Konsole und lagfix free) probiert, bringt beides keinen Effekt.

 

[brix-1]

Vielen Dank an 0cram72 für die detaillierte Fehlerbeschreibung.

Das gleiche Problem habe ich leider an meinem Nexus seit ein paar Tagen auch.
Kaufdatum war 10/2012 (im MM), so dass die Garantie abgelaufen ist.

Hilft hier eigentlich die 24-monatige Gewährleistung?
Falls nicht, wird (oder war) das wohl ein teuerer Spass.

 

[gokpog]

Samsung gibt 2 Jahre Garantie. Mit der Fehlerbeschreibung, am besten so ausführlich wie möglich ausgedruckt belegen, zu w-support oder einem Service Partner deiner Wahl schicken.

 

[kokoko]

Samsung gibt 2 Jahre Garantie. Mit der Fehlerbeschreibung, am besten so ausführlich wie möglich ausgedruckt belegen, zu w-support oder einem Service Partner deiner Wahl schicken.

Samsung gibt nur 1 Jahre Garantie, aber das spielt keine Rolle denn Media Markt muss Ihm 2 Jahre gesetzliche Gewährleistung bieten.

Bring das Gerät zu Media Markt die werden das kostenlos Reparieren

 

[brix-1]

Samsung gibt nur 1 Jahre Garantie, aber das spielt keine Rolle denn Media Markt muss Ihm 2 Jahre gesetzliche Gewährleistung bieten.

Jetzt bin ich etwas irritiert. Zunächst war ich auch von 12 Monaten ausgegangen, dann hatre ich mich über die Aussage gefreut, dass es auf Samsung-Geräte 2 Jahre gibt.
Jetzt deine Aussage, die wieder 12 Monate angibt.

Ich hab mal nachgesehen: auf Samsung Homepage findet sich folgende Aussage (zur Gerätegruppe "Telekommunikation")

Bei Erwerb nach dem 01.05.2006 gewährt Samsung für dieses Produkt eine Garantie gegen Material- und Verarbeitungsfehler für den Zeitraum von vierundzwanzig Monaten und von sechs Monaten auf im Lieferumfang befindliches Zubehör

Hast du andere Quellen, die besagen, dass die Garantie nur 12 Monate beträgt?

 

[kokoko]

Ich bin jetzt einfach davon ausgegangen dass Samsung heutzutage eigentlich immer nur 12 Monate Garantie gibt.

Aber das ist wie gesagt völlig egal, bringt das Gerät einfach zu Media Markt. Man hat in Deutschland eine 24 Monatige gesetzliche Gewährleistungspflicht.

Ob das Teil nun über die Garantie des Herstellers oder aber über die Gewährleistungspflicht des Händlers repariert wird, kann dir doch eigentlich egal sein, oder ? Hauptsache du bekommst es repariert zurück

EDT/ Ok hab mich geirrt, hier kann man die Garantie direkt überprüfen. Habe auch ein GNex von 08/12 und es hat noch bis 08/14 Garantie, also doch 2 Jahre.

Aber ich würde es trotzdem bei MM abgeben, so sparst du dir die Versandkosten ..

 

[mr.calamity]

Mich haben die random reboots auch seit Anfang der Woche erwischt...

Nach troubleshooting (Systemaktualisierung, dann altes Backup, Apps deinstalliert...) bin ich auf diesen Beitrag gestoßen und siehe da, auch bei mir massenhaft defekte Sektoren!!

Zum Glück habe ich noch Gewährleistung von Amazon und möchte das Handy nächste Woche einschicken... Jetzt nochmal eine kleine Frage in die Runde: Es wurde ja geraten die wichtigsten Zeilen der last_ksmg auszudrucken und der Fehlerbeschreibung beizulegen! Aber zeigt das nicht den Verantwortlichen sofort, dass man das Gerät gerooted hat und ist damit die Gewährleistung nicht verspielt?
Wie haben das denn die anderen gehandhabt?

Kleines Ergänzug zu den tollen Hinweisen von Ocram72:
Falls man die Datei last_kmsg nicht finden kann (wie ich!! =D ) dann sollte man folgendes tun: Wir brauchen die Terminal Emulator App aus dem Playstore, tippen dort "su" ein, dann Enter, dann "cat(leertaste)/proc/last_kmsg(Leertaste)>(Leertaste)/sdcard/last_kmsg.txt, dann wieder Enter. Sucht man dann mit einem Dateimanager nach der "last_kmsg"-datei wird man fündig und kann diese dann auch kopieren und beispielsweise auf der SD-Karte deponieren und dann über den PC auslesen!! ;-)

 

[meLAW]

Erstmal fettes Danke an 0cram72!
Auch bei mir gibts seit ein paar Tagen diese Reboots, das ist schon sehr lästig (mobile Bordkarte am Flughafen, mitten auf der Autobahn als Navi...)
Genau wie beim Threadstarter steht ein Kernelpanic im logfile, es sieht fast exakt so aus wie im ersten Post!! Bingo!
Ich habe noch ein paar Monate Garantie bei Amazon und werde es demnächst einschicken.
Ohne diesen Thread (Zufallsfund) hätte ich wohl neu geflasht und nach all der Arbeit bald wieder reboots gehabt!

Nur zur Vollständigkeit, meine Frage ist ähnlich meines Vorposters.
Die blieb unbeantwortet daher hole ich den Thread nochmal hervor:

stockrom flashen, bootloader schließen ist klar...
Als Fehlerbeschreibung dann aber trotzdem angeben, dass man aus den logdateien herauslesen konnte, dass es ein Speicherfehler ist, oder lieber einfach nur die random reboots beklagen?
Oder kann man den bootloader offen und customrom drauflassen?