> 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. > I've tried the method of rs600 for gpu reset (use rs600_bm_disable() to disable PCI MASTER bit and enable it after reset), but it doesn't solve the problem. Then I found that in r100_bm_disable() it do more things, e.g. writing the GPU register R_000030_BUS_CNTL. In r600_reg.h there is a register R600_BUS_CNTL, does this register have a similar function? But I don't know how to use it... Huacai Chen >> >> 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
