On Mon, 2012-02-27 at 10:44 +0800, Chen Jie wrote: > Hi, > > For this occasional GPU lockup when returns from STR/STD, I find > followings(when the problem happens): > > The value of SRBM_STATUS is whether 0x20002040 or 0x20003040. > Which means: > * HI_RQ_PENDING(There is a HI/BIF request pending in the SRBM) > * MCDW_BUSY(Memory Controller Block is Busy) > * BIF_BUSY(Bus Interface is Busy) > * MCDX_BUSY(Memory Controller Block is Busy) if is 0x20003040 > Are MCDW_BUSY and MCDX_BUSY two memory channels? What is the > relationship among GART mapped memory, On-board video memory and MCDX, > MCDW? > > CP_STAT: the CSF_RING_BUSY is always set. Once the memory controller fails to do a pci transaction the CP will be stuck. At least if ring is in system memory, if ring is in vram CP might be stuck too because anyway everything goes through the MC. > > There are many CP_PACKET2(0x80000000) in CP ring(more than three hundreds). e.g. > r[131800]=0x00028000 > r[131801]=0xc0016800 > r[131802]=0x00000140 > r[131803]=0x000079c5 > r[131804]=0x0000304a > r[131805] ... r[132143]=0x80000000 > r[132144]=0xffff0000 > After the first reset, GPU will lockup again, this time, typically > there are 320 dwords in CP ring -- with 319 CP_PACKET2 and 0xc0033d00 > in the end. > Are these normal? > > BTW, is there any way for X to switch to NOACCEL mode when the problem > happens? Thus users will have a chance to save their documents and > then reboot machine. I have been meaning to patch the ddx to fallback to sw after GPU lockup. But this is useless in today world, where everything is composited ie the screen is updated using the 3D driver for which there is no easy way to suddenly migrate to software rendering. I will still probably do the ddx patch at one point. Cheers, Jerome _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
