GSOC qemu Boot Mac OS >= 8.5 on PowerPC system

[mcayland]

Even if there is a hang, there isn't enough information available to help someone else reproduce your exact environment - we need considerably more detail, enough for someone else to be able to reproduce the issue locally. Given that no-one else can see this it could be something that is Windows-specific (the block routines have had a massive overhaul in the 2.7 cycle) so do you still see an error if you build/run in a Linux VM or on MacOS?

[raidenii]

It has hung there for two hours... I got some disk errors dialog yesterday.

Another try:

Even if there is a hang, there isn't enough information available to help someone else reproduce your exact environment - we need considerably more detail, enough for someone else to be able to reproduce the issue locally. Given that no-one else can see this it could be something that is Windows-specific (the block routines have had a massive overhaul in the 2.7 cycle) so do you still see an error if you build/run in a Linux VM or on MacOS?

I have compiled Windows version and seems the latest git on ppc-for-2.7 branch do have some issues on block transfer. I always receive a VC++ error at the end of installation and QEMU crashes, which does not occur on the code checked out on Jul 15th.

[mcayland]

Even if there is a hang, there isn't enough information available to help someone else reproduce your exact environment - we need considerably more detail, enough for someone else to be able to reproduce the issue locally. Given that no-one else can see this it could be something that is Windows-specific (the block routines have had a massive overhaul in the 2.7 cycle) so do you still see an error if you build/run in a Linux VM or on MacOS?

I have compiled Windows version and seems the latest git on ppc-for-2.7 branch do have some issues on block transfer. I always receive a VC++ error at the end of installation and QEMU crashes, which does not occur on the code checked out on Jul 15th.

Aha now that is *very* useful information. Can you do a "git bisect" to identify the offending commit?

Actually: dgibson's branch has now been merged into git master, so can you try vanilla git master with a custom OpenBIOS first just in case dgibson's branch was out of date? If that still hangs, then go for the "git bisect".

[raidenii]

Aha now that is *very* useful information. Can you do a "git bisect" to identify the offending commit?

Actually: dgibson's branch has now been merged into git master, so can you try vanilla git master with a custom OpenBIOS first just in case dgibson's branch was out of date? If that still hangs, then go for the "git bisect".

Cloned vanilla qemu master branch and had errors during installation. The transfer error seems to occur randomly.
I'll clone the branch on ppc-for-2.7 and try using bisect to walk backwards, but that will take a LONG time...

[mcayland]

Aha now that is *very* useful information. Can you do a "git bisect" to identify the offending commit?

Actually: dgibson's branch has now been merged into git master, so can you try vanilla git master with a custom OpenBIOS first just in case dgibson's branch was out of date? If that still hangs, then go for the "git bisect".

Cloned vanilla qemu master branch and had errors during installation. The transfer error seems to occur randomly.
I'll clone the branch on ppc-for-2.7 and try using bisect to walk backwards, but that will take a LONG time...

As a starting point, can you provide the git hash of the last "good" checkout you had on 15th July, and also double-check that the bug definitely doesn't occur then? (git reflog may help here). I can then have a look through the changelog to see if I can spot anything relevant to help narrow it down.

[raidenii]

As a starting point, can you provide the git hash of the last "good" checkout you had on 15th July, and also double-check that the bug definitely doesn't occur then? (git reflog may help here). I can then have a look through the changelog to see if I can spot anything relevant to help narrow it down.

It's 6b92bbfe812746fe7841a24c24e6460f5359ce72. I'm now starting to walk back from 36a24df to see which commit creates the problem.

[mcayland]

As a starting point, can you provide the git hash of the last "good" checkout you had on 15th July, and also double-check that the bug definitely doesn't occur then? (git reflog may help here). I can then have a look through the changelog to see if I can spot anything relevant to help narrow it down.

It's 6b92bbfe812746fe7841a24c24e6460f5359ce72. I'm now starting to walk back from 36a24df to see which commit creates the problem.

Thanks for the info! BTW if you use "git bisect" it will reduce the number of bisections to 2 to the power N (i.e 256 commits becomes just 8 bisections) so I would highly recommend doing it that way, i.e.

git checkout master
git bisect start
git bisect bad
git checkout 6b92bbfe812746fe7841a24c24e6460f5359ce72
git bisect good

and then follow the prompts. I don't think I've done a complete install since then, so I will try again either later today/tomorrow.

[raidenii]

As a starting point, can you provide the git hash of the last "good" checkout you had on 15th July, and also double-check that the bug definitely doesn't occur then? (git reflog may help here). I can then have a look through the changelog to see if I can spot anything relevant to help narrow it down.

It's 6b92bbfe812746fe7841a24c24e6460f5359ce72. I'm now starting to walk back from 36a24df to see which commit creates the problem.

Thanks for the info! BTW if you use "git bisect" it will reduce the number of bisections to 2 to the power N (i.e 256 commits becomes just 8 bisections) so I would highly recommend doing it that way, i.e.

git checkout master
git bisect start
git bisect bad
git checkout 6b92bbfe812746fe7841a24c24e6460f5359ce72
git bisect good

and then follow the prompts. I don't think I've done a complete install since then, so I will try again either later today/tomorrow.

It is quite weird that when I checkout old commits (including 6b92bbf), none of them can even pass the NVRAM error message stage. I re-cloned the latest version on ppc-for-2.7 branch and Mac OS 9.2.1 installs fine now (as of commit 05b3947).

Also, did anyone notice the reboot problem? When clicking "Restart" from Mac OS 9 menu, the OS shuts down properly (or at least it seems, screen goes black) but never reboot to OpenBIOS again. Manually closing QEMU and re-launching is required.

PS: When booting from hard drive (9.2.1 installed from CD and 9.2.2 patch applied before reboot), Mac OS throws an system extension error.

[mcayland]

It is quite weird that when I checkout old commits (including 6b92bbf), none of them can even pass the NVRAM error message stage. I re-cloned the latest version on ppc-for-2.7 branch and Mac OS 9.2.1 installs fine now (as of commit 05b3947).

Also, did anyone notice the reboot problem? When clicking "Restart" from Mac OS 9 menu, the OS shuts down properly (or at least it seems, screen goes black) but never reboot to OpenBIOS again. Manually closing QEMU and re-launching is required.

Yeah, this was broken by a commit in trunk which was subsequently fixed by Ben H. BTW all patches are now upstream in git master (a3b343772114c8c98986508f3352a631164f913c), so can you test against that? Even better I managed to fix the OpenBIOS regression, so QEMU 2.7 and git master will be able to boot MacOS 9 out of the box

[Arths]

Compiled latest master build from QEMU repo and 9.2.2 boots fine from HDD qcow2 image

[mcayland]

PS: When booting from hard drive (9.2.1 installed from CD and 9.2.2 patch applied before reboot), Mac OS throws an system extension error.

That looks like exactly the same error I used to see before the macio DMA invalidation bugfix - I wonder if this is some kind of disk corruption? Are you able to test on MacOS/Linux VM at all for side-by-side comparison?

[raidenii]

PS: When booting from hard drive (9.2.1 installed from CD and 9.2.2 patch applied before reboot), Mac OS throws an system extension error.

That looks like exactly the same error I used to see before the macio DMA invalidation bugfix - I wonder if this is some kind of disk corruption? Are you able to test on MacOS/Linux VM at all for side-by-side comparison?

Used the latest source from qemu vanilla and Mac OS 9.2.2 upgrade stuck. I complied Linux version, however under VNC the mouse is uncontrollable (the acceleration is too high)

[mcayland]

Used the latest source from qemu vanilla and Mac OS 9.2.2 upgrade stuck. I complied Linux version, however under VNC the mouse is uncontrollable (the acceleration is too high)

On the Linux VM, run a full vncserver and then use the GTK interface inside that because it has mouse capture.

I've just pulled git master and installed both OS 9.2.1 and OS 9.2.2 here without any errors (Debian Linux), so more information is needed to work out what is happening

[mcayland]

Heads-up for those who missed it: dgibson branch and my OpenBIOS fixes have been merged into QEMU git master

This means vanilla git master (and QEMU 2.7) will boot OS 9 out-of-the-box with no custom OpenBIOS required anymore :D

[Cat_7]

Yes,

That's worth a celebration
And congratulations to all who put in that hard work.

Best,
Cat_7

[kataetheweirdo]

That is encouraging news, indeed. I do notice that raidenii's screenshot shows that 9.2 isn't crashing on OpenTransport during boot-up (or so it seems), but on the PC Exchange control panel. Once the mouse control is fixed for Windows systems, I'd like to extensively test 9.2 out for QEMU.

[raidenii]

That is encouraging news, indeed. I do notice that raidenii's screenshot shows that 9.2 isn't crashing on OpenTransport during boot-up (or so it seems), but on the PC Exchange control panel. Once the mouse control is fixed for Windows systems, I'd like to extensively test 9.2 out for QEMU.

I never had problems with mouse on Windows, just some random crashes on IO operations.
Not sure if compiling under Fedora causes any problem (or mingw32?)

[kikyoulinux]

Another issue... After running a few minutes, icons on the desktop disappear and the system hangs except the mouse pointer. The mouse pointer still moves but does not click... Keyboard does not work too.




It happens both on Ubuntu and Windows build.

current startup argument:
F:\QEMU>qemu-system-ppc -sdl -M mac99 -m 384 -cpu G3 -usb -device usb-kbd -device usb-mouse -device usb-audio -net nic,model=rtl8139 -net user -hda os92en.img -cdrom "F:\BetaArchive\Apple Mac OS 9.2.2 [English] (CD)\Apple MacOS 9.2.2.iso" -boot d

[Cat_7]

Hi,

I have the impression these hang-ups are caused by the usb audio device.

Best,
Cat_7

[mcayland]

That is encouraging news, indeed. I do notice that raidenii's screenshot shows that 9.2 isn't crashing on OpenTransport during boot-up (or so it seems), but on the PC Exchange control panel. Once the mouse control is fixed for Windows systems, I'd like to extensively test 9.2 out for QEMU.

Just wanting to add here: raidenii mentions that he doesn't see the mouse problem at http://www.emaculation.com/forum/viewto ... 700#p53307 so which build are you using? Perhaps it is something specific to Stefan's binaries?

Also I should point out that the GTK frontend has been the default for a while, and as a result the SDL code isn't being exercised as much anymore. I wonder if what you see with the mouse is related to a bug in SDL? I would highly recommend using the GTK interface for no other reason that it does mouse capture which means the problem with local/remote mouse cursors getting out of sync disappears.

If it turns out to be a bug then you need to file a bug on the QEMU bugtracker hosted at launchpad with as much detail as possible: https://bugs.launchpad.net/qemu

[mcayland]

current startup argument:
F:\QEMU>qemu-system-ppc -sdl -M mac99 -m 384 -cpu G3 -usb -device usb-kbd -device usb-mouse -device usb-audio -net nic,model=rtl8139 -net user -hda os92en.img -cdrom "F:\BetaArchive\Apple Mac OS 9.2.2 [English] (CD)\Apple MacOS 9.2.2.iso" -boot d

To add here: with the latest builds there is no need to override the default CPU with -cpu G3 - as per my earlier post that was a red herring due to the TLB corruption. Overriding the machine default with a custom CPU option and other hardware to create a non-standard machine is likely to cause issues. Before experimenting with custom options try and use the defaults first:

qemu-system-ppc -M mac99 -m 384 -net nic,model=rtl8139 -net user -hda os92en.img -cdrom "F:\BetaArchive\Apple Mac OS 9.2.2 [English] (CD)\Apple MacOS 9.2.2.iso" -boot d

[celebi23]

So, I tried installing Mac OS X Public Beta just to see how far I could get it to go. I used the latest build of Qemu from this topic & installed 9.2.2. I changed the date to before the beta expired. Tried running the installer the normal way & got this error message:


So, I tried booting from the disc by changing the qemu.command file:

./qemu-system-ppc -bios ./openbios-ppc -boot d -M mac99 -m 1024 -cpu G4 -prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -g 640x480x32 -netdev user,id=network0 -device rtl8139,netdev=network0 -drive file=./Discs/MacOSXPublicBeta.iso,format=raw,media=cdrom -drive file=./MacintoshHD.dmg,format=raw,media=disk

This is what I got in the output of Verbose mode (resized the window for this shot so all the output could be seen at once):

The "Still waiting for root device" message kept on repeating over & over.

When I disabled the verbose mode boot option, here's what that looked like:


The broken folder icon wasn't there automatically. It showed up after 30 seconds or so. Not sure if any of this helps at all but, I had some time to kill and figured I'd give it a shot anyways.

[Arths]

Public Beta is picky when it comes to hardware, so I think it will be difficult to make it run on QEMU unless people implement real compatible hardware.

OS X 10.0 boots a little bit further though..
But it initiates an automatic-reboot so I guess something is wrong

[Programmingkid]

Mac OS 9.0.4 running in QEMU with Graphing Calculator in the background





The mouse does act erratically under the cocoa interface, so it looks like this is an emulated hardware problem rather than a front-end problem. This is under QEMU commit 206d0c24361a083fbdcb2cc86fb75dc8b7f251a2.

Has anyone been able to make anything old than Mac OS 9.0.4 run in QEMU? I hope it isn't too early to talk about Mac OS 8.

[kikyoulinux]

OS 9.0.0 will crash the emulator. But Mac OS 9.0.4 Trad.Chinese (Power Mac G4 Cube restore CD) works.