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.
> ...
