On 11/1/06, Alex Deucher <> wrote:
Sorry for the delay in response.

No problem. I appreciate the responses.

These are what the bits in the RBBM_STATUS register mean for r300
(XPRESS may differ slightly)

6:0  Available slots in the FIFO
8    Host Interface active
9    CP request active
10   FIFO request active
11   Host Interface retry active
12   CP retry active
13   FIFO retry active
14   FIFO pipeline busy
15   Event engine busy
16   CP command stream busy
17   2D engine busy
18   2D portion of render backend busy
20   3D setup engine busy
26   GA engine busy
27   CBA 2D engine busy
31   2D engine busy or 3D engine busy or FIFO not empty or CP busy or
        command stream queue not empty or Ring Buffer not empty

Based on this information (which could be different for XPRESS),
"0x8001c100" means:
host interface is active
FIFO pipeline busy
Event engine busy
CP command stream busy
bit 31 - something is busy

Good luck!


    First, thanks for the clarification and help.

    Ok.  I've made a small amount of progress. I figured out that the X server was treating the card as a PCI card rather than a PCIExpress card.  I fixed that by forcing the bus type. (Option "BusType" "PCIE").

I've also tracked the CP hang down a little more. It hangs on the first use after radeon_do_init_cp has completed.  So, rather than a particular bogus command, I suspect that this some sort of setup issue.

I've turned on tracing like crazy (and added some of my own debugging), so maybe this can help:

[drm:radeon_do_init_cp] dev_priv->cp_ring->handle f8bd1000
[drm:radeon_do_init_cp] dev_priv->ring_rptr->handle f8cd2000
[drm:radeon_do_init_cp] dev->agp_buffer_map->handle f8cd3000
[drm] Setting GART location based on new memory map
[drm:radeon_do_init_cp] dev_priv->gart_size 8388608
[drm:radeon_do_init_cp] dev_priv->gart_vm_start 0x58000000
[drm:radeon_do_init_cp] dev_priv->gart_buffers_offset 0x58102000
[drm:radeon_do_init_cp] Setting phys_pci_gart to f8bb0000 0FFF8000
[drm:drm_ati_pcigart_init] PCI: Gart Table: VRAM 57FF8000 mapped at F8BB0000
[drm:radeon_set_pciegart] programming pcie 58000000 57FF8000 00800000
[drm] radeon_do_wait_for_fifo 6: Succeeded!
[drm] radeon_do_wait_for_idle 6: Succeeded!
[drm] Loading R300 Microcode
[drm:radeon_cp_init_ring_buffer] ring rptr: offset=0x33adf000 handle=0xf8cd2000
[drm] radeon_do_wait_for_fifo 6: Succeeded!
[drm] radeon_do_wait_for_idle 6: Succeeded!

In radeon_do_cp_start:

[drm] radeon_do_cp_start: About to COMMIT ring:
RBBM_STATUS = 0x00000140
CP_RB_RTPR = 0x00000000
CP_RB_WTPR = 0x00000000
AIC_CNTL = 0x000007e0
AIC_STAT = 0x00000000
AIC_PT_BASE = 0x00000000
TLB_ADDR = 0x00000000
TLB_DATA = 0x00000000

[drm] radeon_do_cp_start: Finished COMMIT ring:
RBBM_STATUS = 0x80010140
CP_RB_RTPR = 0x00000006
CP_RB_WTPR = 0x00000006
AIC_CNTL = 0x000007e0
AIC_STAT = 0x00000000
AIC_PT_BASE = 0x00000000
TLB_ADDR = 0x00000000
TLB_DATA = 0x00000000

For "RBBM_STATUS = 0xXXX1XXXX", this means:
bit 16:   CP command stream busy

After this, the "CP command stream" never reports a "non-busy" status. Ie, bit 16 (AND bit 31) is always set.

Do you have any idea how the CP could go haywire?

0) What has to be setup properly for the CP work? (Or conversely, what, if setup improperly, could cause the CP to hang...)

1) Could the ring buffer be mapped into a different location than we told the CP?  (And the CP is executing some bogus/random commands..)  (In particular, would this mean that the code in 'radeon_cp_init_ring_buffer' is wrong for this card? )

2) Could the R300 FW that has been uploaded be the incorrect one for this card? (I noticed that radeon_do_cp_start is the first time the cp is fed commands after the FW is loaded. )  Is there a simple test to see if the CP is working?

There are more problems later, but I think that this is the start of the badness.