2012/3/1 :
> Status update:
> In r600.c I found for RS780, num_*_threads are like this:
>sq_thread_resource_mgmt = (NUM_PS_THREADS(79) |
> NUM_VS_THREADS(78) |
> NUM_GS_THREADS(4) |
>
Status update:
In r600.c I found for RS780, num_*_threads are like this:
sq_thread_resource_mgmt = (NUM_PS_THREADS(79) |
NUM_VS_THREADS(78) |
NUM_GS_THREADS(4) |
NUM_ES_T
On Wed, 2012-02-29 at 12:49 +0800, che...@lemote.com wrote:
> > On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
> >> 在 2012年2月17日 下午5:27，Chen Jie 写道：
> >> >> One good way to test gart is to go over GPU gart table and write a
> >> >> dword using the GPU at end of each page something like 0xCAFED
> 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 reques
> On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
>> 在 2012年2月17日 下午5:27，Chen Jie 写道：
>> >> One good way to test gart is to go over GPU gart table and write a
>> >> dword using the GPU at end of each page something like 0xCAFEDEAD
>> >> or somevalue that is unlikely to be already set. And then
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 pendin
On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
> 在 2012年2月17日 下午5:27，Chen Jie 写道：
> >> One good way to test gart is to go over GPU gart table and write a
> >> dword using the GPU at end of each page something like 0xCAFEDEAD
> >> or somevalue that is unlikely to be already set. And then go ove
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_B
在 2012年2月17日 下午5:27，Chen Jie 写道：
>> One good way to test gart is to go over GPU gart table and write a
>> dword using the GPU at end of each page something like 0xCAFEDEAD
>> or somevalue that is unlikely to be already set. And then go over
>> all the page and check that GPU write succeed. Abusing
>> 在 2012年2月15日 下午11:53，Jerome Glisse 写道：
>>> To me it looks like the CP is trying to fetch memory but the
>>> GPU memory controller fail to fullfill cp request. Did you
>>> check the PCI configuration before & after (when things don't
>>> work) My best guest is PCI bus mastering is no properly wo
在 2012年2月17日 上午12:32，Jerome Glisse 写道：
> Ok let's start from the begining, i convince it's related to GPU
> memory controller failing to full fill some request that hit system
> memory. So in another mail you wrote :
>
>> BTW, I found radeon_gart_bind() will call pci_map_page(), it hooks
>> to swi
On Thu, Feb 16, 2012 at 05:21:10PM +0800, Chen Jie wrote:
> Hi,
>
> 在 2012年2月15日 下午11:53，Jerome Glisse 写道：
> > To me it looks like the CP is trying to fetch memory but the
> > GPU memory controller fail to fullfill cp request. Did you
> > check the PCI configuration before & after (when things do
在 2012年2月16日 下午5:21，Chen Jie 写道：
> Hi,
>
> 在 2012年2月15日 下午11:53，Jerome Glisse 写道：
>> To me it looks like the CP is trying to fetch memory but the
>> GPU memory controller fail to fullfill cp request. Did you
>> check the PCI configuration before & after (when things don't
>> work) My best guest i
Hi,
在 2012年2月15日 下午11:53，Jerome Glisse 写道：
> To me it looks like the CP is trying to fetch memory but the
> GPU memory controller fail to fullfill cp request. Did you
> check the PCI configuration before & after (when things don't
> work) My best guest is PCI bus mastering is no properly working
On Wed, Feb 15, 2012 at 05:32:35PM +0800, Chen Jie wrote:
> Hi,
>
> Status update about the problem 'Occasionally "GPU lockup" after
> resuming from suspend.'
>
> First, this could happen when system returns from a STR(suspend to
> ram) or STD(suspend to disk, aka hibernation).
> When returns fro
Hi,
Status update about the problem 'Occasionally "GPU lockup" after
resuming from suspend.'
First, this could happen when system returns from a STR(suspend to
ram) or STD(suspend to disk, aka hibernation).
When returns from STD, the initialization process is most similar to
the normal boot.
The
2011/12/16 :
>> On Don, 2011-12-08 at 19:35 +0800, che...@lemote.com wrote:
>>>
>>> I found CP_RB_WPTR has changed when "ring test failed", so I think CP is
>>> active, but what it get from ring buffer is wrong.
>>
>> CP_RB_WPTR is normally only changed by the CPU after adding commands to
>> the r
On Fre, 2011-12-16 at 16:42 +0800, che...@lemote.com wrote:
> > On Don, 2011-12-08 at 19:35 +0800, che...@lemote.com wrote:
> >>
> >> I found CP_RB_WPTR has changed when "ring test failed", so I think CP is
> >> active, but what it get from ring buffer is wrong.
> >
> > CP_RB_WPTR is normally only
> On Don, 2011-12-08 at 19:35 +0800, che...@lemote.com wrote:
>>
>> I found CP_RB_WPTR has changed when "ring test failed", so I think CP is
>> active, but what it get from ring buffer is wrong.
>
> CP_RB_WPTR is normally only changed by the CPU after adding commands to
> the ring buffer, so I'm af
On Don, 2011-12-08 at 19:35 +0800, che...@lemote.com wrote:
>
> I found CP_RB_WPTR has changed when "ring test failed", so I think CP is
> active, but what it get from ring buffer is wrong.
CP_RB_WPTR is normally only changed by the CPU after adding commands to
the ring buffer, so I'm afraid that
Thank you for your reply.
I found CP_RB_WPTR has changed when "ring test failed", so I think CP is
active, but what it get from ring buffer is wrong. Then, I want to know
whether there is a way to check the content that GPU get from ring buffer.
BTW, when I use "echo shutdown > /sys/power/disk; e
2011/12/7 :
> When "MC timeout" happens at GPU reset, we found the 12th and 13th
> bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these
> two bits are like this:
> #define G_000E50_MCDX_BUSY(x) (((x) >> 12) & 1)
> #define G_000E50_MCDW_BUSY(x)
When "MC timeout" happens at GPU reset, we found the 12th and 13th
bits of R_000E50_SRBM_STATUS is 1. From kernel code we found these
two bits are like this:
#define G_000E50_MCDX_BUSY(x) (((x) >> 12) & 1)
#define G_000E50_MCDW_BUSY(x) (((x) >> 13) & 1)
Co
And, I want to know something:
1, Does GPU use MC to access GTT?
2, What can cause MC timeout？
> Hi,
>
> Some status update.
> 在 2011年9月29日 下午5:17，Chen Jie 写道：
>> Hi,
>> Add more information.
>> We got occasionally "GPU lockup" after resuming from suspend(on mipsel
>> platform with a mips64 compa
On Tue, Nov 08, 2011 at 03:33:03PM +0800, Chen Jie wrote:
> Hi,
>
> Some status update.
> 在 2011年9月29日 下午5:17，Chen Jie 写道：
> > Hi,
> > Add more information.
> > We got occasionally "GPU lockup" after resuming from suspend(on mipsel
> > platform with a mips64 compatible CPU and rs780e, the kernel
2011/11/8 :
> And, I want to know something:
> 1, Does GPU use MC to access GTT?
Yes. All GPU clients (display, 3D, etc.) go through the MC to access
memory (vram or gart).
> 2, What can cause MC timeout？
Lots of things. Some GPU client still active, some GPU client hung or
not properly initi
Hi,
Some status update.
在 2011年9月29日 下午5:17，Chen Jie 写道：
> Hi,
> Add more information.
> We got occasionally "GPU lockup" after resuming from suspend(on mipsel
> platform with a mips64 compatible CPU and rs780e, the kernel is 3.1.0-rc8
> 64bit). Related kernel message:
> /* return from STR */
>
On Die, 2011-10-18 at 16:35 +0800, Chen Jie wrote:
>
> 在 2011年10月17日 下午2:34， 写道：
> If I start X but switch to the console, then do suspend &
> resume, "GPU
> reset" hardly happen. but there is a new problem that the IRQ
> of radeon
> card is disabled. Maybe
Hi,
在 2011年10月17日 下午2:34， 写道：
> If I start X but switch to the console, then do suspend & resume, "GPU
> reset" hardly happen. but there is a new problem that the IRQ of radeon
> card is disabled. Maybe "GPU reset" has something to do with "IRQ
> disabled"?
>
> I have tried "irqpoll", it doesn't
2011/10/5 Michel Dänzer :
> On Don, 2011-09-29 at 17:17 +0800, Chen Jie wrote:
>>
>> We got occasionally "GPU lockup" after resuming from suspend(on mipsel
>> platform with a mips64 compatible CPU and rs780e, the kernel is
>> 3.1.0-rc8 64bit). Related kernel message:
>
> [...]
>
>> [ 177.085937]
On Don, 2011-09-29 at 17:17 +0800, Chen Jie wrote:
>
> We got occasionally "GPU lockup" after resuming from suspend(on mipsel
> platform with a mips64 compatible CPU and rs780e, the kernel is
> 3.1.0-rc8 64bit). Related kernel message:
[...]
> [ 177.085937] radeon :01:05.0: GPU lockup CP s
Hi,
Add more information.
We got occasionally "GPU lockup" after resuming from suspend(on mipsel
platform with a mips64 compatible CPU and rs780e, the kernel is 3.1.0-rc8
64bit). Related kernel message:
/* return from STR */
[ 156.152343] radeon :01:05.0: WB enabled
[ 156.187500] [drm] rin
32 matches
Mail list logo
