Hi George,
nice. Ill do the next days. Thank you very much.
Best regards
Andreas
On 9/11/21 3:01 AM, George Koehler wrote:
On Fri, 10 Sep 2021 15:26:39 +0200
Andreas Drewke <andr...@drewke.net> 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
