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:
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:
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:
Wenn SU+J abgedreht sind, sehe ich diese Meldungen nicht mehr.
Wo melde ich diese Kernel Panic am besten?
Das obligatorische uname -a:
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
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
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
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