http://bugzilla.kernel.org/show_bug.cgi?id=13683
--- Comment #23 from Jan Kreuzer kontrolla...@gmx.de 2009-11-20 08:37:49 ---
Still the same with latest git. Is it possible that the bios lies about the
connectors ? When i used the real old non-kms, non-xrandr radeon driver i had
to specify
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #2 from Fabio fabio@libero.it 2009-11-20 00:59:13 PST ---
(In reply to comment #1)
Sounds like you are building against an old version of libdrm_radeon. To
update build libdrm configured with
http://bugs.freedesktop.org/show_bug.cgi?id=25179
--- Comment #2 from Fabio fabio@libero.it 2009-11-20 01:09:36 PST ---
Does it work without that fix for the 7.6 branch?
No, with a clean clone of 7.7 branch it asserts in a similar way to bug #24131
(see below). Apparently the Leaking
http://bugs.freedesktop.org/show_bug.cgi?id=25197
Summary: [REGRESSION] openarena: vbo/vbo_exec_api.c:881:
vbo_exec_FlushVertices: Assertion `callDepth == 1'
failed.
Product: Mesa
Version: unspecified
Platform:
http://bugs.freedesktop.org/show_bug.cgi?id=25197
--- Comment #1 from Rafał Miłecki zaj...@gmail.com 2009-11-20 03:15:26 PST
---
Created an attachment (id=31335)
-- (http://bugs.freedesktop.org/attachment.cgi?id=31335)
openarena.log
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=25198
Summary: [R6XX] : System hard hangs on launching OpenGL
application
Product: Mesa
Version: git
Platform: x86 (IA32)
OS/Version: other
Status: NEW
http://bugs.freedesktop.org/show_bug.cgi?id=25198
--- Comment #1 from samit vats hysv...@gmail.com 2009-11-20 03:41:48 PST ---
Created an attachment (id=31337)
-- (http://bugs.freedesktop.org/attachment.cgi?id=31337)
Xorg.log
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=25198
--- Comment #2 from samit vats hysv...@gmail.com 2009-11-20 03:42:14 PST ---
Created an attachment (id=31338)
-- (http://bugs.freedesktop.org/attachment.cgi?id=31338)
xorg.conf
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=25198
--- Comment #3 from samit vats hysv...@gmail.com 2009-11-20 03:42:55 PST ---
Created an attachment (id=31339)
-- (http://bugs.freedesktop.org/attachment.cgi?id=31339)
lspci
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=25198
--- Comment #4 from samit vats hysv...@gmail.com 2009-11-20 03:43:29 PST ---
Created an attachment (id=31340)
-- (http://bugs.freedesktop.org/attachment.cgi?id=31340)
glxgears-log
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=25197
Maciej Cencora m.cenc...@gmail.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
---
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #3 from Ed Tomlinson e...@aei.ca 2009-11-20 04:04:24 PST ---
This turns out not to be the case. As stated in the initial report libdrm is
from git. My log shows the correct api enabled:
Emerging (1 of 1) x11-libs/libdrm-
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #1 from Allen Walker walkerallen...@googlemail.com 2009-11-20
04:51:46 PST ---
Created an attachment (id=31341)
-- (http://bugs.freedesktop.org/attachment.cgi?id=31341)
short xorg session with touhou 11 running
I compiled
Hi,
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation:
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
[...]
if (var-pixclock == -1 ||
Add a function to validate buffer in a given range of
memory. This is needed by some hw for some of their
buffer (scanout buffer, cursor ...).
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c| 305 ++-
This patch series add ttm range validation function. Aim is to
include this in 2.6.33 so i have time to iron out issue, comments.
ttm:
I duplicated a bunch of ttm functions but now i think, best would
be to add range to all function and use free list if range cover
all the manager space. Doing so
We force the crtc cursor bo to be in the first 64M, this
will help on legacy modesetting hw where the offset of
scanout buffer and cursor are relative to a base address.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h |3 ++
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #2 from Allen Walker walkerallen...@googlemail.com 2009-11-20
05:59:50 PST ---
ok, got oprofile running and it shows me:
$ oprofile | head
Overflow stats not available
CPU: AMD64 processors, speed 1607.55 MHz (estimated)
Counted
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #3 from Allen Walker walkerallen...@googlemail.com 2009-11-20
06:06:50 PST ---
better results:
$ opreport -l /usr/lib/xorg/modules/dri/r300_dri.so | head
Overflow stats not available
CPU: AMD64 processors, speed 1607.55 MHz
http://bugs.freedesktop.org/show_bug.cgi?id=22851
Fabio fabio@libero.it changed:
What|Removed |Added
Summary|radeon_lock.c:65: |[bisected] radeon_lock.c:65:
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #4 from Fabio fabio@libero.it 2009-11-20 06:15:57 PST ---
Could you try running:
LIBGL_DEBUG=verbose glxgears
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
Add a function to validate buffer in a given range of
memory. This is needed by some hw for some of their
buffer (scanout buffer, cursor ...).
V2: A fix were missing in the first version, only update
node-private if we are actualy dealing with a node.
Signed-off-by: Jerome Glisse
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #5 from Florian Scandella f...@chilicode.com 2009-11-20 06:42:33
PST ---
same thing here ...
~ $ LIBGL_DEBUG=verbose glxgears
libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so
libGL: OpenDriver: trying
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #4 from Roland Scheidegger srol...@tungstengraphics.com
2009-11-20 06:51:38 PST ---
(In reply to comment #3)
samples %symbol name
633992 98.0560 radeon_ptr_4byte
11532 1.7836 radeonReadRGBASpan_ARGB
This
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #5 from Allen Walker walkerallen...@googlemail.com 2009-11-20
07:10:40 PST ---
(In reply to comment #4)
(In reply to comment #3)
samples %symbol name
633992 98.0560 radeon_ptr_4byte
11532 1.7836
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #6 from Alex Deucher ag...@yahoo.com 2009-11-20 07:40:29 PST ---
(In reply to comment #2)
To avoid this problem current libdrm should be tagged as 2.4.16 and mesa
should
require libdrm_radeon = 2.4.16.
That will be done
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #7 from Alex Deucher ag...@yahoo.com 2009-11-20 07:41:22 PST ---
(In reply to comment #5)
same thing here ...
~ $ LIBGL_DEBUG=verbose glxgears
libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so
libGL: OpenDriver:
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #8 from Florian Scandella f...@chilicode.com 2009-11-20 07:54:18
PST ---
hmm.. thats strange, a new clone fixed the problems ... didn't get any changes
with pull.
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #6 from Maciej Cencora m.cenc...@gmail.com 2009-11-20 08:06:21
PST ---
Please try my r300-blit branch.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
On Fri, Nov 20, 2009 at 5:45 AM, Viktor Malyarchuk mal...@gmail.com wrote:
Dear David,
thank you and all the developers involved for your outstanding DRM/KMS work.
There is a problem that was introduced in 2.6.32-rc6-git5.
SUMMARY
any mode switch on MacBookPro2,2 is delayed by 130 seconds
http://bugs.freedesktop.org/show_bug.cgi?id=25198
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://bugs.freedesktop.org/show_bug.cgi?id=25193
Alex Deucher ag...@yahoo.com changed:
What|Removed |Added
Status|NEW |RESOLVED
On Fri, Nov 20, 2009 at 8:29 AM, Jerome Glisse jgli...@redhat.com wrote:
We force the crtc cursor bo to be in the first 64M, this
will help on legacy modesetting hw where the offset of
scanout buffer and cursor are relative to a base address.
This limitation only applies to pre-avivo
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation: ...
patch:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
P.S. check CLCOK spelling :)
This patch got lost
On Fri, Nov 20, 2009 at 11:47:22AM -0500, Alex Deucher wrote:
On Fri, Nov 20, 2009 at 8:29 AM, Jerome Glisse jgli...@redhat.com wrote:
We force the crtc cursor bo to be in the first 64M, this
will help on legacy modesetting hw where the offset of
scanout buffer and cursor are relative to a
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation: ...
patch:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
Those patches will enable fbdev apps to run
On Fri, 20 Nov 2009 18:53:37 + (GMT)
James Simmons jsimm...@infradead.org wrote:
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation: ...
patch:
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to
change
video mode, because of different var-pixclock evaluation: ...
patch:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html
Those patches will
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #7 from Allen Walker walkerallen...@googlemail.com 2009-11-20
12:09:22 PST ---
(In reply to comment #6)
Please try my r300-blit branch.
Was half success, failed half. My problem is that I can only get indirect
rendering working
On Fri, 20 Nov 2009, Paulius Zaleckas wrote:
On 11/20/2009 10:01 PM, James Simmons wrote:
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to
change
video mode, because of different var-pixclock evaluation: ...
http://bugs.freedesktop.org/show_bug.cgi?id=21501
--- Comment #5 from rem11_1...@yahoo.fr 2009-11-20 13:02:23 PST ---
Tested with mesa branch master from now (after branch 7.7 was merged in) and
same error message :
scourge: radeon_texture.c:875: migrate_image_to_miptree: Assertion
http://bugs.freedesktop.org/show_bug.cgi?id=25142
--- Comment #8 from Allen Walker walkerallen...@googlemail.com 2009-11-20
13:15:56 PST ---
Created an attachment (id=31351)
-- (http://bugs.freedesktop.org/attachment.cgi?id=31351)
ingame garbled
--
Configure bugmail:
2009/11/19 Eric Anholt e...@anholt.net:
On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote:
2009/11/6 Kristian Høgsberg k...@bitplanet.net:
Hi,
This has come up a few time and it's something I think makes a lot of
sense. Since all driver development (afaik) now happens in linux
Hello Thomas:
I know this kernel module is made for VIAs own X.org driver and not
openchrome but:
1. I don't think userspace should be able to easily trigger a kernel oops,
and
2. Can't this new VIA Chrome9 DRM interface be made more compatible to the
existing one? Ideally it would
http://bugzilla.kernel.org/show_bug.cgi?id=13683
--- Comment #24 from Alex Deucher alexdeuc...@gmail.com 2009-11-20 23:41:49
---
(In reply to comment #23)
Still the same with latest git. Is it possible that the bios lies about the
connectors ?
It's possible, but not likely. The bios
http://bugs.freedesktop.org/show_bug.cgi?id=25193
Ed Tomlinson e...@aei.ca changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://bugs.freedesktop.org/show_bug.cgi?id=25193
--- Comment #10 from Ed Tomlinson e...@aei.ca 2009-11-20 16:48:13 PST ---
Just to confirm, reverting 286bf89e5a1fc931dbf523ded861b809859485e2 fixes the
corruption here.
--
Configure bugmail:
On Sat, Nov 21, 2009 at 6:48 AM, James Simmons jsimm...@infradead.org wrote:
On Fri, 20 Nov 2009, Paulius Zaleckas wrote:
On 11/20/2009 10:01 PM, James Simmons wrote:
Paulius Zaleckas wrote:
On drivers using drm_fb_helper's in fb_ops it is not possible to
change
On Fri, Nov 20, 2009 at 11:16 PM, Paulius Zaleckas
paulius.zalec...@gmail.com wrote:
Hi,
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation:
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
49 matches
Mail list logo
