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
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) |
>
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 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 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 0xCA
> 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 写道：
> >> >> 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
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月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
>> 在 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
? 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 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
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
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 fro
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
> 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
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 normall
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
>> th
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, 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 t
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
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
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
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)
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
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 */
>
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
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
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
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 s
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]
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
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
64 matches
Mail list logo
