> Date: Sat, 11 Dec 2021 05:10:41 -0700
> From: Ted Bullock <[email protected]>
>
> 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?
Yes, but the most likely answer you'll get there is probably "we don't
care about big-endian platforms".
> > 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].
The are several reasons why that test can fail though. It can be an
endian-ness issue or on sparc64 it could also be an IOMMU issue where
the wrong address is programmed into the hardware because CPU
addresses aren't properly translated into device virtual addresses.
> 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]>
>
