Bugreport-Analyse – Philips 43PUS7394/12

Nachtrag 2026-08-25: Eine spätere, rein lesende Abfrage des noch vorhandenen Android-Eventpuffers lieferte storaged_emmc_info: [emmc 5.1,1,10,10]. Die geräteeigene Event-Tagdefinition weist die Felder als (mmc_ver,eol,lifetime_a,lifetime_b) aus. Damit ist PRE_EOL_INFO=0x01 (Normal) entgegen den damaligen, nur auf den extrahierten Haupttext bezogenen Nichtfund-Aussagen inzwischen bestätigt. Der Bericht unterscheidet unten zwischen dem ursprünglichen Haupttext-Nichtfund, dem späteren Event-Export und dem weiterhin gesperrten direkten Rohbyte.

Stand: 2026-08-25. Der Bugreport wurde mit dem normalen, autorisierten ADB- Zugang erzeugt. Alle Aktionen am Fernseher waren lesend; Entpacken und Suchen erfolgten ausschließlich im lokalen Workspace.

Erzeugung und Vollständigkeit

Merkmal	Ergebnis
Datei	`bugreport-PH9M_EA_5599-STT2.230526.001-2026-08-25-13-26-44.zip`
lokale Größe	6.420.496 Byte (6,12 MiB)
lokaler Zeitstempel	2026-08-25 13:29:05 +02:00
ZIP-Einträge	1.790
extrahierte Dateien	1.792, einschließlich zweier Einträge aus einem eingebetteten ZIP
extrahierte Nutzdaten	61.268.602 Byte
Hauptbericht	46.511.209 Byte
Textsuche	1.787 Dateien geprüft, 5 Binärdateien ausgelassen, 2.450 Trefferzeilen

Windows Expand-Archive konnte Android-Dateinamen mit :: und einzelne sehr lange cgroup-Pfade nicht abbilden. Deshalb wurde das ZIP mit extract_bugreport.py verlustfrei in flach nummerierte Dateien extrahiert. extracted/manifest.tsv ordnet jede lokale Datei ihrem ursprünglichen ZIP-Pfad zu. Dieser Fehler betraf nur die lokale Extraktion, nicht den Bugreport auf dem Fernseher.

Dumpstate-Einschränkungen

Der Hauptbericht ist verwertbar, aber nicht vollständig privilegiert:

perfetto --save-for-bugreport wird auf diesem user-Build nicht unterstützt;
der historische logcat -L-Abruf scheiterte;
iotop ist nicht installiert;
mehrere HIDL-Debug-Aufrufe, darunter TPV-/MediaTek-Dienste, antworteten mit FAILED_TRANSACTION;
dumpstate meldet ausdrücklich No IDumpstateDevice implementation;
deshalb existiert weder dumpstate_board.bin noch dumpstate_board.txt;
der Kernel-Log-Abschnitt enthält nur Unexpected klogctl return value: -1;
/proc/last_kmsg fehlt; der Recovery-last_kmsg-Eintrag ist leer;
Dienst-Dumps von UpdateEngineService scheiterten, die separaten Update-Engine-Logdateien sind jedoch vorhanden und erfolgreich.

IDumpstateDevice ist eine optionale OEM-Schnittstelle. Ihr Fehlen bedeutet, dass dieser Build keinen zusätzlichen Philips/TPV-Board-Dump in den Standard-Bugreport einspeist. Die leeren lshal-debug-Dateien liefern daher keine weitere eMMC-Gesundheitsinformation. Siehe AOSP: Scoped vendor logging.

eMMC-Befunde

Der Bugreport bestätigt unabhängig von den vorherigen Einzelabfragen:

[persist.odm.tpv.sys.emmc_lifetime]: [0x0a 0x0a]
[init.svc.emmclifereaderd]: [stopped]
[ro.boottime.emmclifereaderd]: [11750142162]
OnBootLogger: logEMMCDetails devLifeTime = 0x0a 0x0a
dev_lt_a:"a", dev_lt_b:"a"
TVStorageMonitorService: propvalue = 0x0a 0x0a
TVStorageMonitorService: EmmcLifetime 90%-100% device lifetime used

Die ursprüngliche native Boot-Zeile D eMMCLifeReader: eMMC life time 0x0a 0x0a ist im neuen Bugreport nicht mehr im aktuellen Log-Ring enthalten; sie bleibt in den zuvor gesicherten Bootlogs belegt. Der neue Bericht wiederholt denselben Wert über Property, OnBootLogger und TVStorageMonitorService über mehrere Stunden.

Neu ist die genaue Debugfs-Quelle, auf die Androids storaged zugreifen wollte:

root 2644 storaged: avc: denied { read }
path="/sys/kernel/debug/mmc0/mmc0:0001/ext_csd"
scontext=u:r:storaged:s0
tcontext=u:object_r:debugfs_mmc:s0

Damit sind Gerät mmc0:0001, ein vorhandener EXT_CSD-Debugfs-Knoten und die SELinux-Sperre direkt belegt. Bemerkenswert ist: Auch der Prozess storaged mit Linux-UID root wurde blockiert. Ein bloßer UID-0-Zugang würde den Wert daher nicht automatisch lesbar machen; zusätzlich wäre ein geeigneter SELinux-Domain-/Policy-Zugang erforderlich.

Für life_time und pre_eol_info enthält der extrahierte Hauptbericht die Audit-Denials der ADB-Shell. Dort erscheint kein ausgeschriebener PRE_EOL_INFO-Wert. Die spätere Eventlog-Abfrage hat den Wert jedoch als eol=1 bestätigt. Weiterhin fehlen ein vollständiger EXT_CSD-Rohdump, CID und eine Hersteller- oder Modellkennung.

Life Time A, Life Time B und PRE_EOL

Feld	Befund	Status
Life Time A	Philips speichert `0x0a`; OnBootLogger meldet `dev_lt_a="a"`	belegt: 90–100 % verbraucht
Life Time B	Philips speichert `0x0a`; OnBootLogger meldet `dev_lt_b="a"`; TVStorageMonitor wertet diesen zweiten Wert aus	belegt: 90–100 % verbraucht
PRE_EOL_INFO	direkter Pfad für Shell gesperrt; späterer Storaged-Event meldet `eol=1`	bestätigt: `0x01` (Normal); Rohbyte nicht direkt gelesen

Die Interpretation von 0x0a stützt sich auf die JEDEC-Wertetabelle, wie sie beispielsweise in Herstellerunterlagen wiedergegeben wird. Der genaue Verschleiß innerhalb des 10-%-Bandes ist nicht bestimmbar.

Prüfung auf Storage-Fehler

Die automatisierte Suche erfasste Hauptbericht, ANRs, Recovery-Logs, Incident-Report, Update-Engine-Logs und alle eingebetteten Textdateien. Danach wurden die Treffer manuell klassifiziert.

Nicht gefunden wurden:

EXT4-fs error, Journal-Fehler oder schreibgeschützte Remounts;
Buffer I/O error, Block-I/O-Fehler oder blk_update_request;
MMC-Timeouts, CRC-/ECC-Fehler, Controller-Resets oder Command-Fehler;
disk I/O error, SQLite-malformed oder nachgewiesene DB-Korruption;
OTA-Schreibfehler oder erfolglose Update-Engine-Aktionen;
ein unerwarteter Neustart mit belegtem Storage-Bezug.

Die vier automatischen Treffer der Kategorie storage_errors waren:

ein DNS/SSL-write error mit Try again;
ein TLS-Lesefehler nach Connection reset by peer;
ein TLS-Shutdown mit Broken pipe;
incidentd: Buffer corrupted beim Lesen eines Incident-Puffers.

Keiner dieser Treffer ist einem Blockgerät oder Dateisystem zuzuordnen. Alle sechs enthaltenen Update-Engine-Logs enden mit ErrorCode::kSuccess und Processing Done. PackageManager-Meldungen, dass ältere Systemkopien wegen vorhandener neuerer Updates nicht ausgewählt wurden, sind normale Paket-Selektion und keine Schreibfehler.

Das Fehlen sichtbarer Fehler ist ausdrücklich kein Gesundheitsnachweis: Kernel-dmesg, EXT4-Fehlerzähler und OEM-Board-Dumps fehlen. Es bedeutet nur, dass im verfügbaren Diagnosefenster kein Storage-Fehler nachweisbar ist.

Ergebnis

Der Bugreport bestätigt die bisherige Speicherursache und die beiden Philips-eMMC-Werte, liefert aber keinen dritten Health-Wert. Sein stärkster neuer Beitrag ist die direkte Identifikation des EXT_CSD-Knotens und der SELinux-Barriere. Ein unmittelbarer Medienausfall ist nicht belegt; die beiden hohen Life-Time-Bänder bleiben dennoch ein ernstzunehmender Verschleißhinweis.

Lokale Artefakte

bugreport/original/: unverändertes ZIP
bugreport/extracted/manifest.tsv: vollständige Pfadzuordnung
bugreport/analysis/search-hits.tsv: Treffer mit Quelle, Zeile und Kontext
bugreport/analysis/search-summary.tsv: Treffer je Datei/Kategorie
bugreport/analysis/search-totals.tsv: Summen je Kategorie
bugreport/analysis/binary-skipped.tsv: ausgelassene Binärdateien

7.5 KiB Raw Permalink Blame History Unescape Escape