Classic app hangs under Qemu 4.1, but not 4.0

[McHargue]

"And now for something completely different..."

Maybe not that different for those that have been around the emulation world for awhile. I don't seriously think anyone will be able to address my problem directly, but if there are tricks you might suggest to help be zero in on a possible cause I would appreciate any advice.

"Deep Emulation" is what I would call my use of all this (wonderful) software tech with Qemu and VMware. Ever see the movie "Inception"? I'm sure my Mac is experiencing something like the plot hook of that movie.

Background:

My setup is a very well equipped Mac with 8 cores, 32 GB RAM, and an SSD running macOS 10.14.6 Mojave.

My production environment is a VMware Fusion guest machine that serves as my primary "virtual host machine" relative to the suite of Qemu emulated machines that run under it. This virtual host is to provide a semi-future-proof environment that is also easily portable. It is also running macOS 10.14.6 and intended to be able to run that version of the OS well into the future even with the physical machine possibly migrating though several future macOS versions (10.15, 10.16, etc.).

Under this virtual host are 4 Qemu instances, each running Mac OS X 10.4.11 and the Classic 9.2.2 environment. They each run a variety of applications--some OS X, some OS 9--and I am to tie them together via a Tap network "backbone" that will also provide a bridge to the virtual host machine and thus to the physical machine running VMware. This network configuration is under development--film at 11.

The Problem:

Finally, my problem has surfaced within one of these Qemu machines that is running FileMaker Server 5.0v2 under the Classic environment. With my install of Qemu 4.0, FileMaker Server runs fine. However, I just tested the new Qemu 4.1 and once that (emulated) machine finishes launching its Classic environment then it appears that FileMaker Server soon hangs.

Being a Classic application this essentially hangs the Mac OS 9 Classic machine and regaining control of the parent OS X 10.4.11 is also problematic so I need to force quit the Qemu instance even though it is still reported as responding. Qemu 4.1 does not seem to have hung itself in that the instance is not reported as "not responding" and I can see it (and "sample" it) within Activity Monitor running on the virtual host machine that the 4 Qemu instances are running under.

So, after that long winded explanation, my question is simple(?): What are my options for sleuthing why this Classic app under an emulated Classic OS under an emulated OS X 10.4 running under (one of four instances of) Qemu running under macOS 10.14 running under VMware on a Mac running 10.14? Will taking a "sample" with Activity Monitor of the still-running Qemu process illuminate anything (assuming one knows how to read such samples)?

The dependency put hierarchically is:

Mac 8-Core Physical Machine
macOS 10.14
VMware Fusion
macOS 10.14
Qemu 4.1 (total of 4 instances) <-- continues to respond within Activity Monitor)
Mac OS X 10.4
Mac OS Classic 9.2.2
FileMaker Server 5.0v2 <-- appears to have hung along with Classic

(You can stop laughing now...)

Are there diagnostic switches for Qemu to make what it is doing more verbose in a way that might help?

Any other Mac OS X / Classic tools for tracing the hang?

Finally, is there a rundown on what things were changed in the Qemu 4.1 compared to 4.0 that might give me a clue as to something FileMaker within Classic might be depended on?

Thanks for reading, hope you found my application of this entertaining.

Bill.

[UbuntuXP]

Can you try a test with a minimal number of emulation layers and see if it works? Specifically, try:

Mac 8-Core Physical Machine
macOS 10.14
Qemu 4.1
Mac OS X 10.4
Mac OS Classic 9.2.2
FileMaker Server 5.0v2

[Cat_7]

Hi,

Where to begin diagnosing that problem?
Qemu can be invoked with a number of debugging options, however, the value of them also depends on whether debugging was enabled during the build of the program. If you are running my 4.1 build, debugging is not enabled as it would slow down Qemu. Also, the 4.1 build was built on a newer version of MacOS compared to the 4.0 version. I have no means to verify the accuracy of these builds at all, we all just hope they work

Adding -serial stdio and -d guest_errors to your command line will give you some feedback and the option to compare what might be different between 4.0 and 4.1. But I doubt it will catch the hangup in Classic.

To simplify things, do you have the option to run your Filemaker server in Mac OS 9 in Qemu directly (e.g. not inside classic, not inside VMWare)?
There is a debugger for Mac OS 9, called macsbug. I have no experience whether it can be installed/used in classic under 10.4.11. Not do I have any real experience in invoking it and understanding its output.

Can you give us the command line you use to start the Qemu instance that shows the problem?
Did you check the sleep/screen saver settings in 10.4.11/Classic?

I also see there is a filemaker server event log available. Does it mention anything suspicious?

A list of changes between versions 4.0 and 4.1 is available on the Qemu wiki, but it might not give clues to deeper code changes.

Not much help here...

Best,
Cat_7

[McHargue]

Can you try a test with a minimal number of emulation layers and see if it works? Specifically, try:

Mac 8-Core Physical Machine
macOS 10.14
Qemu 4.1
Mac OS X 10.4
Mac OS Classic 9.2.2
FileMaker Server 5.0v2

If I try a pure Mac OS 9 emulation and it doesn't fail, then I can work myself back up into layers of emulation as above. Good suggestion, thanks.

Hi,
Where to begin diagnosing that problem?
. . .
Not much help here...

Best,
Cat_7

More help than I could expect given the nature and depth of the emulation. Several good ideas, and I'll tackle them as suggested.

The good news is that 4.0 _does_ work, and what I am trying to do is to gain confidence that future Qemus will not break things. But in reality the whole strategy is to encapsulate the production environment in the top virtual host environment which needn't ever change—assuming VMware, or a successor, will run it for the lifetime of the production system.

Thank you,

Bill.

[McHargue]

Hi,
Can you give us the command line you use to start the Qemu instance that shows the problem?
Cat_7

Note that I am NOT a well versed Qemu jockey and do a great deal of copy/pasting as well as trial and error configuring.

I have a lot to do in learning and deploying a Tap interface, too. But here is the specific command file for the Qemu instance in question. Independent of the 4.1 problem at hand, I am always open to advice in Qemu configurations--the plethora of options is daunting for the newbie.

BTW: I discovered the "-device usb-tablet" option but there are still issues with mouse tracking when emulating/virtualizing through so many layers. Sometimes it loses its way in the world.

Here you go:


#!/bin/bash
cd "$(dirname "$0")"

nohup ./SAMOA_Image_Database_System_PPC -L pc-bios -boot c -M mac99,via=pmu -m 1024 \
-prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -prom-env 'vga-ndrv?=true' \
-drive file=SAMOA_Image_Database_HD.img,format=raw,media=disk \
-netdev user,id=network01,hostfwd=tcp::5003-:5003 -device sungem,netdev=network01,mac=52:54:00:12:34:01 \
-device VGA,edid=on \
-device usb-tablet \
> QEMU_Logs/SAMOA_Image_Database_System_PPC.out.log 2> QEMU_Logs/SAMOA_Image_Database_System_PPC.error.log < /dev/null &
exit;
osascript -e 'tell application "Terminal" to quit'

[Cat_7]

Hi,

I don't see anything wrong with that command line.
You can prune it a bit, however. This whole line can be deleted:
-prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -prom-env 'vga-ndrv?=true' \
Auto-boot and vga-ndrv are true by default, and -v only lets you see what's happening behind the apple start-up screen.

You might only use the usb tablet device with OSX guests, OS 9.x do not have a driver for it. There is an experimental driver available on the forum for Mac OS 9.2 only, but it is not without its own problems. Mind that using mac99,via=pmu by default present usb-keyboard and usb-mouse to the guest, so you are adding a third usb device. At least Mac OS 9.0 has problems with more than one device, not sure whether 9.1/9.2 have problems with more than two. I'm also not sure how classic reacts to that.

Tap networking would introduce yet another dependency in your already complex setup: there is no official driver for OSX hosts, the required tuntaposx software was created some time ago and doesn't seem to get updated regularly. Without fiddling with permissions to the tap devices you would also need to run your Qemu instances with root privileges to enable them.

The good news is that 4.0 _does_ work, and what I am trying to do is to gain confidence that future Qemus will not break things.

If this is a Qemu problem, it should be addressed by the Qemu developers.

You didn't tell us whether you are building your own Qemu, or are using our build. The build I provide depends on the libraries from brew in the Libs folder and some libraries available by default on OSX hosts. Also, when you use -net user, Qemu uses the Slirp network stack. I've seen some patches to Slirp on the developer mailing list, so it might be there are fixes for some issues (now assuming the problem is network related, which we don't know).

There is also a Qemu stable code release which would be more suitable for production environments. By default development is done in the master code branch so when building from that, Qemu could still show some issues despite all testing. So, upgrading to 4.1 might not be the best idea if you need a stable environment.

Having said that, I might be able to provide you with a build from recent source built on 10.14. But that would be an escape to the future

Best,
Cat_7

[McHargue]

Hi,
You can prune it a bit, however. This whole line can be deleted:
-prom-env 'auto-boot?=true' -prom-env 'boot-args=-v' -prom-env 'vga-ndrv?=true' \

Done. Thanks.

You might only use the usb tablet device with OSX guests, OS 9.x do not have a driver for it.

My only use for "tablet" was to coerce a one-to-one cursor ratio for tracking between the host and emulated OS. It works most of the time, but not always and when it loses it, it really goes bonkers. Since it loses it even when manipulating the emulated OSX guest independent of the Classic OS I am going to guess the problem is not in a missing OS 9 driver.

You didn't tell us whether you are building your own Qemu, or are using our build. The build I provide depends on the libraries from brew in the Libs folder and some libraries available by default on OSX hosts. Also, when you use -net user, Qemu uses the Slirp network stack.

I am using your build. I've resigned myself to stick with the 4.0 release and not resolve this 4.1 issue yet. My plate is too full, and getting tap networking up and running is my current roadblock. Since it is tangential to this thread's subject I will post a tun tap question to a new thread. Spoiler: "warning: netdev network0 has no peer".

(P.s. Sorry I didn't reply/thank you sooner--I didn't get a notification and was sidetracked on another project. So, thank you!)

Bill.