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 las
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.
--
Regards
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 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 delibe
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 t
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
&
; 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
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 engi
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: Borislav Petkov
C
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
> Signed-off-by
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
eon 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 :
http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-
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 :
> >> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6x
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
>> 2d6cc7296d4ee128
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 affected people can you tes
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 :
http://people.f
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 :
>>> http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6x
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 t
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 i
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 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: ATI Technologies In
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 unless
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 loads just f
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 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.
>
> --
> Regards/Gru
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.
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, 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 "ra
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 D
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 yo
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 enabl
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 - so
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 no_console_suspen
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
--
To unsubscribe from this list: send the line "unsubsc
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
now if 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)
> [16
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 0000:02:00.0: GPU lockup CP stall for
39 matches
Mail list logo
