search

utmapp / UTM

Virtual machines for iOS and macOS
https://getutm.app
Apache License 2.0
26.62k stars 1.33k forks source link

Starting with UTM 3.1.0, Mac OS 9.0.4 no longer boots #3670

Open adespoton opened 2 years ago

adespoton commented 2 years ago

Describe the issue For UTM 2.x through 3.0.4, creating a mac99, via=cuda guest and booting a G4 Cube install CD resulted in the ability to create a usable Mac OS 9.0.4 OS. Starting with UTM 3.1.0, after the initial OpenBIOS boot screen, all operation halts where it would previously display the ? disk followed by the happy mac. Using regular qemu-system-ppc continues to function properly with the same disk image.

Configuration

STDOUT log UTM-904-stdout.log

Debug log debug.log

Upload VM Mac OS 9.0.4.utm.zip

osy commented 2 years ago

I see this in your config

        <key>AddArgs</key>
        <array>
            <string></string>
            <string></string>
            <string></string>
            <string></string>
        </array>

Is this intentional?

osy commented 2 years ago

Either way it's weird because the only change from 3.0 to 3.1 is the user argument parser which skips 0 length arguments anyways...

adespoton commented 2 years ago

Definitely odd, but reproducible. Those empty strings are holdovers from when I was trying to get mouse handling to work in the 2.x releases; UTM doesn't appear to clean up empty strings or allow you to delete an argument once it's been created, and I haven't bothered cleaning up the tags themselves.

The reported error seems to be something to do with SPICE, as the same QEMU without SPICE runs it just fine, and QEMU had no changes between 3.0 and 3.1. The change happened at the same time that I started getting a usable mouse/keyboard in CUDA guests and a usable mouse/keyboard in macOS 11 x86-64. But it happens right after QEMU hands off video handling from the OpenBIOS loader, before the Mac OS initialization happens.

Did anything change in the SPICE codebase around pointer handling?

osy commented 2 years ago

But SPICE issues shouldn't result in anything on the guest VM. That's all handled in QEMU.

I tried 9.2.1 from the gallery https://mac.getutm.app/gallery/mac-os-9-2-1 and it still works fine. Can you confirm that on your end? @adespoton

adespoton commented 2 years ago

I can confirm; 9.1 and up, including 9.2.1 uses PMU. Only 9.0.4 uses CUDA. But the issue isn’t with CUDA because that’s used by 10.0 and 10.1 as well, and they work just fine.

The problem seems to happen when attempting to switch from the text-based interface of the OpenBIOS screen to the VGA-based interface of the OS 9 boot screen. If I define a screen resolution in the config, the screen switches from the yellow OpenBIOS screen at that resolution to a black screen at the default resolution. If I use default resolution, the boot sits on the yellow OpenBIOS screen at the point where it would normally switch to VGA.

Using UTM 3.0.4, there are no issues; VGA screen comes up as expected and the VM boots to the Finder. But of course under 3.0.4 there’s the issue with CUDA ADB mouse and keyboard being overridden by SPICE, so 9.0.4 can’t do anything once booted.

None of this is an issue in vanilla qemu-system-ppc (CUDA/ADB issues were sorted out back in QEMU 2.X).

On Feb 24, 2022, at 9:12 PM, osy @.***> wrote:

 But SPICE issues shouldn't result in anything on the guest VM. That's all handled in QEMU.

I tried 9.2.1 from the gallery https://mac.getutm.app/gallery/mac-os-9-2-1 and it still works fine. Can you confirm that on your end? @adespoton

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

adespoton commented 2 years ago

Might be related (not something that's changed, but maybe SPICE interacts differently now?), but UTM config passes both -vga none and -device vga. https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/#tldr indicates that -device vga is just another way of saying -vga std. So maybe something in the regex parameter parsing change has resulted in -vga none trumping -device vga instead of the other way around?

Also interesting from that page is that the recommended default device is -device virtio-vga as it handles hardware acceleration if the drivers are available and falls back to vga if they aren't. But UTM doesn't appear to have virtio-vga compiled in.

Also, using console-only instead of Full Graphics appears to go to the exact same position in emulation, which suggests the issue is indeed at the point where the VGA instance is being brought up.

Adding secondary VGA devices just skip the console altogether.

So I'm still at a total loss as to what change could have created the issue, but it's an issue that won't go away, no matter whether I attempt to boot a functional installed 9.0.4 image, or boot from a functional install CD. The issue is unique to UTM 3.1.0 and 3.1.1 and doesn't exist in any other build of UTM or of QEMU without SPICE.

osy commented 2 years ago

Can you send me a complete image to work with? You can DM me on discord or email or twitter (see bottom of getutm.app)

adespoton commented 2 years ago

Will do. Interestingly, I finally got a successful boot after turning off everything I possibly could. So before I send you a complete image, I want to track down which of the things I disabled allowed for a boot.

adespoton commented 2 years ago

OK: this is odd: after disabling sound and networking and Legacy input, it booted. Re-enabling sound and networking, it still booted. Enabling legacy mode, it didn't boot.

But the first thing I originally tried when it stopped booting after the update was disabling legacy input mode.

Now though, that single toggle changes the results. And oddly, even though it's CUDA and uses ADB, with legacy input disabled, it's functioning properly with the pointer, where it didn't in 3.0.4.

No idea what's going on here, but there appears to be some underlying issue and we're only seeing symptoms.

[edit] and I spoke too soon -- mouse is working, but keyboard isn't. Adding -usbdevice keyboard doesn't work because CUDA doesn't see the USB hub, having no concept of USB.

[edit2] Adding -device adb-keyboard doesn't appear to fix the keyboard issue either.

adespoton commented 2 years ago

Here's what the Apple System Profiler has to say. Interestingly, even though we're emulating CUDA, the initial USB activity was recognized and then rejected: image

Broken-904-ADB-USB-2

Since I have no keyboard, I can't copy the text out or do any of the other useful things to isolate the issue. This trace is probably more useful for Mark in tweaking qemu-system-ppc CUDA, but it does indicate that the default USB hub presented by UTM/SPICE appears to be stomping all over the legitimate I/O.

Also worth noting that in order for the mouse to work, I have to capture/release/capture. Next time I catch you online, I'll send you the image so you can play with it too.

osy commented 2 years ago

Can you try disabling USB forwarding by setting Sharing -> Maximum Shared USB devices to 0

adespoton commented 2 years ago

Adding this for future tracking, even though we already discussed out of band: There's no difference with shared USB devices at 0; keyboard remains unresponsive and USB 0 reports no devices found. USB log appears identical to the one I provided, with set address failing and ports flagged dead and disabled (3 of them).

osy commented 2 years ago

I tried your .utm and it gets stuck booting with the progress bar at 20%. Is this what you observe as well?

adespoton commented 2 years ago

No; at that point you have to click the mouse and the boot will resume. Assuming you’ve already captured the mouse so it will click.

After clicking, you should be able to boot right to the Finder; the mouse should work as long as it stays captured, but the keyboard will be unresponsive, because there's no link between the physical keyboard and the virtual ADB keyboard presented to the guest OS. I don't know why there's no link, because there IS a link for OS X 10.0 and 10.1 now.