Re: Sun45 garbled radeondrm output

> From: David Stanaway <[email protected]>
> Date: Wed, 25 Mar 2026 02:16:35 +0000
> 
> I have the same experience and posted a while back.
> 
> X11 works, but the key binding to change virtual consoles throws error.
> 
> Looking into it, during initialization of the framebuffer, it was unable 
> to find a supported display mode and sets to an 8bpp mode that is not 
> rendered correctly or supported by the hardware, I couldn't see a way to 
> specify mode for the frame-buffer at boot. For me the snapshot at the 
> time froze on boot at about the point of the frame-buffer initialization.

-current might be better.  At least it looks as if 8bpp modes have
been fixed.

> On 3/21/26 14:18, Thomas de Grivel wrote:
> > No, X11 works fine even without config.
> >
> > It's just radeondrm
> >
> >
> > Thomas de Grivel
> > https://www.kmx.io/
> >
> >
> > On Sat, Mar 21, 2026, 20:14 Mike Tremaine <[email protected]> wrote:
> >
> >     I have a similar experience with my Sun Ultra5 (XVR-100). I think
> >     it is because it fails to initialize the card (no 3d acceleration)
> >     and falls back to basic frame buffer mode at 1280x1024 which
> >     freaks my monitor out.
> >     From my DMESG (I saved this in my notes when it happened)
> >
> >     radeondrm0: RV100 [drm] *ERROR* radeon: ring test failed
> >     (scratch(0x15E4)=0xCAFEDEAD) [drm] *ERROR* radeon: cp isn't
> >     working (-22). drm:pid0:r100_startup *ERROR* failed initializing
> >     CP (-22). drm:pid0:r100_init *ERROR* Disabling GPU acceleration
> >     drm:pid0:drm_fb_helper_find_format *WARNING* [drm] format
> >     0x20203843 not supported drm:pid0:drm_fb_helper_find_format
> >     *WARNING* [drm] format 0x20203843 not supported
> >     drm:pid0:drm_fb_helper_find_format *WARNING* [drm] format
> >     0x20203843 not supported radeondrm0: 1280x1024, 8bpp
> >
> >
> >     All you need to do is ssh into the machine and setup your
> >     xorg.conf  -> /etc/X11/xorg.conf
> >
> >     This is what I have yours is going to be different (you got better
> >     hardware all around)
> >
> >     Section "Monitor"
> >         Identifier "SyncMaster953BW"
> >         HorizSync   30.0 - 81.0
> >         VertRefresh 56.0 - 75.0
> >         Option "DPMS"
> >     EndSection
> >
> >     Section "Device"
> >         Identifier "XVR100"
> >         Driver     "radeon"
> >         Option     "AccelMethod" "none"
> >         Option     "SWcursor" "true"
> >     EndSection
> >
> >     Section "Screen"
> >         Identifier "Screen0"
> >         Device     "XVR100"
> >         Monitor    "SyncMaster953BW"
> >         DefaultDepth 24
> >         SubSection "Display"
> >             Depth 24
> >             Modes "1440x900" "1280x1024" "1024x768"
> >         EndSubSection
> >     EndSection
> >
> >
> >     > On Mar 21, 2026, at 4:06 AM, Thomas de Grivel <[email protected]> wrote:
> >     >
> >     > Hello sparc@,
> >     >
> >     > I have a nice Sun45 at my desk and the only system that would
> >     actually
> >     > install is OpenBSD ! Never mind NetBSD, Debian, Gentoo all
> >     failed. Did
> >     > not try : FreeBSD, Ubuntu.
> >     >
> >     > If I boot 7.8 multiuser _with_ radeondrm (the default) it gives
> >     > garbled output as soon as radeondrm0 activates the frame buffer. I
> >     > tried with DMS-59/HDMI and DMS-59/VGA to no avail it does not
> >     change a
> >     > thing except the resolution of the garbled output. The output looks
> >     > like 4 or 6 screens were badly rendered side to side. Probably a
> >     > blitter error missing info on the pixel fragments / x position. An
> >     > iterator problem probably on x. Y seems ok but reduced. X is
> >     repeated
> >     > with wrong colors.
> >     >
> >     > Trying with snapshots now. The boot stops at checking filesystems...
> >     > I've been waiting 6 hours for the fs check to complete to no avail.
> >     > Will try again.
> >
>