Re: Emulated macppc with qemu
Havard Eidnes <[email protected]> Mon, 05 Apr 2021 14:20:42 +0200 (CEST)
| Newsgroups | gmane.os.netbsd.ports.macppc |
|---|---|
| Message-ID | <[email protected]> |
>> 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