Re: OldWorld ROM Macintoshes
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.
>>>>
>>>>
>>>> > ...
>>>
>>
>
Reply to: