http://bugs.freedesktop.org/show_bug.cgi?id=22408
Summary: intel_renderbuffer_set_region crashes when sent NULL as
region
Product: Mesa
Version: unspecified
Platform: Other
OS/Version: All
Status: NEW
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Alex Bennee bugzi...@bennee.com changed:
What|Removed |Added
OS/Version|All |Linux (All)
http://bugs.freedesktop.org/show_bug.cgi?id=14094
Alex Bennee bugzi...@bennee.com changed:
What|Removed |Added
CC||bugzi...@bennee.com
On Sun, Jun 21, 2009 at 3:47 PM, Linus
Torvaldstorva...@linux-foundation.org wrote:
What *has* changed is that we have a newradeon driver, and it looks like
that new radeon driver is crap, and does this:
info-fix.smem_start = (unsigned long)fbptr;
which is totally screwed up. It
Randy Dunlap randy.dun...@oracle.com writes:
I.e., using %zd or %zu is the preferred fix.
Good to know, thanks.
--
Krzysztof Halasa
--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Marcel Holtmann wrote:
Hi Krzysztof,
size_t is (some sort of) int on x86-32 and long on x86-64, eliminate
compiler warnings by casting to long.
just using %zd or %zu would do the same trick and avoid stupid casts.
I.e., using %zd or %zu is the preferred fix.
--
~Randy
LPC 2009, Sept.
size_t is (some sort of) int on x86-32 and long on x86-64, correct
format specifiers.
Signed-off-by: Krzysztof Halasa k...@pm.waw.pl
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 39f5c65..cdaa8b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++
On Sun, Jun 21, 2009 at 1:16 AM, Dave Airlieairl...@linux.ie wrote:
I tried this tree (specifically, a merge of Linus' fb20871 this tree) on
Fedora 11 with modesetting enabled on an integrated Radeon 2100, and
plymouthd
crashes immediately with a corrupt page table. Photo attached. After
Remove unused #include linux/version.h('s) in
drivers/gpu/drm/ttm/ttm_bo_util.c
drivers/gpu/drm/ttm/ttm_bo_vm.c
drivers/gpu/drm/ttm/ttm_tt.c
Signed-off-by: Huang Weiyi weiyi.hu...@gmail.com
---
drivers/gpu/drm/ttm/ttm_bo_util.c |1 -
drivers/gpu/drm/ttm/ttm_bo_vm.c |1 -
On Sun, Jun 21, 2009 at 5:14 PM, Andrew Lutomirskil...@mit.edu wrote:
On Sun, Jun 21, 2009 at 3:47 PM, Linus
Torvaldstorva...@linux-foundation.org wrote:
What *has* changed is that we have a newradeon driver, and it looks like
that new radeon driver is crap, and does this:
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Alex Bennee bugzi...@bennee.com changed:
What|Removed |Added
CC||bugzi...@bennee.com
There is a ttm_fbdev_mmap() function in TTM that may help in this situation.
As with the standard ttm mmap it's using fault() which means it's possible to
move out the backing buffer object if you first reserve it and then call
unmap_mapping_range() on the relevant fbdev address space to
On Sun, 2009-06-21 at 10:30 -0700, Eric Anholt wrote:
I was checking on some driver regressions this weekend, and thought that
readpixels failure on i915 might have been my fault, but bisect claims
it's:
dd26899ca39111e0866afed9df94bfb1618dd363 is first bad commit
commit
On Mon, 2009-06-22 at 13:48 +0200, Michel Dänzer wrote:
On Sun, 2009-06-21 at 10:30 -0700, Eric Anholt wrote:
I was checking on some driver regressions this weekend, and thought that
readpixels failure on i915 might have been my fault, but bisect claims
it's:
http://bugs.freedesktop.org/show_bug.cgi?id=21791
--- Comment #15 from Alexey Shildyakov ashl1fut...@gmail.com 2009-06-22
08:04:21 PST ---
With current mesa_7_4_branch this error isn't be.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
http://bugs.freedesktop.org/show_bug.cgi?id=22313
Alexey Shildyakov ashl1fut...@gmail.com changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
---
http://bugs.freedesktop.org/show_bug.cgi?id=22313
Alexey Shildyakov ashl1fut...@gmail.com changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
http://bugs.freedesktop.org/show_bug.cgi?id=21791
--- Comment #16 from Alexey Shildyakov ashl1fut...@gmail.com 2009-06-22
08:17:11 PST ---
*** Bug 22313 has been marked as a duplicate of this bug. ***
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You
http://bugs.freedesktop.org/show_bug.cgi?id=22398
--- Comment #1 from Alexey Shildyakov ashl1fut...@gmail.com 2009-06-22
08:19:02 PST ---
I update mesa to Git mesa_7_4_branch.
Firstly Googleearth run fine.
But then googleearth crash with that error.
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=22405
Eric Anholt e...@anholt.net changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, 2009-06-22 at 14:40 +0200, Michel Dänzer wrote:
On Mon, 2009-06-22 at 13:48 +0200, Michel Dänzer wrote:
On Sun, 2009-06-21 at 10:30 -0700, Eric Anholt wrote:
I was checking on some driver regressions this weekend, and thought that
readpixels failure on i915 might have been my
TTM need to be initialized before radeon if KMS is enabled otherwise
the kernel will crash hard.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/Makefile|2 +-
drivers/gpu/drm/radeon/radeon_drv.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
smem.start is a physical address which kernel can remap to access
video memory of the fb buffer. We now pin the fb buffer into vram
by doing so we are loosing vram but fbdev need to be reworked to
allow change in framebuffer address.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Brian Paul brian.p...@tungstengraphics.com changed:
What|Removed |Added
Status|NEW |RESOLVED
We don't need to allocated contiguous pages in cs codepath
so use vmalloc instead.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_cs.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git
http://bugs.freedesktop.org/show_bug.cgi?id=19504
Bernd Buschinski b.buschin...@web.de changed:
What|Removed |Added
Status|NEW |RESOLVED
On Sun, 2009-06-21 at 22:24 +0100, Chris Wilson wrote:
On Sun, 2009-06-21 at 17:47 +0300, Maxim Levitsky wrote:
52dc7d32b88156248167864f77a9026abe27b432 is first bad commit
commit 52dc7d32b88156248167864f77a9026abe27b432
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Sat Jun 6
http://bugs.freedesktop.org/show_bug.cgi?id=20607
--- Comment #17 from Michel Dänzer mic...@daenzer.net 2009-06-22 11:10:07
PST ---
(In reply to comment #16)
mesa-libGL-7.5-0.14.fc11.x86_64
I assume Fedora 11 ships some variant of the radeon-rewrite branch, see bug
21864.
--
Configure
http://bugs.freedesktop.org/show_bug.cgi?id=22398
--- Comment #2 from Michel Dänzer mic...@daenzer.net 2009-06-22 11:21:56 PST
---
I have Gentoo Linux amd64 (x86_64).
media-libs/mesa-7.5_rc3
libGL warning: 3D driver claims to not support visual 0x68
Those warnings
On Mon, 22 Jun 2009, Thomas Hellström wrote:
It would be very helpful if we could introduce an fbdev mutex that protects
fbdev accesses to the kernel map and to the fbdev acceleration functions.
Not going to happen.
Why? 'printk'.
If you can't handle printk, then you're basically useless.
http://bugs.freedesktop.org/show_bug.cgi?id=22385
--- Comment #6 from Michel Dänzer mic...@daenzer.net 2009-06-22 11:34:26 PST
---
If it only happens with indirect rendering, probably your X server or 3D driver
is missing support for version 2 of the DRI_TexBuffer extension. xserver needs
On Mon, 22 Jun 2009, Andrew Lutomirski wrote:
What if we only guaranteed that the framebuffer is mapped when it's
showing on the screen?
I think that works ok. We only care about printk being immediate in that
case, and if it gets buffered I don't think we care.
printk doesn't need to
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Brian Paul brian.p...@tungstengraphics.com changed:
What|Removed |Added
CC|
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Alex Bennee bugzi...@bennee.com changed:
What|Removed |Added
CC||p...@gentoo.org
---
Dave Airlie wrote:
Hi Linus,
Please pull the 'drm-linus' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
commit df4f7fe7bd516b3833e25c692c3970e22038a6ca
Author: Dave Airlie airl...@redhat.com
Date: Thu Jun 11 16:16:10 2009 +1000
radeon:
http://bugs.freedesktop.org/show_bug.cgi?id=14094
--- Comment #10 from Brian Paul brian.p...@tungstengraphics.com 2009-06-22
14:52:27 PST ---
Mesa commit 1dbbc39f48ce5f9aa63ab42930b14e48938b326f from today (22 June) fixes
the crash in in intel_renderbuffer_set_region(). This will be in the
(cc dri-devel)
On Sun, 14 Jun 2009 21:46:05 -0400
Sanjoy Mahajan san...@mit.edu wrote:
I'm running vanilla 2.6.30 on an otherwise Debian 'unstable' system -- a
TP T60 with Intel graphics and wireless (no tainting). The X server
[xorg 1.6.1.901 (1.6.2 RC 1), intel driver 2.7.1] hung in a way
Date: Thu Jun 11 16:16:10 2009 +1000
radeon: remove _DRM_DRIVER from the preadded sarea map
This shouldn't be there and is what broke r600 late in the 2.6.30
release cycle with Ben's patch.
Signed-off-by: Dave Airlie airl...@redhat.com
Hi,
I
On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote:
As far as I can remember, all fbdev operations are done under the
console semaphore.
Yeah, and some of them are horribly broken (ie copying data from user
space while doing it - causing horrible things like VC switching latencies
and
On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote:
On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote:
As far as I can remember, all fbdev operations are done under the
console semaphore.
Yeah, and some of them are horribly broken (ie copying data from user
space while doing it
On Mon, 2009-06-22 at 11:22 -0700, Linus Torvalds wrote:
Not going to happen.
Why? 'printk'.
If you can't handle printk, then you're basically useless. And printk
absolutely -has- to work in bad situations (the most important
messages could happen in any context).
Well... yes and no. If
On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote:
I think it could work, but ideally we'd keep the kernel fbcon object
pinned, and keep printing into it even while some other gfx app is
running. That way we don't have to dump the whole queue into it when
a
panic occurs, we can just
On Mon, 2009-06-22 at 19:07 -0700, Jesse Barnes wrote:
Yeah I don't think we should try to change the mode, unless we really
have to for whatever reason. fbcon should generally be able to paint
to whatever we have up as long as we set it up properly.
Well... it may not. IE. The text consoles
On Tue, 23 Jun 2009 11:58:44 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote:
I think it could work, but ideally we'd keep the kernel fbcon object
pinned, and keep printing into it even while some other gfx app is
running.
On Tue, 23 Jun 2009 11:04:39 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote:
On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote:
As far as I can remember, all fbdev operations are done under the
console
http://bugs.freedesktop.org/show_bug.cgi?id=21864
Mathias Fröhlich mathias.froehl...@web.de changed:
What|Removed |Added
Status|NEW |RESOLVED
http://bugs.freedesktop.org/show_bug.cgi?id=22405
Shuang He shuang...@intel.com changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment
Hello,
I'm using xorg-edgers' packages on Ubuntu Jaunty, so I have equivalent
of mesa 7.5 from git (intel 945GM), up to date.
Recently (but unfortunately I can't tell exactly when), some of my own
OpenGL programs using VBOs and glMapBuffer broke. I'm not sure if it's a
bug of the intel DRI
Em Sun, Jun 21, 2009 at 08:05:36PM -0400, Andrew Lutomirski escreveu:
David -- there are still plenty of bugs. The kernel gets my monitor's
resolution wrong (X reads it off DDC correctly but I have to use
xrandr to force the resolution).
No crashes here, but I was able to use an external
Jerome Glisse wrote:
smem.start is a physical address which kernel can remap to access
video memory of the fb buffer. We now pin the fb buffer into vram
by doing so we are loosing vram but fbdev need to be reworked to
allow change in framebuffer address.
I tested this (and the corresponding
50 matches
Mail list logo
