On 11/1/06, Alex Deucher <[EMAIL PROTECTED]> wrote:
No problem. I appreciate the responses.
Alex,
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:
Initialization:
....
[drm:radeon_do_init_cp]
[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_cp_load_microcode]
[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!
[drm:radeon_do_engine_reset]
[drm:radeon_do_cp_reset]
....
In radeon_do_cp_start:
[drm] radeon_do_cp_start: About to COMMIT ring:
radeon_status:
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:
radeon_status:
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.
Thanks,
--Phil
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!
Alex
Alex,
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:
Initialization:
....
[drm:radeon_do_init_cp]
[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_cp_load_microcode]
[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!
[drm:radeon_do_engine_reset]
[drm:radeon_do_cp_reset]
....
In radeon_do_cp_start:
[drm] radeon_do_cp_start: About to COMMIT ring:
radeon_status:
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:
radeon_status:
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.
Thanks,
--Phil
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
