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) |
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) |
2012/3/1 che...@lemote.com:
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) |
> 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
On Wed, 2012-02-29 at 12:49 +0800, chenhc at 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
> 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 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 ch...@lemote.com 写道：
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
On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
在 2012年2月17日 下午5:27，Chen Jie ch...@lemote.com 写道：
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
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
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
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
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)
*
On Tue, 2012-02-21 at 18:37 +0800, Chen Jie wrote:
在 2012年2月17日 下午5:27，Chen Jie ch...@lemote.com 写道：
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 pending in
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)
*
? 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.
在 2012年2月17日 下午5:27，Chen Jie ch...@lemote.com 写道：
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
>> ? 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
? 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
在 2012年2月17日 上午12:32，Jerome Glisse j.gli...@gmail.com 写道：
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
在 2012年2月15日 下午11:53，Jerome Glisse j.gli...@gmail.com 写道：
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
? 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
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 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
在 2012年2月16日 下午5:21，Chen Jie ch...@lemote.com 写道：
Hi,
在 2012年2月15日 下午11:53，Jerome Glisse j.gli...@gmail.com 写道：
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
On Thu, Feb 16, 2012 at 05:21:10PM +0800, Chen Jie wrote:
Hi,
在 2012年2月15日 下午11:53，Jerome Glisse j.gli...@gmail.com 写道：
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
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
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
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
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 from STD,
> On Don, 2011-12-08 at 19:35 +0800, chenhc at 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
On Fre, 2011-12-16 at 16:42 +0800, chenhc at lemote.com wrote:
> > On Don, 2011-12-08 at 19:35 +0800, chenhc at 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
2011/12/16 :
>> On Don, 2011-12-08 at 19:35 +0800, chenhc at 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
>>
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
2011/12/16 che...@lemote.com:
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
On Don, 2011-12-08 at 19:35 +0800, chenhc at 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
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 may
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; echo
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;
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)
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)
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
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 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
2011/11/8 che...@lemote.com:
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
On Tue, Nov 08, 2011 at 03:33:03PM +0800, Chen Jie wrote:
Hi,
Some status update.
在 2011年9月29日 下午5:17，Chen Jie ch...@lemote.com 写道：
Hi,
Add more information.
We got occasionally GPU lockup after resuming from suspend(on mipsel
platform with a mips64 compatible CPU and rs780e, the
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 ch...@lemote.com 写道：
Hi,
Add more information.
We got occasionally GPU lockup after resuming from suspend(on mipsel
platform with a mips64
Hi,
Some status update.
在 2011年9月29日 下午5:17，Chen Jie ch...@lemote.com 写道：
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
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
On Die, 2011-10-18 at 16:35 +0800, Chen Jie wrote:
在 2011年10月17日 下午2:34， che...@lemote.com写道：
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
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
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
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 stall
2011/10/5 Michel Dänzer mic...@daenzer.net:
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:
[...]
[
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] ring
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]
59 matches
Mail list logo
