bug: macOS locks up running Quickemu on AMD Ryzen 4000 or 5000 series mobile CPUs?

[markaltmaier]

It always stuck, and restart, I don't know why?

[lj3954]

Please try the latest version of quickemu from git. macOS CPU flags have been changed considerably since v4.9.4 was released.

[markaltmaier]

I'm using the latest version

https://github.com/quickemu-project/quickemu/releases/tag/4.9.4

I used this one

Is this the latest version?

It installs mojve os correctly, however ventura and somoma don't work.

[lj3954]

I'm using the latest version

https://github.com/quickemu-project/quickemu/releases/tag/4.9.4

I used this one

Is this the latest version?

It installs mojve os correctly, however ventura and somoma don't work.

That is the latest tagged release, but it does not contain the latest changes. While v4.9.5 is not released, please clone the repository and try using the quickemu script directly from it.

[markaltmaier]

The same problem happened, I used this repo

git clone --recurse-submodules https://github.com/quickemu-project/quickemu.git

and then used this command

./quickemu --version >> 4.9.5

./quickget macos ventura
./quickemu --vm macos-ventura.conf

first the instance restarted then when I entered (macOS Base System) it became stuck again.

I don't know if this a problem with amd cpu or what?

[tomchiverton]

Mac OS Sonoma boots to a black screen here, post installer, having picked the installer once after reboot. This is using quickget/quickemu from Git this morning.

I think something is badly wrong, but the log file is empty.

[markaltmaier]

Same here. The log file is empty, and the boot screen is stuck. It won't load the installer.

Tested on ventura and sonima both didn't work, testing it now on monetary to see if this is related to ventura and Sonoma only

[lj3954]

@TuxVinyards More needs to be looked into regarding the CPU flag. I think I found something that may be of high importance. I'm not sure what the case is on Intel platforms, but on my AMD system, invtsc, which is a flag that OSX-KVM included in the penryn argument, is reported as constant_tsc instead. Quickemu bash does not catch it.

For the people here experiencing these issues, I'd recommend trying to launch your VM with my project, quickemu-rs. It makes use of a library which interacts directly with the CPU, so it shouldn't have any problems with inaccurate parsing of supported CPU flags. That would help us understand where the issue lies.

[TuxVinyards]

@lj3954 I did say that the formula was wrong. I rewrote it and showed you the improvements.

But all I got was a flea in my from @flexiondotorg for "self promotion" of qqX.

Meanwhile, you have become 'The anointed one' and have decided to self promote your ideas 😂

If I had stuck with your ideas, we would all still be working with failure. All you have ever done is moan and complain and say nothing should be changed from what we had back in 4.9.2.

It's all getting very tedious.

At least my formula works for me and none of the qqX users are lamenting to me either ....

[lj3954]

@lj3954 I did say that the formula was wrong. I rewrote it and showed you the improvements.

But all I got was a flea in my from @flexiondotorg for "self promotion" of qqX.

Meanwhile, you have become 'The anointed one' and have decided to self promote your ideas 😂

If I had stuck with your ideas, we would all still be working with failure. All you have ever done is moan and complain and say nothing should be changed from what we had back in 4.9.2.

It's all getting very tedious.

At least my formula works for me and none of the qqX users are lamenting to me either ....

Rather than addressing what I brought up, you choose to attack me for "promoting my ideas" by recommending testing with a project which should theoretically function in exactly the same way, to see where the issue lies. It's quite strange how you always complain about how unwilling I am to work with others, when virtually none of your work is contributed upstream. Contrast that with my continuation to fixing and improving bash quickemu, despite writing a project intended to supersede it.

I made it very clear that my position was that no changes should be made unless it was clearly shown that the old approach had issues, and that said issues could be fixed. I don't believe you, me, or anyone else in those discussions had real, tangible issues with the original argument. You preferred to instead talk about pointless things such as how the penryn architecture is "old" and doesn't "officially" support said amount of cores. Those who did are coming to report that one solution, apparently not the one you prefer the most, is also causing issues. Why don't you propose a fix, if you have this magical solution that everyone needs. Unlike you, I'm not recommending my project as a permanent solution for everyone to switch to and completely disregarding everything else, rather, just a step in troubleshooting an issue here.

[TuxVinyards]

I think I found something that may be of high importance. I'm not sure what the case is on Intel platforms, but on my AMD system, invtsc ....

I have already mentioned similar here 3 weeks ago.

I made it very clear that my position was that no changes should be made ...

Yes, you did. Continually.

.... unless it was clearly shown that the old approach had issues

Yes. I did show you. But you kept ignoring me.

Why don't you propose a fix, if you have this magical solution that everyone needs.

Not saying it's 'magical' but I did propose one and that got ignored too: #1114 (comment)

I then proposed a fix on another issue here and got the flea in my ear that I mentioned.

So, I gave up

and put my work here so people can choose for themselves:

You always have to have areas where you agree to disagree and find option solutions for different ideas.

But

I can't have entirely given up, otherwise I wouldn't be taking the time to reply, I suppose?

Even after @zen0bit following his myriad of contributions seems to have walked away completely:

I would like to think that it is just hurried people who are not understanding or who are misunderstanding. People who are possibly pressured making snap decisions and comments that they possibly regret but hope people understand as such. And so forth.

I would like to think something might be done about issue #1113 too. Closed as 'completed' but never fully addressed.

And

This Quickemu branch here has the new qqX cpu formula which should be able to run as plain Quickemu without the need to install qqX , if you want to.

[markaltmaier]

so you still working on the problem guys, or it was solved?

[lj3954]

@Mustafa-Agha please try quickemu from https://github.com/TuxVinyards/quickemu/tree/freespirit-dev-tweaks and report back whether it fixes the issue.

[lj3954]

@TuxVinyards the comments you made in qqxproject@174232c aren't clear. Are 8 cores required for the VM to boot, or just for macOS to display a processor name?

[TuxVinyards]

@lj3954

The comments you made in TuxVinyards@174232c aren't clear. Are 8 cores required for the VM to boot, or just for macOS to display a processor name?

Presume this comment in the code:

Tests suggest edit of .conf file to cpu_cores="8" ie 4 core x 2 threads for MacOS to recognise Xeon

My guess is that if MacOS recognises the iMacPro 2017 when it is set at ="8" then things under-the-hood will generally be happier.

https://en.wikipedia.org/wiki/IMac_Pro#Technical_specifications

The OS will boot and run when set at ten or more. Please feel to experiment but as stated in my qqX wiki do backup copy the whole of Mac OS folders before starting. Lots of ancillary files can get changed during processes.

I think the way forward for more powerful setups will be to use Cascade Lake. I want to have a look at that.

A lot of people, me included, are getting tempted by the new Zen 5 processors. When I bought my current main processor, I was lucky to even get that. Chips were really hard to get hold of, certainly here in Europe. Now we are in the era of desktop CPU's with 16 cores, huge government support for new fabs and 2, 3 and 4 nm becoming common place.

Cascade Lake, the Mac Pro 2019, can be set to have up to 28 cores, so I am seeing something like --macpro-2019 as a Quickemu switch that would allow users with newer hardware to enable this instead of a default of iMac Pro 2017. Although, as with Skylake, a lower core number may be needed here too, say 16 ??

https://en.wikipedia.org/wiki/Mac_Pro#Specifications_3

The other thing I want to do is to have a config setting that allows individuals to turn off any Qemu CPU flags when an unexpected compatibility problem happens with the physical hardware. Something in the .conf file like MacCPU_NoFlags=("pqr" "xy-z")