Bug 40103

(II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS

Check the drm/radeon initialization messages in dmesg. Usually this is due to failing to load a firmware file. I guess we should handle the failure more gracefully though...

Created attachment 50236 [details]
screenshot

I should probably add that the mouse cursor is a "box" which moves, so the server appears working fine. A photo attached to prove it.

Created attachment 50237 [details]
full dmesg

the interesting bits from dmesg:

[    9.455331] [drm] Initialized drm 1.1.0 20060810
[    9.562808] [drm] radeon defaulting to kernel modesetting.
[    9.562811] [drm] radeon kernel modesetting enabled.
[    9.562865] radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    9.562870] radeon 0000:01:00.0: setting latency timer to 64
[    9.563019] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779).
[    9.563062] [drm] register mmio base: 0xFE8C0000
[    9.563064] [drm] register mmio size: 131072
[    9.563377] ATOM BIOS: 6779.13.12.0.0.AS03
[    9.563569] radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
[    9.563572] radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
[    9.564306] [drm] Detected VRAM RAM=512M, BAR=256M
[    9.564309] [drm] RAM width 32bits DDR
[    9.568873] [TTM] Zone  kernel: Available graphics memory: 3062390 kiB.
[    9.568876] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
[    9.568878] [TTM] Initializing pool allocator.
[    9.568898] [drm] radeon: 512M of VRAM memory ready
[    9.568899] [drm] radeon: 512M of GTT memory ready.
[    9.568915] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    9.568917] [drm] Driver supports precise vblank timestamp query.
[    9.568956] radeon 0000:01:00.0: irq 44 for MSI/MSI-X
[    9.568961] radeon 0000:01:00.0: radeon: using MSI.
[    9.568998] [drm] radeon: irq initialized.
[    9.569002] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    9.579091] [drm] Loading CAICOS Microcode
[    9.568998] [drm] radeon: irq initialized.
[    9.569002] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    9.579091] [drm] Loading CAICOS Microcode
[   10.026510] radeon 0000:01:00.0: WB enabled
[   10.204837] [drm:r600_ring_test] *ERROR* radeon: ring test failed (scratch(0x8504)=0xCAFEDEAD)
[   10.204843] radeon 0000:01:00.0: disabling GPU acceleration
[   10.206115] radeon 0000:01:00.0: ffff8801a29c4400 unpin not necessary
[   10.206447] failed to evaluate ATIF got AE_BAD_PARAMETER
<connector info>
[   10.290516] [drm] radeon: power management initialized
[   10.376185] [drm] fb mappable at 0xD0141000
[   10.376187] [drm] vram apper at 0xD0000000
[   10.376189] [drm] size 9216000
[   10.376190] [drm] fb depth is 24
[   10.376191] [drm]    pitch is 7680
[   10.376309] fbcon: radeondrmfb (fb0) is primary device
[   10.376942] Console: switching to colour frame buffer device 240x75
[   10.376993] fb0: radeondrmfb frame buffer device
[   10.376994] drm: registered panic notifier
[   10.377001] [drm] Initialized radeon 2.10.0 20080528 for 0000:01:00.0 on minor 0
<calltrace >
[   10.609455] [drm:radeon_ttm_backend_bind] *ERROR* failed to bind 2250 pages at 0x00000000
[   10.609800] radeon 0000:01:00.0: object_init failed for (9216000, 0x00000002)
[   10.609802] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (9216000, 2, 4096, -22)
<rinse,repeat>

I get the exact same behaviour, with pretty much the same setup.

64-bit Ubuntu Oneiric Beta1, 3.0 kernel, xorg-edgers PPA for latest drivers.

Created attachment 50935 [details]
dmesg

Created attachment 50959 [details]
dmesg with ttm dma pool 1.7 patchset

After discussion with Dave Airlie he concluded that the chipset (Intel G31 in my case) doesn't have DMAR / IOMMU and that systems with 4GB or more memory enabled SWIOTLB in those cases, which was the problem.

However, booting with mem=3G or with physical memory below 4GB did not solve the problem.

Disabling iommu with iommu=off only disabled the SATA-support without solving the Radeon-issue.

Booting with less than 4GB of memory and iommu=off did not disable SATA-support but did not solve the issue either.

I finally tried compiling the Oneiric kernel with the TTM DMA Pool 1.7 patchset from Konrad for Xen, but the ring test still failed. Reading the source I can conclude that the test writes "0xDEADBEEF" but reads "0xCAFEDEAD".

Not sure how to proceed.

Attaching dmesg from boot with TTM DMA Pool 1.7 patchset.

Does this patch:
http://lists.freedesktop.org/archives/dri-devel/2011-August/013591.html
adapted for evergreen/ni chips help?

I'm not sure how to adapt it for evergreen/ni.

If you'd send me such a patch I'd be happy to try it out and report back.

I tried this:

diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 15bd047..1630423 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1404,6 +1404,7 @@ int evergreen_cp_resume(struct radeon_device *rdev)

        rdev->cp.rptr = RREG32(CP_RB_RPTR);
        rdev->cp.wptr = RREG32(CP_RB_WPTR);
+       rdev->cp.wptr &= rdev->cp.ptr_mask;

        evergreen_cp_start(rdev);
        rdev->cp.ready = true;

but it just hung the machine when X had started (before it got to write any
logs).

(In reply to comment #10)
> I tried this:
> 
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 15bd047..1630423 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -1404,6 +1404,7 @@ int evergreen_cp_resume(struct radeon_device *rdev)
> 
>         rdev->cp.rptr = RREG32(CP_RB_RPTR);
>         rdev->cp.wptr = RREG32(CP_RB_WPTR);
> +       rdev->cp.wptr &= rdev->cp.ptr_mask;
> 
>         evergreen_cp_start(rdev);
>         rdev->cp.ready = true;
> 
> but it just hung the machine when X had started (before it got to write any
> logs).

Sounds like the change did make a difference though... can you attach dmesg for that?

Created attachment 50969 [details] [review]
Don't read from CP ring write pointer registers

This patch goes further and removes any reliance on reads from those registers. Does it help?

Created attachment 50974 [details]
dmesg with the patched kernel

unfortunately no, VT's still look corrupted, and starting X hangs the machine.

Created attachment 51806 [details] [review]
workaround debugged on my caicos

please test this patch and tell me if it works for you.

If it does AMD will have to debug things from here, I just got this using old fashion if 0 bisection.

This patch, applied to latest Ubuntu Oneiric kernel, works perfectly!

Performance blows fglrx out of the water and the display management is way better than the AMD CCCLE.

Finally a usable desktop, thank you so much!

I have some strange issue with XVideo, though.

I started playing a video with Totem and the colors were off and way too dark.
Then I tried playing it with VLC and mplayer with the same result.
But then I tried to play the video with the x11 output (mplayer -vo x11) which showed the correct colors, and the next try with mplayer -vo xv also had the right colors.

This can be better compared in gstreamer-properties, where the test-stream for x11 looks like it should, but for xv, everything white or black is black and the rest of the colors are too dark.

I had similar issues with XVideo on fglrx, where XVideo could turn completely black from time to time.

(In reply to comment #16)
> I have some strange issue with XVideo, though.

Make sure your Xv attributes aren't adjusted strangely.  Some apps set strange default values.

Created attachment 51957 [details] [review]
channel remap fix

This patch should fix the issue.

A patch referencing this bug report has been merged in Linux v3.1-rc9:

commit 12d5180bd7e683a4ae80830b82ba67e7b7fac7b2
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Oct 4 10:46:34 2011 -0400

    drm/radeon/kms: fix channel_remap setup (v2)

*** Bug 42373 has been marked as a duplicate of this bug. ***