On Tue, 12 Jul 2022, Mark Cave-Ayland wrote:
On 11/07/2022 08:42, Cédric Le Goater wrote:
Anything special I should know ?
As I don't have access to a G5 I've never tried that, however the
qemu-system-ppc64 mac99 is wired differently to the qemu-system-ppc mac99
machine so I wouldn't be surprised if something is broken there.
My normal test for MacOS is something like:
qemu-system-ppc -M mac99 -accel kvm -hda macos104.img
Can you try qemu-system-ppc and see if it is any better? If not then I can
fire up the G4 and get the git hashes for my last known working
configuration.
Same issue with 32bit.
I've just fired up my G4 to test this again, pulled the latest QEMU git
master and confirmed that I have a working setup with the details below:
Host kernel: (5.1.0-rc2+)
commit a3ac7917b73070010c05b4485b8582a6c9cd69b6
Author: Linus Torvalds <torva...@linux-foundation.org>
Date: Mon Mar 25 14:49:00 2019 -0700
Guest kernel: (4.14.0-3-powerpc)
using Debian ports debian-9.0-powerpc-NETINST-1.iso
Command line:
./qemu-system-ppc [-M mac99] -accel kvm -cdrom
/home/mca/images/debian-9.0-powerpc-NETINST-1.iso -boot d -nographic
However if I switch to using the latest Debian ports
debian-10.0.0-powerpc-NETINST-1.iso then I get a failure:
[ 0.198565] BUG: Unable to handle kernel data access on read at 0xbb0030d4
What is or should be at this address and why does the kernel access it? By
default I see nothing mapped there. Do you need more RAM? Maybe the
default 128 MB is not enough for newer kernels? I've seen such problem
with other OSes before.
Regards,
BALATON Zoltan
[ 0.205152] Faulting instruction address: 0x0001b0c4
[ 0.210175] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.214933] BE PAGE_SIZE=4K MMU=Hash PowerMac
[ 0.218226] Modules linked in:
[ 0.220746] CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-2-powerpc #1
Debian 5.6.14-1
[ 0.226967] NIP: 0001b0c4 LR: 000030d4 CTR: 00000000
[ 0.230869] REGS: c7fb5908 TRAP: 0300 Not tainted (5.6.0-2-powerpc
Debian 5.6.14-1)
[ 0.236844] MSR: 00001012 <ME,DR,RI> CR: 24002820 XER: 20000000
[ 0.242096] DAR: bb0030d4 DSISR: 40000000
[ 0.242096] GPR00: c0044e70 c7fb59c0 c0b26510 c7fb5f48 bb0030d4 40000000
00000000 00000001
[ 0.242096] GPR08: ff340038 bb0030d4 00001032 c7fb59c0 00000000 00000000
00000000 00000004
[ 0.242096] GPR16: 029c61f0 029c5d68 07c5cd08 00000001 029dd844 fffffffd
fff55d10 42000000
[ 0.242096] GPR24: c0af6704 c0b20d94 00000000 00000000 c0bd862c 00000000
00000000 0000000d
[ 0.271138] NIP [0001b0c4] 0x1b0c4
[ 0.273978] LR [000030d4] 0x30d4
[ 0.276410] Call Trace:
[ 0.278812] Instruction dump:
[ 0.281219] 55290206 XXXXXXXX XXXXXXXX XXXXXXXX 4c00012c XXXXXXXX XXXXXXXX
XXXXXXXX
[ 0.287561] 419f0028 XXXXXXXX XXXXXXXX XXXXXXXX 81690000 XXXXXXXX XXXXXXXX
XXXXXXXX
[ 0.293922] ---[ end trace 3a9d775bab6f3340 ]---
[ 0.297491]
[ 1.284408] Kernel panic - not syncing: Attempted to kill the idle task!
[ 1.290027] ---[ end Kernel panic - not syncing: Attempted to kill the
idle task! ]---
Decompressing the initrd takes quite a long time, but I think this is the
issue that was recently discussed on the mailing list?
I think the next step should be to move my host kernel forward to a more
current version with the working debian-9.0-powerpc-NETINST-1.iso and see if
it is able to boot without any problems.
ATB,
Mark.
