On 11/5/06, Phillip Ezolt <[EMAIL PROTECTED]> wrote: > Alex, > > On 11/1/06, Alex Deucher <[EMAIL PROTECTED]> 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! > > > > 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").
Good. make sure the PCIE ring buffer is set up properly in vram. > > 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? Lots of things. It could be a hardware bug on the XPRESS chips that the busy bit never clears, although I would hope a bit that important would work properly. You might try waiting on slots rather than on the busy bit as a work around. Savage chips have a bug like this, fortunately they have an alternate method for checking status. > > 0) What has to be setup properly for the CP work? (Or conversely, what, if > setup improperly, could cause the CP to hang...) Lots of stuff can cause it to hang unfortunately. > > 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? ) XPRESS chips may need some additional set up. > > 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? > Very possible. you might try grabbing the microcode from fglrx or the windows driver and see if that helps. > There are more problems later, but I think that this is the start of the > badness. If definitely looks like it. > > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
