- Without this change I get a general protection fault.
- Also use PTR_ERR where applicable.
Signed-off-by: Maarten Maathuis
---
drivers/gpu/drm/ttm/ttm_tt.c | 18 +++---
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/
http://bugs.freedesktop.org/show_bug.cgi?id=26641
--- Comment #8 from Tobias Jakobi 2010-02-19 16:13:09
PST ---
I'm really at a loss here.
Just went back several weeks in git history with xf86-video-ati, libdrm and
mesa and the problem still happens.
Furthermore I noticed that it's not on
http://bugzilla.kernel.org/show_bug.cgi?id=15284
--- Comment #8 from Johannes Hirte
2010-02-20 00:35:48 ---
seems to be fixed in the xf86-video-ati driver in commit
a3b730eceb522c7ac1ef3dd6f6c7d773118d03f7
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- Yo
http://bugzilla.kernel.org/show_bug.cgi?id=15328
--- Comment #20 from Tobias Jakobi 2010-02-20 00:03:17
---
No, nothing - doesn't have any effect on performance. Must be something else.
I'm still wondering though since I already went back several weeks in git with
xf86-video-ati, libdrm and
http://bugzilla.kernel.org/show_bug.cgi?id=15328
--- Comment #19 from Tobias Jakobi 2010-02-19 23:49:06
---
I just went back to commit db78e27de7e2 and reverted then - I'm now building
that tree. Reporting back once I've done some tests.
--
Configure bugmail: http://bugzilla.kernel.org/us
This patch enable the use of unmappable VRAM thanks to
previous TTM infrastructure change.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |5 -
drivers/gpu/drm/radeon/r100.c |5 -
drivers/gpu/drm/radeon/r600.c |5 -
drivers/gpu/drm/radeon/rv
This isn't needed anymore with the new TTM fault callback
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_ttm.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index b8
This isn't needed anymore with the new TTM fault callback
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index c
On fault the driver is given the opportunity to perform any operation
it sees fit in order to place the buffer into a CPU visible area of
memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon
should keep working properly. Future patch will take advantage of this
infrastructure and
All TTM driver have been converted to new io_mem_reserve/free
interface which allow driver to choose and return proper io
base, offset to core TTM for ioremapping if necessary. This
patch remove what is now deadcode.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/ttm/ttm_bo.c | 22 -
This patchset add a new infrastructure to deal with memory mapping,
with the new interface the driver is responsible for providing io
address at which a buffer is accessible. This would be usefull for
separate aperture configuration but also for future hw which likely
have more advanced feature whe
This add the support for the new fault callback, does change anything
from driver point of view, thought it should allow nouveau to add
support for unmappable VRAM.
Improvement: store the aperture base in a variable so that we don't
call a function to get it on each fault.
Patch hasn't been teste
This isn't needed anymore with the new TTM fault callback
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 0
This add the support for the new fault callback and also the
infrastructure for supporting unmappable VRAM.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_ttm.c | 99 ++-
1 files changed, 98 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu
This add the support for the new fault callback, does change anything
from driver point of view.
Improvement: store the aperture base in a variable so that we don't
call a function to get it on each fault.
Patch hasn't been tested.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/vmwgfx/vmwgfx
http://bugzilla.kernel.org/show_bug.cgi?id=15328
--- Comment #18 from Francisco Jerez 2010-02-19
23:44:25 ---
(In reply to comment #17)
> I get an error with git when trying to revert the commit, so I just tried the
> two patches.
You'll need to revert f0e2f38befa7 first.
--
Configure bu
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #8 from Tobias Jakobi 2010-02-19 15:38:00
PST ---
Created an attachment (id=33441)
--> (http://bugs.freedesktop.org/attachment.cgi?id=33441)
xorg log when output works
--
Configure bugmail: http://bugs.freedesktop.org/userpre
http://bugzilla.kernel.org/show_bug.cgi?id=15328
--- Comment #17 from Tobias Jakobi 2010-02-19 23:36:50
---
I get an error with git when trying to revert the commit, so I just tried the
two patches.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are r
> Hi Linus
>
> hope you get this before release, if not stable life, the main fix is a
> major regression on AGP/no-pat systems where pages ended up in uncached,
>
> a further fix to the vgaarb fix, and a fix to make rv740 gpus just work
> for now (they have some tile/backend quirk that AMD haven't
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #7 from Alex Deucher 2010-02-19 15:20:14 PST ---
(In reply to comment #6)
> OK, tests done.
>
> First of all: All other 1024x768 modes except the 85Hz one work, it's just
> this
> single one that makes the signal go weird
>
> D
http://bugs.freedesktop.org/show_bug.cgi?id=26641
--- Comment #7 from Tobias Jakobi 2010-02-19 14:52:29
PST ---
Already wrote that on kernel.org, but it looks like that my problem is not
really related to the DRM since it also happens when KMS is disabled.
Probably some change in mesa or l
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #6 from Tobias Jakobi 2010-02-19 14:49:58
PST ---
OK, tests done.
First of all: All other 1024x768 modes except the 85Hz one work, it's just this
single one that makes the signal go weird
Disabling new_pll -> no change at all
D
http://bugzilla.kernel.org/show_bug.cgi?id=15328
--- Comment #16 from Francisco Jerez 2010-02-19
22:49:18 ---
(In reply to comment #15)
> I'm experiencing similar problems on my RV740 which is hooked up through the
> PCIe.
>
> I first noticed the issue when updating drm-radeon-testing and
http://bugs.freedesktop.org/show_bug.cgi?id=26641
--- Comment #6 from Tobias Jakobi 2010-02-19 14:40:54
PST ---
Same card model as Martin here (and PCIe also) and also hitting this bug.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving th
http://bugzilla.kernel.org/show_bug.cgi?id=15328
Tobias Jakobi changed:
What|Removed |Added
CC||liquid.a...@gmx.net
--- Comment #15 fr
http://bugzilla.kernel.org/show_bug.cgi?id=15166
Manuel Ullmann changed:
What|Removed |Added
Kernel Version|2.6.33-rc7, 2.6.32.8|2.6.33-rc8, 2.6.32.8
--- Comment #28
Hi Linus
hope you get this before release, if not stable life, the main fix is a
major regression on AGP/no-pat systems where pages ended up in uncached,
a further fix to the vgaarb fix, and a fix to make rv740 gpus just work
for now (they have some tile/backend quirk that AMD haven't tracked
http://bugs.freedesktop.org/show_bug.cgi?id=26641
Michał Ostrowski changed:
What|Removed |Added
CC||nemr...@gmail.com
--- Comment #5 f
http://bugs.freedesktop.org/show_bug.cgi?id=22017
Andrey Gusev changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugzilla.kernel.org/show_bug.cgi?id=15328
--- Comment #14 from John W. Linville 2010-02-19
18:47:23 ---
The patch from comment 13 is acceptable, but my "seat of the pants" feeling is
that the first patch performed better. FWIW the load average seemed 20-30%
lower with the first patc
On Fri, Feb 19, 2010 at 04:51:29PM +0200, Panagiotis Papadakos wrote:
> Hi. I am posting a warning I got from todays git...
> Should I open a new bug?
>
> Τhis is on a Mobility X2300
>
We have a patch queued to fix this issue.
Cheers,
Jerome
>
> [ 212.042277] [ cut here ]--
http://bugzilla.kernel.org/show_bug.cgi?id=15328
Francisco Jerez changed:
What|Removed |Added
Attachment #25107|0 |1
is obsolete|
http://bugzilla.kernel.org/show_bug.cgi?id=15166
--- Comment #27 from Alex Deucher 2010-02-19 16:27:17
---
(In reply to comment #24)
> Bug persists in 2.6.33-rc8. However there is a new kms-driver. But according
> to
> help, support for R6xx-7xx is not finished yet. Additionally it´s based
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #5 from Alex Deucher 2010-02-19 08:18:16 PST ---
(In reply to comment #4)
> Would it help to check the 1024x768 mode with the other refresh rates?
>
for thoroughness, but if they do have problems, it's likely the same issue as
t
Hi. I am posting a warning I got from todays git...
Should I open a new bug?
Τhis is on a Mobility X2300
[ 212.042277] [ cut here ]
[ 212.042317] WARNING: at /home/kernel-
ppa/mainline/build/drivers/gpu/drm/radeon/radeon_fence.c:159
radeon_fence_signaled+0xb3/0xd0 [r
http://bugzilla.kernel.org/show_bug.cgi?id=15328
--- Comment #12 from John W. Linville 2010-02-19
15:00:57 ---
Yup, that looks good...thanks!
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the
http://bugzilla.kernel.org/show_bug.cgi?id=15166
Manuel Ullmann changed:
What|Removed |Added
Attachment #24956|0 |1
is obsolete|
http://bugzilla.kernel.org/show_bug.cgi?id=15166
Manuel Ullmann changed:
What|Removed |Added
Attachment #24956|0 |1
is obsolete|
http://bugzilla.kernel.org/show_bug.cgi?id=15166
--- Comment #24 from Manuel Ullmann 2010-02-19 14:46:53
---
Created an attachment (id=25115)
--> (http://bugzilla.kernel.org/attachment.cgi?id=25115)
kernel 2.6.33-rc8 configuration file
Bug persists in 2.6.33-rc8. However there is a new km
http://bugzilla.kernel.org/show_bug.cgi?id=15276
--- Comment #35 from Panagiotis Papadakos 2010-02-19
14:36:30 ---
Aa user has posted a backtrace using 2.6.32 in the phoronix post about this
problem.
See http://www.phoronix.com/forums/showpost.php?p=113530&postcount=9
--
Configure bugmai
This patch properly set visible VRAM and enforce any pinned buffer
to be into visible VRAM. We might later add a flag to release this
constraint for some newer hw more clever than previous.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/evergreen.c |1 +
drivers/gpu/drm/radeon/r
On Fri, Feb 19, 2010 at 12:15:35PM +0100, Martin PERES wrote:
> Le 19/02/2010 07:54, Alex Deucher a écrit :
> > > From e69022ade813cb26d64719d7a402459ddfc401b3 Mon Sep 17 00:00:00 2001
> > From: Alex Deucher
> > Date: Fri, 19 Feb 2010 01:51:55 -0500
> > Subject: [PATCH] drm/radeon: fixes for r6xx/r
http://bugzilla.kernel.org/show_bug.cgi?id=15328
--- Comment #11 from John W. Linville 2010-02-19
14:23:30 ---
Sorry for the delay...
CONFIG_X86_PAT=y
Building w/ patch from comment 9 now.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving
On Fri, 2010-02-19 at 08:52 +0100, Marco wrote:
> > Please provide the full Xorg.0.log file.
> Here it is (in the meantime I recompiled drm 2.4.18, but non vmwgfx 3D
> again)
Hmm. I guess most likely vmw_drm_create_screen() fails, but I'm not sure
why. Can you try finding out with a debugger or by
Le 19/02/2010 07:54, Alex Deucher a écrit :
> > From e69022ade813cb26d64719d7a402459ddfc401b3 Mon Sep 17 00:00:00 2001
> From: Alex Deucher
> Date: Fri, 19 Feb 2010 01:51:55 -0500
> Subject: [PATCH] drm/radeon: fixes for r6xx/r7xx gfx init
>
> - RV740 requires a special backend map
> - updated swiz
http://bugs.freedesktop.org/show_bug.cgi?id=26639
--- Comment #4 from Tobias Jakobi 2010-02-19 02:11:49
PST ---
Yeah, sorry about that. I was talking about the 85hz refresh rate one, I mostly
use 85hz refresh when it's available.
Going to test the new_pll parameters this evening and probab
> Please provide the full Xorg.0.log file.
Here it is (in the meantime I recompiled drm 2.4.18, but non vmwgfx 3D
again)
Marco
Xorg.0.log
Description: Binary data
--
Download Intel® Parallel Studio Eval
Try the new softw
47 matches
Mail list logo
