Mac on Linux

Mac on Linux is a software package for Linux running on a PowerPC processor. It will allow you to run MacOS in a virtual machine.

It is similar in concept to VMWare GSX, where the disk images are stored in the host’s file system but the guest VM screen is not tied to the host’s screen.

Hardware

I’m running it on an old Power Computing PowerCurve Mac clone. It has been upgraded to a 225MHz PPC 604 CPU and 128MB ram.

Software

Submitted by amillar on Sun, 2004-02-01 21:01

Bad X Server

I have an old laptop being used as an LTSP X Terminal. I have found that the X server software for this laptop is buggy. Somehow Mozilla exposes a bug that locks up the terminal.

Here is what I sent to the LTSP mailing list:

I have ltsp_core-3.0.7-0, ltsp_kernel-3.0.5-0, ltsp_x_core-3.0.4-0, and ltsp_x336_svga-3.0.0-0 on RedHat 8.0 I have one laptop running as an LTSP terminal using the ltsp-wireless package. It is a Toshiba Satellite 110CT with a Chips&Technology 65548 video chip and 24MB RAM. It uses the “chips” driver in XFree86 v4 and the SVGA driver in XFree86 v3. The X server seems to be buggy for this machine. If I display a page in Mozilla containing PNG images, such as http://www.bolis.com/amillar/pg/rdamh/radio-amateur-handbook.html the X server will chew up all its memory and in about 30 seconds, lock up the terminal. Ctrl-Alt-Bksp won’t kill it. The hardware has to be reset. This is in a standard LTSP setup with Mozilla running on the server; no local apps running on the terminal. It seems some X operation initiated by Mozilla is enough to trigger this problem. By putting the terminal in run level 3 and starting X on another VT, I could verify that the memory is being consumed like there is a memory leak. I tried adding swap space, first by NFS swap and then by local IDE swap. It still eats up the memory including the swap space; it just takes longer (60 seconds) to freeze up. This only happens on this one terminal; my other terminals can view the same things without any problems like this. I tried an experiment with the “Xnest” program, creating a new X server window and displaying Mozilla in it. In this situation, the problem does not occur! This reinforces my suspicion that there is a bug in the Chips X Server and Xnest is masking it through its virtualization of the display. Unfortunately Xnest isn’t a good solution because it is not resizable, needs a second window manager, and has some keyboard quirks. I tried copying Xnest from my server as a local app, but it wouldn’t run on the terminal because it complained about incompatible GLIBC versions. Even if that did work, I’m not sure if I could get it to initiate the XDMCP request. Replacing it with another laptop using a different X server is obvious, but I’m trying to make do with what I have. My next thought is to run vncviewer as a terminal local app connecting to an xinetd-launched vncserver, but that sounds like a nasty hack I’d rather avoid. Any thoughts or advice? Thanks

Unfortunately nobody had a solution.

What I did to solve it was to run vncviewer locally on the terminal, and set up vncserver on the terminal server to launch from xinetd. So the terminal is really only running vncviewer in full-screen mode, and the X server is really the vncserver running on the LTSP server machine. This solved it.

Submitted by amillar on Sun, 2004-02-01 21:01