On Fri, Jan 11, 2013 at 12:43:36PM +0100, Borislav Petkov wrote:
> Ok, I'm running -rc3 with this and will watch it for any changes in
> behavior.
AFAICT, this fixes the CP stalls, for I haven't seen any of them in
dmesg for the last couple of days after applying your revert.
Thanks.
--
On Tue, Jan 15, 2013 at 7:19 AM, Borislav Petkov wrote:
> On Fri, Jan 11, 2013 at 12:43:36PM +0100, Borislav Petkov wrote:
>> Ok, I'm running -rc3 with this and will watch it for any changes in
>> behavior.
>
> AFAICT, this fixes the CP stalls, for I haven't seen any of them in
> dmesg for the
On Fri, Jan 11, 2013 at 12:43:36PM +0100, Borislav Petkov wrote:
Ok, I'm running -rc3 with this and will watch it for any changes in
behavior.
AFAICT, this fixes the CP stalls, for I haven't seen any of them in
dmesg for the last couple of days after applying your revert.
Thanks.
--
On Tue, Jan 15, 2013 at 7:19 AM, Borislav Petkov b...@alien8.de wrote:
On Fri, Jan 11, 2013 at 12:43:36PM +0100, Borislav Petkov wrote:
Ok, I'm running -rc3 with this and will watch it for any changes in
behavior.
AFAICT, this fixes the CP stalls, for I haven't seen any of them in
dmesg for
On Thu, Jan 10, 2013 at 03:47:01PM -0500, Alex Deucher wrote:
> >> Does disabling the new DMA ring for ttm bo moves avoid the issue?
> >
> > How do I do that?
>
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index 9056faf..b0cc46d 100644
[ ? ]
Ok,
On Thu, Jan 10, 2013 at 03:47:01PM -0500, Alex Deucher wrote:
Does disabling the new DMA ring for ttm bo moves avoid the issue?
How do I do that?
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index 9056faf..b0cc46d 100644
[ … ]
Ok, I'm
On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote:
> I'm assuming you didn't also update your userspace gfx stack?
By that you mean x.org etc, right? Or GPU microcode too? In any case, I
haven't touched any of those deliberately, AFAICR at least.
> Does disabling the new DMA ring for
On Thu, Jan 10, 2013 at 3:32 PM, Borislav Petkov wrote:
> On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote:
>> I'm assuming you didn't also update your userspace gfx stack?
>
> By that you mean x.org etc, right? Or GPU microcode too? In any case, I
> haven't touched any of those
locks up somewhere
>> down radeon_fence_wait_seq, judging by the error messages.
>>
>> And this doesn't happen with 3.7, of course.
>>
>> Let me know if you need any more info, thanks.
>>
>> [16273.668350] radeon :02:00.0: GPU lockup CP stall for more than
&g
; And this doesn't happen with 3.7, of course.
>
> Let me know if you need any more info, thanks.
>
> [16273.668350] radeon 0000:02:00.0: GPU lockup CP stall for more than
> 1msec
> [16273.668361] radeon :02:00.0: GPU lockup (waiting for
> 0x002b last fence
with 3.7, of course.
Let me know if you need any more info, thanks.
[16273.668350] radeon :02:00.0: GPU lockup CP stall for more than
1msec
[16273.668361] radeon :02:00.0: GPU lockup (waiting for
0x002b last fence id 0x002a)
[16273.882550] plugin
radeon_fence_wait_seq, judging by the error messages.
And this doesn't happen with 3.7, of course.
Let me know if you need any more info, thanks.
[16273.668350] radeon :02:00.0: GPU lockup CP stall for more than
1msec
[16273.668361] radeon :02:00.0: GPU lockup (waiting
On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote:
I'm assuming you didn't also update your userspace gfx stack?
By that you mean x.org etc, right? Or GPU microcode too? In any case, I
haven't touched any of those deliberately, AFAICR at least.
Does disabling the new DMA ring for
On Thu, Jan 10, 2013 at 3:32 PM, Borislav Petkov b...@alien8.de wrote:
On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote:
I'm assuming you didn't also update your userspace gfx stack?
By that you mean x.org etc, right? Or GPU microcode too? In any case, I
haven't touched any of
2013-01-04 08:40 keltez?ssel, Borislav Petkov ?rta:
> On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
>> From: Alex Deucher
>> Date: Wed, 2 Jan 2013 18:30:21 -0500
>> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
>>
>> count must be a multiple of 2.
>>
>> Cc:
On Fri, Jan 4, 2013 at 6:16 AM, Boszormenyi Zoltan wrote:
> 2013-01-04 08:40 keltez?ssel, Borislav Petkov ?rta:
>
>> On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
>>>
>>> From: Alex Deucher
>>> Date: Wed, 2 Jan 2013 18:30:21 -0500
>>> Subject: [PATCH] drm/radeon/r6xx: fix DMA
On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
> From: Alex Deucher
> Date: Wed, 2 Jan 2013 18:30:21 -0500
> Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
>
> count must be a multiple of 2.
>
> Cc: Borislav Petkov
> Cc: Markus Trippelsdorf
>
,
Alexander; Borislav Petkov; Shuah Khan
Subject: Re: radeon :02:00.0: GPU lockup CP stall for more than
1msec
2013-01-03 00:37 keltezéssel, Alex Deucher írta:
On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2013.01.02 at 17:31 -0500, Jerome Glisse
2013-01-04 08:40 keltezéssel, Borislav Petkov írta:
On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
From: Alex Deucher alexander.deuc...@amd.com
Date: Wed, 2 Jan 2013 18:30:21 -0500
Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
count must be a multiple of
On Fri, Jan 4, 2013 at 6:16 AM, Boszormenyi Zoltan zbos...@pr.hu wrote:
2013-01-04 08:40 keltezéssel, Borislav Petkov írta:
On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
From: Alex Deucher alexander.deuc...@amd.com
Date: Wed, 2 Jan 2013 18:30:21 -0500
Subject: [PATCH]
: radeon 0000:02:00.0: GPU lockup CP stall for more than
> 1msec
>
> 2013-01-03 00:37 keltez?ssel, Alex Deucher ?rta:
> > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
> > wrote:
> >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
> >>
2013-01-03 00:37 keltez?ssel, Alex Deucher ?rta:
> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
> wrote:
>> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
>>> Please affected people can you test if patch :
>>>
On 2013.01.02 at 18:37 -0500, Alex Deucher wrote:
> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
> wrote:
> > On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
> >> Please affected people can you test if patch :
> >>
top.org; Deucher,
>> Alexander; Borislav Petkov; Shuah Khan
>> Subject: Re: radeon 0000:02:00.0: GPU lockup CP stall for more than
>> 1msec
>>
>> 2013-01-03 00:37 keltez?ssel, Alex Deucher ?rta:
>> > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
On 01/03/2013 01:59 AM, Alex Deucher wrote:
> On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan wrote:
>> On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher
>> wrote:
>>> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
>>> wrote:
On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
> Please
On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
Please affected people can you test if patch :
On Wed, Jan 2, 2013 at 4:59 PM, Alex Deucher alexdeuc...@gmail.com wrote:
Catching up with this thread. I reverted the
drm/radeon: use async dma for ttm buffer moves on 6xx-SI
commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2
Do I need to apply this patch without reverting
On 2013.01.02 at 18:37 -0500, Alex Deucher wrote:
On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
Please affected people can you test if patch :
2013-01-03 00:37 keltezéssel, Alex Deucher írta:
On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
Please affected people can you test if patch :
-Original Message-
From: Boszormenyi Zoltan [mailto:zbos...@pr.hu]
Sent: Thursday, January 03, 2013 6:37 AM
To: Alex Deucher
Cc: Markus Trippelsdorf; lkml; dri-devel@lists.freedesktop.org; Deucher,
Alexander; Borislav Petkov; Shuah Khan
Subject: Re: radeon :02:00.0: GPU lockup
On Wed, Jan 02, 2013 at 06:37:23PM -0500, Alex Deucher wrote:
From: Alex Deucher alexander.deuc...@amd.com
Date: Wed, 2 Jan 2013 18:30:21 -0500
Subject: [PATCH] drm/radeon/r6xx: fix DMA engine for ttm bo transfers
count must be a multiple of 2.
Cc: Borislav Petkov b...@alien8.de
Cc:
On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
> Please affected people can you test if patch :
> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch
>
> Fix the issue, you need to make sure you don't have the patch that
> disable dma on r6xx
On 01/02/2013 07:19 PM, Jerome Glisse wrote:
> On Wed, Jan 2, 2013 at 7:02 AM, Borislav Petkov wrote:
>> On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote:
>>> I ended up also that same commit after bisecting from current 3.8
>>> master.
>>>
>>> 01:05.0 VGA compatible controller:
On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan wrote:
> On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher wrote:
>> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
>> wrote:
>>> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
Please affected people can you test if patch :
On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
wrote:
> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
>> Please affected people can you test if patch :
>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch
>>
>> Fix the issue, you need
On Wed, Jan 2, 2013 at 4:59 PM, Alex Deucher wrote:
>>>
>>
>> Catching up with this thread. I reverted the
>>
>> drm/radeon: use async dma for ttm buffer moves on 6xx-SI
>> commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2
>>
>> Do I need to apply this patch without reverting
>>
Please affected people can you test if patch :
http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch
Fix the issue, you need to make sure you don't have the patch that
disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c
is :
On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher wrote:
> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
> wrote:
>> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
>>> Please affected people can you test if patch :
>>>
On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote:
> I ended up also that same commit after bisecting from current 3.8
> master.
>
> 01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon
> 3000] It is ASUS M5A78L-M/USB3 with integrated GPU.
>
> I cannot even boot
On Wed, Jan 2, 2013 at 7:02 AM, Borislav Petkov wrote:
> On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote:
>> I ended up also that same commit after bisecting from current 3.8
>> master.
>>
>> 01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon
>> 3000] It is ASUS
On 12/25/2012 06:50 AM, Shuah Khan wrote:
> On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov wrote:
>> On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote:
>>> Right, let me try that and report back.
>>
>> Yep, looks like reverting the above commit fixes it - the boston.com
>> website
On Wed, Jan 2, 2013 at 7:02 AM, Borislav Petkov b...@alien8.de wrote:
On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote:
I ended up also that same commit after bisecting from current 3.8
master.
01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon
3000] It is
On 01/02/2013 07:19 PM, Jerome Glisse wrote:
On Wed, Jan 2, 2013 at 7:02 AM, Borislav Petkov b...@alien8.de wrote:
On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote:
I ended up also that same commit after bisecting from current 3.8
master.
01:05.0 VGA compatible controller: ATI
Please affected people can you test if patch :
http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch
Fix the issue, you need to make sure you don't have the patch that
disable dma on r6xx ie that line 977-978 1061-1062 in radeon_asic.c
is :
.copy
On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
Please affected people can you test if patch :
http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch
Fix the issue, you need to make sure you don't have the patch that
disable dma on r6xx ie
On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
Please affected people can you test if patch :
http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch
Fix the
On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan shuahk...@gmail.com wrote:
On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote:
Please affected
On 01/03/2013 01:59 AM, Alex Deucher wrote:
On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan shuahk...@gmail.com wrote:
On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2013.01.02 at 17:31
On 12/25/2012 06:50 AM, Shuah Khan wrote:
On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov b...@alien8.de wrote:
On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote:
Right, let me try that and report back.
Yep, looks like reverting the above commit fixes it - the boston.com
On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov b...@alien8.de wrote:
On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote:
Right, let me try that and report back.
Yep, looks like reverting the above commit fixes it - the boston.com
website loads just fine.
Thanks.
--
On Mon, Dec 24, 2012 at 09:50:11PM -0700, Shuah Khan wrote:
> Saw the same error and after reading this thread, reverted the
>
> Commit 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2.
>
> drm/radeon: use async dma for ttm buffer moves on 6xx-SI
>
> and the problem is gone. In my case, it is a solid hang
On Mon, Dec 24, 2012 at 09:50:11PM -0700, Shuah Khan wrote:
Saw the same error and after reading this thread, reverted the
Commit 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2.
drm/radeon: use async dma for ttm buffer moves on 6xx-SI
and the problem is gone. In my case, it is a solid hang right
On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov wrote:
> On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote:
>> Right, let me try that and report back.
>
> Yep, looks like reverting the above commit fixes it - the boston.com
> website loads just fine.
>
> Thanks.
>
> --
>
On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote:
> Right, let me try that and report back.
Yep, looks like reverting the above commit fixes it - the boston.com
website loads just fine.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is
On Sun, Dec 23, 2012 at 12:51:33PM +0100, Markus Trippelsdorf wrote:
> (If you don't use modules: git grep MODULE_PARM_DESC --
> drivers/gpu/drm/radeon/ )
Yeah.
> You may have hit the same issue as I, see:
> http://thread.gmane.org/gmane.comp.video.dri.devel/78328
Yes, it very much looks like
On 2012.12.23 at 12:31 +0100, Borislav Petkov wrote:
> On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote:
> > modinfo radeon
> >
> > will give a list assuming you use modules, I think all of them need =.
>
> Yep, that is one way of getting that info, thanks. I always go and look
> at
On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote:
> modinfo radeon
>
> will give a list assuming you use modules, I think all of them need =.
Yep, that is one way of getting that info, thanks. I always go and look
at Documentation/kernel-parameters.txt and forget about modinfo.
As
On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote:
> no_wb=1 should work.
Yeah, maybe all those radeon and other GPU module parameters' syntax
should be documented somewhere - Documentation/kernel-parameters.txt for
example, or a GPU-specific file, whatever - so that we can save us all
On Sat, Dec 22, 2012 at 07:42:16PM -0500, Alex Deucher wrote:
> Does booting with radeon.wb=0 help?
Right, this param specification somehow didn't work here:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2
Borislav Petkov wrote:
> On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote:
>> no_wb=1 should work.
>
> Yeah, maybe all those radeon and other GPU module parameters' syntax
> should be documented somewhere - Documentation/kernel-parameters.txt for
> example, or a GPU-specific file,
Borislav Petkov wrote:
> [ 28.191072] radeon: `0' invalid for parameter `wb'
>
> although the whole driver blubber didn't appear on the console fterwards
> aso something got turned off allright.
>
> Then, I went and tried "radeon.no_wb" where the driver blubber appeared
> but AGP writeback was
On Sun, 2012-12-23 at 11:01 +, Andy Furniss wrote:
> Borislav Petkov wrote:
>
> > [ 28.191072] radeon: `0' invalid for parameter `wb'
> >
> > although the whole driver blubber didn't appear on the console fterwards
> > aso something got turned off allright.
> >
> > Then, I went and tried
On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote:
> What chip is this?
I think it is RV635. Here's the whole 3.8-rc1 dmesg.
[0.00] Linux version 3.8.0-rc1 (boris at liondog) (gcc version 4.7.2
(Debian 4.7.2-4) ) #13 SMP PREEMPT Sat Dec 22 11:48:54 CET 2012
[0.00]
On Sat, Dec 22, 2012 at 07:42:16PM -0500, Alex Deucher wrote:
Does booting with radeon.wb=0 help?
Right, this param specification somehow didn't work here:
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.8.0-rc1 root=/dev/sda1
ro vga=0 log_bug_len=10M resume=/dev/sda2
Borislav Petkov wrote:
[ 28.191072] radeon: `0' invalid for parameter `wb'
although the whole driver blubber didn't appear on the console fterwards
aso something got turned off allright.
Then, I went and tried radeon.no_wb where the driver blubber appeared
but AGP writeback was still
On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote:
no_wb=1 should work.
Yeah, maybe all those radeon and other GPU module parameters' syntax
should be documented somewhere - Documentation/kernel-parameters.txt for
example, or a GPU-specific file, whatever - so that we can save us all
Borislav Petkov wrote:
On Sun, Dec 23, 2012 at 11:01:37AM +, Andy Furniss wrote:
no_wb=1 should work.
Yeah, maybe all those radeon and other GPU module parameters' syntax
should be documented somewhere - Documentation/kernel-parameters.txt for
example, or a GPU-specific file, whatever -
On 2012.12.23 at 12:31 +0100, Borislav Petkov wrote:
On Sun, Dec 23, 2012 at 11:19:00AM +, Andy Furniss wrote:
modinfo radeon
will give a list assuming you use modules, I think all of them need =num.
Yep, that is one way of getting that info, thanks. I always go and look
at
On Sun, 2012-12-23 at 11:01 +, Andy Furniss wrote:
Borislav Petkov wrote:
[ 28.191072] radeon: `0' invalid for parameter `wb'
although the whole driver blubber didn't appear on the console fterwards
aso something got turned off allright.
Then, I went and tried radeon.no_wb
On Sun, Dec 23, 2012 at 12:51:33PM +0100, Markus Trippelsdorf wrote:
(If you don't use modules: git grep MODULE_PARM_DESC --
drivers/gpu/drm/radeon/ )
Yeah.
You may have hit the same issue as I, see:
http://thread.gmane.org/gmane.comp.video.dri.devel/78328
Yes, it very much looks like it.
On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote:
Right, let me try that and report back.
Yep, looks like reverting the above commit fixes it - the boston.com
website loads just fine.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
Hi Alex,
got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere
down radeon_fence_wait_seq, judging by the error messages.
And this doesn't happen with 3.7, of course.
Let me know if you need any more info, thanks.
[16273.668350] radeon :02:00.0: GPU lockup CP stall for more
On Sat, Dec 22, 2012 at 7:25 PM, Borislav Petkov wrote:
> On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote:
>> What chip is this?
>
> I think it is RV635. Here's the whole 3.8-rc1 dmesg.
Does booting with radeon.wb=0 help?
Alex
f you need any more info, thanks.
What chip is this?
Alex
>
> [16273.668350] radeon 0000:02:00.0: GPU lockup CP stall for more than
> 1msec
> [16273.668361] radeon :02:00.0: GPU lockup (waiting for
> 0x002b last fence id 0x002a)
> [1627
Hi Alex,
got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere
down radeon_fence_wait_seq, judging by the error messages.
And this doesn't happen with 3.7, of course.
Let me know if you need any more info, thanks.
[16273.668350] radeon :02:00.0: GPU lockup CP stall for more
info, thanks.
What chip is this?
Alex
[16273.668350] radeon :02:00.0: GPU lockup CP stall for more than
1msec
[16273.668361] radeon :02:00.0: GPU lockup (waiting for
0x002b last fence id 0x002a)
[16273.882550] plugin-containe[11435]: segfault
On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote:
What chip is this?
I think it is RV635. Here's the whole 3.8-rc1 dmesg.
[0.00] Linux version 3.8.0-rc1 (boris@liondog) (gcc version 4.7.2
(Debian 4.7.2-4) ) #13 SMP PREEMPT Sat Dec 22 11:48:54 CET 2012
[0.00] Command
On Sat, Dec 22, 2012 at 7:25 PM, Borislav Petkov b...@alien8.de wrote:
On Sat, Dec 22, 2012 at 07:01:31PM -0500, Alex Deucher wrote:
What chip is this?
I think it is RV635. Here's the whole 3.8-rc1 dmesg.
Does booting with radeon.wb=0 help?
Alex
78 matches
Mail list logo
