On 2021-12-11 4:41 a.m., Mark Kettenis wrote:
Date: Fri, 10 Dec 2021 17:24:58 -0700
From: Ted Bullock <[email protected]>
So the real problem is:
[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] *ERROR* Wait for CP idle timeout, shutting down CP.
Failed to wait GUI idle while programming pipes. Bad things might happen.
as a result of this GPU acceleration is disabled and software
rendering is used. Which obviously has endian-ness issues.
Yeah so there are actually 2 problems here. The first is the fault you
can see above causing it to fall back to software rendering. The second
is that there is going to be some sort of endian issue (probably) with
the software renderer causing everything to display in the wrong colors.
The sad truth is that most of us don't have much time to test older
hardware and we tend to favor making new hardware work correctly over
keeping the really old stuff working. But help is appreciated and we
certainly won't outright reject any fixes you discover.
That's totally expected, and not a problem for me. I'm definitely not
looking for other people to swoop in and fix this old stuff for me, but
I am trying to document what I'm finding, and if it's possible to keep
stuff working a while longer I think it's worth my time. It's not like
there will ever be another ultrasparc workstation made but there is
definitely big endian stuff out in the world. Like that new powerpc
system which is unfortunately a little too expensive to just buy to have
one sitting around.
Is this more appropriate to take to the freedesktop.org bug list btw?
That said I think Jonathan said that support for the R100 is going to
be removed from Mesa, which would probably mean the end of GPU
acceleration support for that hardware.
That's kind of sad to hear given how much hardware is going to still be
out there, but I guess it depends on people using it, testing and
fixing. c'est la vie.
ok, regarding this fault, it's also apparently impacting macppc [0] and
has been around for a while [1].
sys/dev/pci/drm/radeon/r100.c:3651
WREG32(scratch, 0xCAFEDEAD);
r = radeon_ring_lock(rdev, ring, 2);
if (r) {
DRM_ERROR("radeon: cp failed to lock ring (%d).\n", r);
radeon_scratch_free(rdev, scratch);
return r;
}
radeon_ring_write(ring, PACKET0(scratch, 0));
radeon_ring_write(ring, 0xDEADBEEF);
radeon_ring_unlock_commit(rdev, ring, false);
for (i = 0; i < rdev->usec_timeout; i++) {
tmp = RREG32(scratch);
if (tmp == 0xDEADBEEF) {
break;
}
udelay(1);
}
if (i < rdev->usec_timeout) {
DRM_INFO("ring test succeeded in %d usecs\n", i);
} else {
DRM_ERROR("radeon: ring test failed (scratch(0x%04X)=0x%08X)\n",
scratch, tmp);
r = -EINVAL;
}
[0] https://marc.info/?l=openbsd-bugs&m=162447131102854
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/162
--
Ted Bullock <[email protected]>
