As I mentioned in a previous mail, bsd.mp always crashes during boot on the
Pinephone, (whereas the sp kernel does not).
Until now, it's usually been impossible to enter ddb and get further
information, but this time ddb was responsive:
Stopped at 0x7effff80004afc68: panic: attempt to access user address 0
x7effff80004afc68 from EL1
Stopped at panic+0x160: cmp w21, #0x0
TID PID UID PRFLAGS PFLAGS CPU COMMAND
453089 43751 0 0x14000 0x200 3 cleaner
403310 55046 0 0x14000 0x200 2 reaper
19527 89680 0 0x14000 0x200 1 pagedaemon
* 0 0 0 0x10000 0x200 0K swapper
db_enter() at panic+0x15c
panic() at do_el1h_sync+0x1f8
do_el1h_sync() at handle_el1h_sync+0x6c
handle_el1h_sync() at db_read_bytes+0x74
db_read_bytes() at db_get_value+0x40
db_get_value() at disasm+0x2c
disasm() at db_trap+0x84
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}>
ddb{0}> show panic
*cpu0: attempt to access user address 0x7effff80004afc68 from EL1
ddb{0}> trace
db_enter() at panic+0x15c
panic() at do_el1h_sync+0x1f8
do_el1h_sync() at handle_el1h_sync+0x6c
handle_el1h_sync() at db_read_bytes+0x74
db_read_bytes() at db_get_value+0x40
db_get_value() at disasm+0x2c
disasm() at db_trap+0x84
db_trap() at kdb_trap+0xc8
kdb_trap() at db_trapper+0x48
db_trapper() at do_el1h_sync+0x1d0
do_el1h_sync() at handle_el1h_sync+0x6c
handle_el1h_sync() at 0x7effff80004afc64
7effff80004afc68 at 0xffffff80005f5788
clock_set_frequency_idx() at cpu_opp_mountroot+0x108
cpu_opp_mountroot() at config_process_deferred_mountroot+0x5c
config_process_deferred_mountroot() at main+0x5dc
main() at $x.2+0x70
ddb{0}> mach ddbcpu 1
Unfortunately it stopped responding as soon as I tried to get a trace from cpu
1.
So something in clock_set_frequency_idx made it access non-kernel memory space?
