# apt-get install xserver-xorg-video-mach64and 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.soPlease 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. > ...