Cedar, Are you able to confirm that installing xserver-xorg-video-mach64 allows X11 to work on your Wallstreet (passing the correct "video=atyfb..." argument and unchecking "No video driver" in BootX)?
I still think there's a kernel regression that is preventing "video=ofonly" from working. I plan to follow up later this week if I still haven't heard back from a developer. -Stan On 9/12/25 1:02 PM, Stan Johnson wrote: > 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. >>>> >>>> >>>> > ... >>> >> >
