Re: OldWorld ROM Macintoshes

Installing "xserver-xorg-video-mach64" in Debian SID allows X11 to work 
on the Wallstreet. Unfortunately, I was not able to get the Wallstreet 
to boot into the current Debian SID that uses systemd, so I installed 
xserver-xorg-video-mach64 on a Pismo:

# apt-get install xserver-xorg-video-mach64

and then copied /usr/lib/xorg/modules/drivers/mach64_drv.so to the 
slightly older Debian SID on the Wallstreet that uses sysvinit, and that 
seems to work (I'll eventually install xserver-xorg-video-mach64 on my 
Wallstreet when it's using sysvinit).

# ls -l mach64_drv.so
-rw-r--r-- 1 root root 200780 May  5 06:10 mach64_drv.so
# sha1sum mach64_drv.so
e89e377f12b1738548c99d090986115566d1a535  mach64_drv.so

Please add xserver-xorg-video-mach64 to the default set of packages that 
get installed when installing an X11 desktop environment. That's likely 
needed for all systems that use "video=atyfb...".

BTW, saying that systemd "... enables a lot of services and features by 
default that you can just disable" is true but only useful if the system 
actually boots; otherwise, systemctl may not even be available to tune 
systemd if the system is stuck in a loop at boot time with the rootfs 
mounted readonly. IMO, what is needed is a tool that can be used to tune 
systemd from a rescue rootfs such as Gentoo. Or if anyone has a set of 
steps that can be used to minimize the impact of systemd on old systems 
such as the Wallstreet, I would like to see it.

The fact that "video=ofonly" doesn't work on the Wallstreet may be due 
to the kernel regression that has been reported (no response yet from a 
kernel developer). For now, make sure to uncheck "No video driver" in 
BootX, then specify the correct "video=atyfb..." line in additional 
kernel options.

In Gentoo, I'm not sure which package to install to get 
/usr/lib/xorg/modules/drivers/mach64_drv.so, but copying the file from 
Debian SID seems to be a good workaround for now.

The fonts seem a little choppy in X11, as if the screen is the wrong 
size, so there's still work to do.


On 9/11/25 11:07 AM, Stan Johnson wrote:
> I doubt that this is the same issue. The Debian kernel referenced in the 
> links was Linux version 4.9.0-2-powerpc.
> 
> The Wallstreet has worked on and off since then, with kernel regressions 
> introduced as recently as a few years ago regarding KUEP and KUAP.
> 
> If you have the .config file that they used to compile their custom 
> kernel, we can try compiling a recent kernel. Note that v6.1 works; the 
> possible kernel regression occurred between v6.2-rc1 (good) and v6.2-rc8 
> (bad).
> 
> The possible kernel regression we may be seeing now is that the 
> "video=ofonly" fallback stopped working on the Wallstreet. But we should 
> first determine whether the xorg mach64 driver can be made to work (why 
> doesn't mach64 show up in /usr/lib/xorg/modules/drivers?)
> 
> And the complete freeze may be a different problem than X11 not working 
> but still getting a text login.
> 
> 
> On 9/11/25 10:26 AM, Cedar Maxwell wrote:
>> Looks like some folks at Arch fixed this with a custom kernel:
>>
>> https://bbs.archlinux32.org/viewtopic.php?id=2776
>>
>> Adrian, Riccardo and others discussed this exact same issue at length 9
>> years ago, so looks like this isn't new.:
>>
>> https://linux.debian.ports.powerpc.narkive.com/vQmkxrXj/xorg-fails-on-ati-after-update-mmio-aperture
>>
>> But this "regression" is just about the Xorg server failing to launch
>> with Mach64, it has nothing to do with the complete system hang we are
>> seeing on kernel 6.2+
>>
>> On Thu, 2025-09-11 at 09:32 -0600, Stan Johnson wrote:
>>> Hi Cedar,
>>>
>>> On 9/10/25 9:49 AM, Cedar Maxwell wrote:
>>>> On Mon, 2025-09-08 at 21:15 -0600, Stan Johnson wrote:
>>>>> ...
>>>>>>>
>>>>>>> My BootX configuration is as follows (working X11 in 6.1.0 in
>>>>>>> Gentoo):
>>>>>>>         Kernel: vmlinux-6.1.0-pmac (custom kernel, no modules)
>>>>>>>         Boot Device: /dev/sda13 (Gentoo partition)
>>>>>>>         More kernel arguments:
>>>>>>> video=atyfb:vmode:14,cmode:32,mclk:71
>>>>>>>         No video driver: checked
>>>>>>>         Options:
>>>>>>>           Force SCSI ON: checked
>>>>>>>           Force video settings: checked
>>>>>>>           Use specified RAM disk: not checked
>>>>>>
>>>>>> ...
>>>>
>>>> In your Xorg.log it should say which "video=" option you are using.
>>>> ...
>>>
>>> On a Wallstreet running kernel 6.1 in Gentoo and using twm:
>>>
>>> $ fgrep video xorg.0.log
>>> [    70.783] Kernel command line: root=/dev/sda13
>>> video=atyfb:vmode:14,cmode:32,mclk:71 video=ofonly
>>> [    72.023] (II) FBDEV(0): hardware: OFfb ATY,RageLT (video memory:
>>> 3072kB)
>>>
>>> $ cat /proc/cmdline
>>> root=/dev/sda13 video=atyfb:vmode:14,cmode:32,mclk:71 video=ofonly
>>>
>>> Like you noticed, it appears that "video=ofonly" is also being passed
>>> since I checked "No video driver".
>>>
>>> See Xorg.0.log_no_video_driver_checked.xz, attached. X11 works.
>>>
>>> If I uncheck "No video driver", video=ofonly is no longer being
>>> passed
>>> to the kernel, and X11 does not work (text login prompt only):
>>>
>>> $ fgrep video Xorg.0.log
>>> [    66.565] Kernel command line: root=/dev/sda13
>>> video=atyfb:vmode:14,cmode:32,mclk:71
>>>
>>> $ cat /proc/cmdline
>>> root=/dev/sda13 video=atyfb:vmode:14,cmode:32,mclk:71
>>>
>>> See Xorg.0.log_no_video_driver_unchecked.xz, attached. X11 doesn't
>>> work.
>>>
>>> I think the atyfb driver is the same as Mach64; I see this in
>>> Xorg.0.log
>>> when video=ofonly isn't passed to the kernel:
>>>
>>> $ grep -i Mach64 Xorg.0.log
>>> [    67.315] (II) LoadModule: "mach64"
>>> [    67.323] (WW) Warning, couldn't open module mach64
>>> [    67.323] (EE) Failed to load module "mach64" (module does not
>>> exist, 0)
>>>
>>> So we may need to investigate why xorg module mach64 doesn't exist in
>>> /usr/lib/xorg/modules/drivers.
>>>
>>>
>>>   > ...
>>
>