Port-macppc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Emulated macppc with qemu



>> The script I've used to start and run the installer with is
>> ---
>> #!/bin/sh
>> MEM=2g
>> qemu-system-ppc \
>>          -M mac99,via=pmu \
>>          -m $MEM  \
>>          -nographic \
>>          -drive id=hda,format=raw,file=disk.img \
>>          -L pc-bios \
>>          -netdev user,id=net0,hostfwd=tcp::2223-:22,ipv6=off \
>>          -net nic,model=rtl8139,netdev=net0 \
>>          -boot d \
>>          -cdrom NetBSD-8.2-macppc.iso
>> ---
>> The installer is booted up with "boot cd:\ofwboot.xcf".
>
> Is there any reason that you're overriding the default sungem NIC for
> QEMU's macppc machines? You should be able to drop the model=rtl8139
> here and end up with a more realistic hardware configuration.

None other than it's probably a holdover from my unfamiliarity
with qemu.

...

I tried dropping the model= setting, and got

[   1.0000000] gem0 at pci0 dev 15 function 0: Apple Computer GMAC Ethernet (rev. 0x01)
[   1.0000000] gem0: interrupting at irq 30
[   1.0000000] gem0: cannot reset receiver
[   1.0000000] gem0: cannot reset receiver
[   1.0000000] bmtphy0 at gem0 phy 0: BCM5201 10/100 media interface, rev. 0
[   1.0000000] bmtphy0: 100baseTX-FDX, auto
[   1.0000000] gem0: Ethernet address 52:54:00:12:34:56, 20KB RX fifo, 9KB TX fifo

so that looks "sort of" promising, but on use, I get the same
error:

eple# sh /etc/rc.d/network restart
Stopping network.
Deleting aliases.
Downing network interfaces: gem0.
Starting network.
Hostname: eple.urc.uninett.no
IPv6 mode: host
Configuring network interfaces: gem0[ 251.7799484] gem0: cannot reset receiver
[ 252.7927702] gem0: cannot reset receiver
[ 253.8297412] gem0: cannot reset receiver
[ 254.8425581] gem0: cannot reset receiver

and it appears to be stuck there, so ... hm, not so good.  It
also looks like the VM has hung, it doesn't respond to ^T at that
point... and ... doesn't respond to break via C-a b either.

So ... back to rtl8139 it is for now.  (I made an earlier attempt
with fxp0 "hardware", and that also wasn't trouble-free, but may
also have been while I tried using 3GB memory, ref. below.)

>> There appears to be something finicky about the amount of memory:
>> 1G fails with a trap early on, 3G fails as described in
>>    https://bugs.launchpad.net/bugs/1922391
>> quite a bit into the installation, but with 2G I've managed to
>> install and it appears to run stably as well.
>
> Hmmm that's odd - it looks like something has unmapped the DMA memory
> used for the macio IDE request before the QEMU host IO callback has
> completed?

I admit that I would not know...

That said, I don't know of any actual G4 Macs which can be
equipped with more than 2GB physical memory either, so this is
probably excercising "unfamiliar terroitory".

>> Speed-wise it's nothing to write home about, but it's not
>> entirely unusable either: a 1.5GHz G4 Mac Mini gives this with
>> "openssl speed sha1":
>> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
>> sha1 5365.74k 19695.50k 64076.54k 146566.70k 235167.74k
>> while the emulated system on a i7-4790 host gives
>> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
>> sha1 1123.70k 4264.97k 15203.62k 40735.26k 86124.15k
>
> If you are looking for more IO speed, you can always use
> virtio-blk-pci and virtio-net devices after the install has completed
> which should help considerably. My TODO list does include adding
> virtio-scsi support for OpenBIOS one day...

OK, thanks, I'll keep that in mind.  I think the "openssl speed"
test is more a CPU exerciser, though, so those won't help with
that, but every speedup helps to make it more usable, of course.

Regards,

- Håvard


Home | Main Index | Thread Index | Old Index