aarch64 / Journaled Soft Updates / Kernel Panic bei fsck

pooltechniker

Well-Known Member
Habe hier ein seltsames Problem; hier die chronologische Reihenfolge:
1. FreeBSD Image mittels crochet aus releng/13.0 für aarch64 (Orange Pi Zero Plus) gebaut
2. Image geflasht, Orange Pi Zero Plus erfolgreich gebootet
3. System mittels freebsd-update auf den Letztstand gebracht
4. Installation div. Pakete mittels pkg; bei der Installation von Python 3.8 bliebt das System hängen; Login via SSH war noch möglich, Shell kam aber keine mehr
5. Power Cycle - danach bootete FreeBSD nicht mehr wegen eine inkonsistenten Filesystems:
Code:
mmc1: <MMC/SD bus> on aw_mmc0
mmcsd0: 64GB <SDHC SC64G 8.0 SN 8B0D14CD MFG 08/2018 by 3 SD> at mmc1 50.0MHz/4bit/32768-block
mmc1: Failed to set VCCQ for card at relative address 43690
uhub2: 1 port with 1 removable, self powered
uhub4: 1 port with 1 removable, self powered
mountroot: waiting for device /dev/mmcsd0s2a...
WARNING: / was not properly dismounted
Setting hostuuid: 30633238-3030-3130-6462-623536366366.
Setting hostid: 0x005c1ace.
Starting file system checks:
** SU+J Recovering /dev/mmcsd0s2a
** Reading 4194304 byte journal from inode 4.
aw_mmc0: prepare_dma failed: 27
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
mmcsd0: Error indicated: 1 Timeout
/dev/mmcsd0s2a: Error reading journal block 41408
/dev/mmcsd0s2a: UNEXPECTED SU+J INCONSISTENCY
/dev/mmcsd0s2a: INTERNAL ERROR: GOT TO reply()
/dev/mmcsd0s2a: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY.

aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
mmcsd0: Error indicated: 1 Timeout
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
mmcsd0: Error indicated: 1 Timeout
aw_mmc0: controller timeout
6. fsck der SD-Karte in einem anderen FreeBSD-Rechner
7. Neuerlicher Versuch, Pyhton 3.8 zu installieren - Rechner bleibt wieder hängen, Filesystem inkonsistent, neuerlicher fsck
8. Der Versuch, Journaled Soft Update zu deaktivieren schlägt fehl, da das Filesystem angeblich nach wie vor inkonsistent ist
9. Boot in den Single User Mode, um fsck zu starten. Endet mit einer Kernel Panic:
Code:
mmc1: <MMC/SD bus> on aw_mmc0
mmcsd0: 64GB <SDHC SC64G 8.0 SN 8B0D14CD MFG 08/2018 by 3 SD> at mmc1 50.0MHz/4bit/32768-block
mmc1: Failed to set VCCQ for card at relative address 43690
uhub1: 1 port with 1 removable, self powered
uhub0: 1 port with 1 removable, self powered
mountroot: waiting for device /dev/mmcsd0s2a...
Enter full pathname of shell or RETURN for /bin/sh:
root@:/ # fsck -y /
** /dev/mmcsd0s2a
** SU+J Recovering /dev/mmcsd0s2a

USE JOURNAL? yes

** Reading 4194304 byte journal from inode 4.
aw_mmc0: prepare_dma failed: 27

aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
mmcsd0: Error indicated: 1 Timeout
Error reading journal block 41408
UNEXPECTED SU+J INCONSISTENCY

FALLBACK TO FULL FSCK? yes

** Skipping journal, falling through to full fsck

aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
mmcsd0: Error indicated: 1 Timeout
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
mmcsd0: Error indicated: 1 Timeout

CANNOT READ BLK:panic: vm_fault_lookup: fault on nofault entry, addr: 0xffff000044189000
cpuid = 2
time = 1645555374
KDB: stack backtrace:
#0 0xffff00000050d058 at kdb_backtrace+0x60
#1 0xffff0000004b7228 at vpanic+0x184
#2 0xffff0000004b70a0 at panic+0x44
#3 0xffff00000077f790 at vm_fault+0x1964
#4 0xffff00000077dd48 at vm_fault_trap+0x9c
#5 0xffff000000824c48 at data_abort+0xf4
#6 0xffff000000805078 at handle_el1h_sync+0x78
#7 0xffff000000802164 at bounce_bus_dmamap_sync+0x22c
#8 0xffff0000007bd0d0 at aw_mmc_request+0x3ec
#9 0xffff000000203ed4 at mmc_wait_for_request+0x128
#10 0xffff00000020d3f4 at mmcsd_rw+0x1a8
#11 0xffff00000020bf0c at mmcsd_task+0x284
#12 0xffff0000004677ec at fork_exit+0x88
#13 0xffff000000823ae8 at fork_trampoline+0x10
Uptime: 1m14s
10. Erneuter Boot in den Single User Mode, um Journaled Soft Updates endgültig zu deaktivieren
11. Endlich läuft FreeBSD stabil (zumindest derzeit), auch bei hohem I/O (Entpacken div. Archive auf der SD-Karte)

Hat hier jemand Erfahrung mit FreeBSD und UFS auf aarch64? Für mich sieht das nach einem Problem mit SU+J aus. Ist das eventuell Architekturabhängig?
Interessant finde ich vor allem diese Meldungen:
Code:
aw_mmc0: controller timeout
aw_mmc0: timeout updating clock
Wenn SU+J abgedreht sind, sehe ich diese Meldungen nicht mehr.

Wo melde ich diese Kernel Panic am besten?

Das obligatorische uname -a:
Code:
FreeBSD dns1 13.0-RELEASE-p6 FreeBSD 13.0-RELEASE-p6 #0: Mon Jan 10 06:33:27 UTC 2022     root@arm64-builder.daemonology.net:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64
 
SU+J braucht sehr hochwertige Hardware, die nicht lügt. Das mmc-Modul ist sicher vieles, aber nicht hochwertig. ;) Ich würde auf @KobRheTilla hören und mich auf einfache Softupdates beschränken. Bei allen Formen von Flashspeicher ist das fsck auch ohne Journaling schnell genug und für alles, wo es auf die letzten Sekunden ankommt, nimmt man inzwischen eh ZFS. Daher ist das Journaling auch etwas ein verlorenes Kind. Es ist da und man will sich nicht so recht von ihm trennen, also läuft es halt mit.
 
Ich verwende seit der Anfangszeit wo ich es kurz im Einsatz hatte auch kein SU+J mehr weil es die verrücktesten Probleme machte. Leider ist es den FreeBSD Leuten auch egal.
Ich behaupte mal das war auch hochwertige HW (Server SAS Platten, in einem Dell Server).

Immerhin hatte ich aber auch mit SU allein noch nie irgendwelche Inkonsistenzen und ich verwende gerne noch UFS auf Systempartitionen/Platten.
 
Vielen Dank euch allen!
Ich kann mich dunkel erinnern, dass es damals, vor vielen, vielen Jahren, als SU+J eingeführt wurde, schon viele Diskussionen darüber gab, und der Tenor eher gegen SU+J ging. Ich hatte gehofft, dass, wenn es per Default aktiv ist, auch brauchbar funktioniert - vor allem nach so langer Zeit. Dass SU+J hochwertige Hardware voraussetzt war mir nicht bewusst.
ZFS ist hier leider kein Thema, der Orange Pi hat nur 512 MB RAM, daher habe ich dieses Experiment gleich gar nicht gewagt.

Ich hab in den letzten knapp 24 Stunden noch einige Tests durchgeführt, ohne Journaling läuft die Kiste stabil, so wie ich mir das vorstelle - damit kann ich endlich meinen bestehenden Orange Pi mit Armbian in Rente schicken, und hab nach Ewigkeiten endlich wieder mal ein BSD am Laufen :)
 
Ich habe mit FreeBSDs ZFS Implementierung keinerlei Erfahrung, aber selbst auf einem 15 Jahre alten Solaris 10 macht ZFS mit so wenig RAM einfach keinen Sinn. Da das ganze nicht mehr als ein simpler DNS Resolver wird, sehe ich hier jetzt auch nicht unbedingt Bedarf an ZFS. Da die Kiste inzwischen mit UFS ohne Journaling stabil läuft, wird es auch dabei bleiben.
 
Ich würde auf dem System auf keinen Fall ZFS nehmen. ZFS ist einfach nicht für so kleine Systeme gedacht. Ich hatte ZFS oben nur erwähnt, da es hoffentlich keine riesigen UFS-Arrays auf HDDs mehr geben wird und daher die fsck-Zeiten nicht mehr so relevant wie vor 10 Jahren sind.
 
... FreeBSDs ZFS Implementierung ...
Also so wie ich mitbekommen habe, hat man die wegrationalisiert und OpenZFS importiert.
Und das geht ganz gut. Z.B. ARC ist nicht mehr so gierig, was mir persönlich gefällt.
Aber für kleine Systeme ist UFS+SU (ohne J) wirklich das Beste, zumal man den Berichten zufolge als absolutes Minimum für ZFS 768MB ansetzen sollte, wenn noch ein wenig Speicher für Programme benötigt wird.
 
Ich würde auf dem System auf keinen Fall ZFS nehmen. ZFS ist einfach nicht für so kleine Systeme gedacht. Ich hatte ZFS oben nur erwähnt, da es hoffentlich keine riesigen UFS-Arrays auf HDDs mehr geben wird und daher die fsck-Zeiten nicht mehr so relevant wie vor 10 Jahren sind.
Schon klar... ich hantiere seit vielen Jahren tagtäglich mit einer dreistelligen Anzahl an Kisten mit ZFS @work - halt unter Solaris, daher war/ist mir das schon bewusst :)

Also so wie ich mitbekommen habe, hat man die wegrationalisiert und OpenZFS importiert.
Und das geht ganz gut. Z.B. ARC ist nicht mehr so gierig, was mir persönlich gefällt.
Aber für kleine Systeme ist UFS+SU (ohne J) wirklich das Beste, zumal man den Berichten zufolge als absolutes Minimum für ZFS 768MB ansetzen sollte, wenn noch ein wenig Speicher für Programme benötigt wird.
Stimmt... das ist ja inzwischen OpenZFS.
Unter FreeBSD hab ich damit nicht wirklich Erfahrung - unter Solaris ist es nach wie vor so, dass, sofern man den ARC nicht begrenzt, jedes freie MB dafür genutzt wird (was ja prinzipiell auch OK ist); bei Bedarf wird er ja wieder freigegeben.
 
Zurück
Oben