ERROR: Not enough free memory.

[dewenhsu]

Run under Odroid N2, alwayse got ERROR: Not enough free memory. is it support 64bit OS or anything wrong ? Thank you.

[rickyzhang82]

Is it BII or Sheepshaver?

I could run BII in Odroid U2 and Xu4 in 32bit ARM.

[dewenhsu]

It is BII. I can run BII in Odroid XU4, but failed in N2.

[rickyzhang82]

I can build and run BII in amd64 Linux for quite long time without any issues.

In Linux, there are two possible places throwing the OOM error.

• Can you confirm which one by injecting different identification in the message?
• Please let me know which memory addressing do you use. You can get that when you run ./configure. See technical details I wrote.

585 #if REAL_ADDRESSING
 586     if (memory_mapped_from_zero) {
 587         RAMBaseHost = (uint8 *)0;
 588         ROMBaseHost = RAMBaseHost + RAMSize;
 589     }
 590     else
 591 #endif
 592     {
 593         uint8 *ram_rom_area = (uint8 *)vm_acquire_mac(RAMSize + 0x100000);
 594         if (ram_rom_area == VM_MAP_FAILED) {
 595             ErrorAlert(STR_NO_MEM_ERR);
 596             QuitEmulator();
 597         }
 598         RAMBaseHost = ram_rom_area;
 599         ROMBaseHost = RAMBaseHost + RAMSize;
 600     }

 602 #if USE_SCRATCHMEM_SUBTERFUGE
 603     // Allocate scratch memory
 604     ScratchMem = (uint8 *)vm_acquire_mac(SCRATCH_MEM_SIZE);
 605     if (ScratchMem == VM_MAP_FAILED) {
 606         ErrorAlert(STR_NO_MEM_ERR);
 607         QuitEmulator();
 608     }
 609     ScratchMem += SCRATCH_MEM_SIZE/2;   // ScratchMem points to middle of block
 610 #endif

I'm surprised that it is OOM in ARM64.

[dewenhsu]

I am sorry I am a linux rookie, I can only use The Retro Arena image for N2 which has build in Basilisk II : http://theretroarena.com/download/1065/ How can I "inject" the message and how to find it ? Thank you.

[rickyzhang82]

You need to install a build env to compile it in ARM64 or use cross compile tools in a beefy amd64 PC. If you are not a geek, you probably don't bother to go in this route. Never mind.

[dewenhsu]

I hope I can compile and test but I can't. Wish someday it can be run on Odroid N2. Thank you.

[macromorgan]

Getting this same error on ARM64 platform (Ubuntu 19.10 aarch64). On ARMHF (Raspbian Buster) it works just fine, though I had to build it from source I used the Debian package source since Raspbian had the source package but not the binary package.

Memory addressing appears to be direct in the default debuild setup (Addressing mode ......... : direct). SDL support is set to video/audio, Enable video on SEGV signals is yes, GTK user interface is gtk2, floating point emulation is IEEE fpu core, assembly optimisations is none, and bad memory access recovery type is siginfo. All other options are set to no.

I changed the first instance of STR_NO_MEM_ERR under REAL_ADDRESSING to STR_NOT_ENOUGH_MEMORY_ERR and the second instance under USE_SCRATCHMEM_SUBTERFUGE to STR_NO_RAM_AREA_ERR and got the following instead of the "ERROR: Not enough free memory" error: "ERROR: Your computer does not have enough memory to run Basilisk II.". So it looks like the error on line 595 from above is where the error is tripping on ARM64.

Thank you.

edit: same error when I compile with --enable-addressing=banks. As a "workaround" I guess I can go multilib and use the 32 bit version, since that seems to work for now on ARMHF.

[dewenhsu]

Test it on Debian GNU/Linux 10 Buster and got the same error.

[jacexpo]

I have experienced the same Not enough free memory issue up on startup as listed above on aarch64 Debian (buster). I have tried to compile with the three different memory settings recommended above, all fail the same way as previously documented.

[jduerstock]

Using strace to trace the system calls may help show where the error is occurring.

[jacexpo]

strace attached. Thank you for the quick response.

basilisk_strace,txt

[jduerstock]

This isn't my usual project, so I didn't realize the program does a fork()/clone(). Can you retry with strace -f please?

Thank you.

[jacexpo]

No problem at all! Here is hoping that it helps! basilisk_strace.txt

[jacexpo]

Was there anything else I can do to assist troubleshooting this?

[MarcDoughty]

I can confirm this bug on Ubuntu 19.04 on arm64.

I know this isn't going to be a popular stance, but while BII and SheepShaver are fantastic practical emulators, it seems like QEMU has a more solid base for moving forward. With Apple switching to arm64 hardware, would it make sense to focus effort on bringing what is awesome about BII and SheepShaver to QEMU's m68k-softmmu and ppc-softmmu targets?

It feels like the things that are wonky in QEMU are minor (poor mouse tracking, no audio device), while the things that are wonky in macemu are more deep-rooted (using low memory, portability issues, no MMU, etc.). Also, once devices and quirks for a few machine types are moved into QEMU, we inherit things like good upkeep on the platform as a whole, TCG, QCOW2 disk format, and inclusion in virtually every mainstream distro.

I'm not a developer, so I have no idea if what I'm saying is possible. I've just spent a week of my free time compiling BII, SheepShaver, and QEMU on multiple platforms to get solid PPC and m68k emulation running, and I feel like a little bit of effort getting a few practical things from macemu into QEMU would be a really good long-term investment for the Classic Mac emulation community.

I'm willing to put a little bit of money into this if anyone is interested, by shipping a few arm64 Raspberry Pis to people who can make it happen, and even put some (small) bounties on milestones reached on getting QEMU's q800 and mac99 machines up-to-par with what BII and SheepShaver do today.

[trapexit]

The downside to QEMU would certainly be performance but otherwise, for the long term health of emulation of said platforms, QEMU probably is the best bet. Bounties are probably not a bad idea (along with some advertising of such).

[MarcDoughty]

I think QEMU would definitely be a performance hit... but I also think a $35 Raspberry Pi can probably run a Classic Mac faster than the fastest 68k Mac ever could; I definitely remember happily running BII on a Pentium III back in the day.

On that front, the TCG feature in QEMU is JIT-like, and efforts to get PPC and 68k as optimized as possible as a TCG target mean that improvements to QEMU's TCG engine would benefit us.

I just tried compiling BII, SheepShaver, and QEMU on an arm64 Linux box, and it looks like BII and SheepShaver try to do some stuff with memory that isn't working on arm64, QEMU works great though (except that it can't -boot- a 68k Classic Mac quite yet, just PPC).

[rickyzhang82]

I spun up a aarch64 VM from ubuntu-20.04.1-live-server-arm64.iso in QEMU. The first issue I hit is that we have very old config.guess script.

./configure --enable-sdl-video --enable-sdl-audio --disable-vosf --disable-jit-compiler --with-x --with-gtk --with-mon --enable-addressing=direct

...

checking build system type... ./config.guess: unable to guess system type

This script, last modified 2003-01-10, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

    ftp://ftp.gnu.org/pub/gnu/config/

If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <config-patches@gnu.org> in order to provide the needed
information to handle your system.

config.guess timestamp = 2003-01-10

uname -m = aarch64
uname -r = 5.4.0-54-generic
uname -s = Linux
uname -v = #60-Ubuntu SMP Fri Nov 6 10:42:16 UTC 2020

/usr/bin/uname -p = aarch64
/bin/uname -X     = 

hostinfo               = 
/bin/universe          = 
/usr/bin/arch -k       = 
/bin/arch              = aarch64
/usr/bin/oslevel       = 
/usr/convex/getsysinfo = 

UNAME_MACHINE = aarch64
UNAME_RELEASE = 5.4.0-54-generic
UNAME_SYSTEM  = Linux
UNAME_VERSION = #60-Ubuntu SMP Fri Nov 6 10:42:16 UTC 2020
configure: error: cannot guess build type; you must specify one

[asvitkine]

I agree that it would be ideal to just improve qemu and benefit from its ongoing maintenance and mainstream adoption.

Though I don't have much to contribute on this front - since I'm not actively working on SS either.

On Sat., Nov. 28, 2020, 3:31 p.m. Ricky Zhang, notifications@github.com wrote:

I spun up a aarch64 VM from ubuntu-20.04.1-live-server-arm64.iso in QEMU. The first issue I hit is that we have very old config.guess script.

... checking build system type... ./config.guess: unable to guess system type

This script, last modified 2003-01-10, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from

ftp://ftp.gnu.org/pub/gnu/config/

If the version you run (./config.guess) is already up to date, please send the following data and any information you think might be pertinent to config-patches@gnu.org in order to provide the needed information to handle your system.

config.guess timestamp = 2003-01-10

uname -m = aarch64 uname -r = 5.4.0-54-generic uname -s = Linux uname -v = #60-Ubuntu SMP Fri Nov 6 10:42:16 UTC 2020

/usr/bin/uname -p = aarch64 /bin/uname -X =

hostinfo = /bin/universe = /usr/bin/arch -k = /bin/arch = aarch64 /usr/bin/oslevel = /usr/convex/getsysinfo =

UNAME_MACHINE = aarch64 UNAME_RELEASE = 5.4.0-54-generic UNAME_SYSTEM = Linux UNAME_VERSION = #60-Ubuntu SMP Fri Nov 6 10:42:16 UTC 2020 configure: error: cannot guess build type; you must specify one

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cebix/macemu/issues/188#issuecomment-735286987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEJ4CVT3O4JFX2TPBAH5TSSFMZ3ANCNFSM4IXMC7PQ .

[rickyzhang82]

Replacing config.guess and config.sub can make the configure works for aarch64.

wget 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD' -O config.guess
wget 'http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD' -O config.sub

I will do a test for Linux and Mac under x86 and then send a PR for this change.

[rickyzhang82]

I figured out a fix for AARCH64 architecture without an ugly hack like hard coding the MAP_BASE in another one's PR.

For AARCH64, mmap doesn't honor MAP_32_BIT. So we should force to use virtual addressing in configure when encounter architecture such as AARCH64 and bypass the sanity check.

@asvitkine

I don't like QEMU at all. It runs slow even under i9-9900K beefy desktop to emulate ARMV7 and AARCH64. In my previous project patching pfSense router, I have horrible experience to use QEMU to develop for ARMV7. I have to switch to cross compiling, instead. I'm not sure the performance of running M68k Mac OS. Maybe it is acceptable. But developing under QEMU for ARM just sucks.

[rickyzhang82]

I tested the fix in QEMU with Ubuntu 20.14 AARCH64.

See my PR #229

[jacexpo]

I am thrilled to report that after recompiling incorporating PR#229 on my AARCH64 - the BasiliskII emulator load successfully without errors and boots my image into macOS . Thank you very much RickyZhang82 - I also appreciate you updating config.guess - I had found an older 2017 version that worked - but you put in the latest one which was the correct fix. Thank you again.

[MarcDoughty]

@rickyzhang82 , I share your feelings about the usability and performance of QEMU, but... I still think that if QEMU m68k got a little bit of help so Mac OS Classic could boot and the mouse tracked properly, it would be the go-to platform for Classic Mac emulation.

I think BasiliskII and SheepShaver are awesome from a practical perspective, but there's a lot of things that could use work that are intrinsically handled elsewhere in the QEMU project.

I just spent a few hours trying to figure out why BasiliskII won't compile because of missing GTK and SDL libraries that are falling off the back of relevancy, while QEMU is quite current.

[rickyzhang82]

Anything is possible. But who is going to write that code in QEMU?

To me, migrating QEMU is a daunting task. You need to rewrite all emulated hardware of M68 Macintosh such as sound, NIC, display for QEMU. I have enough fun with adding black/white frame buffer for System 6 alone. I'm done with it.

If you think the build system in BII is sub par, you could come up with a better build solution. Eg, add better documentation, introduce a modern build system like CMake, and etc. But IMHO sub par build system is not a good reason to migrate to QEMU. Because the development cost of reinvent the wheel is high.

The benefit of migrating to QEMU may be that we could get a full blown 68K CPU emulation such as 68030 MMU (with this missing feature in BII, we could run A/UX for fun). But System 6 and System 7 are not a truly multi-task with memory protection OS. So why bother MMU?

I'm happy with what I have now in BII where I could run 68k abandonwares. Under modern CPU, the BII emulation performance is superb even without JIT.

I'd prefer to keep BII in life support mode.

[MarcDoughty]

I have a super soft spot in my heart for BII and SheepShaver. They're totally the best practical emulators for classic Mac fans.

I guess what I'm saying is that a huge amount of effort has been put into them to fix idiosyncrasies that I imagine the expertise of a BII veteran would be able to use to push QEMU's q800 target over the hill to viability.

If we're talking about emulation on modern hardware, even low-end stuff like the Raspberry Pi, I think we'd have decent-enough performance on QEMU's m68k target to exceed any actual m68k hardware.

Would you (or anyone else reading) be interested in a cash-sponsored effort to get things like Classic Mac OS boot, mouse tracking, and audio mainlined into QEMU? I'd be willing to put some of my own money and some hours of advocacy towars it, but I think we would need someone who was deeply familiar with BII to do the work.

[rickyzhang82]

No. I’m not interested in any cash related project. I do this for fun. Perhaps, you could find others for help.

I sincerely doubt your claim that QEMU has decent performance on m68k target. No one has ever tried running an actual m68k Macintosh game on QEMU. This is a known unknown.

Could you run emulated PPC Mac OS 9 on QEMU like SheepShaver? Are the graphics and sound OK?

I worked on development under emulated ARM64 QEMU. The emulation performance is sub par. I have never tried a desktop environment with graphics and sound in emulated QEMU.

[ianfixes]

If you think the build system in BII is sub par, you could come up with a better build solution. Eg, add better documentation, introduce a modern build system like CMake, and etc.

Is there a separate issue open to track this?

[jacexpo]

I am thrilled to report that after recompiling incorporating PR#229 on my AARCH64 - the BasiliskII emulator load successfully without errors and boots my image into macOS . Thank you very much RickyZhang82 - I also appreciate you updating config.guess - I had found an older 2017 version that worked - but you put in the latest one which was the correct fix. Thank you again.

I am sad to report that with Basilisk 2 version 1.1 - this fix no longer works correctly - and reverts to the previous "ERROR: Not enough free memory." rickyzhang82 - is there a way for you to check and see if there is something else you can assist with?