On Fri, 10 Sep 2021 15:26:39 +0200 Andreas Drewke <[email protected]> wrote:
> Unfortunatly the G5 doesnt accept any input after this crash from > keyboard. :( > Is there another way to do a trace? After OpenBSD/macppc draws on the framebuffer (when the screen goes dark and changes font), there's no keyboard until you see ukbd0 in the dmesg. Your panic is too early. There is a trace of cpu0 in your photo, but it's empty: | db_enter(...) at db_enter+0x20 | End of kernel: 0xc4c710 | end trace frame: 0xc4c710, count: 14 The best hint might be this line: | panic: trap type 400 srr1 10001032 at 7c200164 (end+...) lr 148e30 Trap 0x400 is EXC_ISI, so cpu0 jumped outside its executable code into 7c200164 (end+...), which is far beyond the end of the kernel. The return address lr 148e30 is in the kernel, but I don't know where, because kernels are randomly reordered. To get around your panic, it might work to disable radeondrm. The commands will be something like, > boot hd:,ofwboot boot> boot -c UKC> disable radeondrm UKC> exit If that works, you might be able to - install a snapshot, so you kernel has the new drm code; - boot to panic, and copy the "trap 400" line; - reboot with disable drm, and check /bsd.booted Each boot copies /bsd to /bsd.booted and reorders /bsd, but your panic happens before that. On the next successful boot, /bsd.booted should be a copy of the panic kernel. If a snapshot kernel panics, would you mail to me (off list) a copy of /bsd.booted, along with the "trap type 400" line and the output of "sysctl kern.version"? (Another photo would work.) I can't reproduce your panic; my G5 has nvidia, not radeon. --George
