http://bugs.freedesktop.org/show_bug.cgi?id=22396
Gordon Jin changed:
What|Removed |Added
CC||kui.zh...@intel.com
AssignedTo|dri-
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 correspondin
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
Signed-off-by: Jerome Glisse
---
include/drm/drm_edid.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index c263e4d..83ea6c9 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -51,7 +51,7 @@ struct std_ti
2009/6/22 Linus Torvalds :
>
>
> 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 h
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 driver
http://bugs.freedesktop.org/show_bug.cgi?id=22405
Shuang He changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #2 from Shuang He
http://bugs.freedesktop.org/show_bug.cgi?id=21864
Mathias Fröhlich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
On Tue, 23 Jun 2009 11:04:39 +1000
Benjamin Herrenschmidt 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 semaphore.
> >
> >
On Tue, 23 Jun 2009 11:58:44 +1000
Benjamin Herrenschmidt 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. That way we don't
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 consol
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 Sun, 2009-06-21 at 12:47 -0700, Linus Torvalds 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 assigns a _virtua
On Mon, 2009-06-22 at 10:18 +0200, 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.
As far as I can remember, all fbdev operations are done under the
console semaph
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
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 whil
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 in
> > 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
> >
>
> Hi,
>
>
(cc dri-devel)
On Sun, 14 Jun 2009 21:46:05 -0400
Sanjoy Mahajan 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 that it
> of
http://bugs.freedesktop.org/show_bug.cgi?id=14094
--- Comment #10 from Brian Paul 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 7.4.4
release.
--
Configure
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
> Date: Thu Jun 11 16:16:10 2009 +1000
>
> radeon: remove _DRM
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Alex Bennee changed:
What|Removed |Added
CC||p...@gentoo.org
--- Comment #4 from Ale
http://bugs.freedesktop.org/show_bug.cgi?id=22398
Alexey Shildyakov changed:
What|Removed |Added
Summary|Googleearth crashes and |Googleearth crashes
http://bugs.freedesktop.org/show_bug.cgi?id=22398
--- Comment #3 from Alexey Shildyakov 2009-06-22
13:33:15 PST ---
[20530.798871] [drm:r300_do_cp_cmdbuf] *ERROR* r300_scratch failed
[20530.836211] googleearth-bin used greatest stack depth: 3160 bytes left
--
Configure bugmail: http://bu
http://bugs.freedesktop.org/show_bug.cgi?id=22377
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Brian Paul changed:
What|Removed |Added
CC||daiml...@gmail.com
--- Comment #3 from B
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=22385
--- Comment #6 from Michel Dänzer 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
to be from Git maste
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 useles
http://bugs.freedesktop.org/show_bug.cgi?id=22398
--- Comment #2 from Michel Dänzer 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 were removed from
http://bugs.freedesktop.org/show_bug.cgi?id=20607
--- Comment #17 from Michel Dänzer 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 bugmail: http://bu
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
> > > Date: Sat Jun 6 09:46:01 200
http://bugs.freedesktop.org/show_bug.cgi?id=19504
Bernd Buschinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
We don't need to allocated contiguous pages in cs codepath
so use vmalloc instead.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_cs.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/d
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
---
drivers/gpu/drm/radeon/radeon
TTM need to be initialized before radeon if KMS is enabled otherwise
the kernel will crash hard.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/Makefile|2 +-
drivers/gpu/drm/radeon/radeon_drv.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/g
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
http://bugs.freedesktop.org/show_bug.cgi?id=22405
Eric Anholt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugs.freedesktop.org/show_bug.cgi?id=22398
--- Comment #1 from Alexey Shildyakov 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/userprefs.
http://bugs.freedesktop.org/show_bug.cgi?id=21791
--- Comment #16 from Alexey Shildyakov 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 are receiving this mail
http://bugs.freedesktop.org/show_bug.cgi?id=22313
Alexey Shildyakov changed:
What|Removed |Added
Resolution|FIXED |DUPLICATE
--- Comment #3 from Ale
http://bugs.freedesktop.org/show_bug.cgi?id=22313
Alexey Shildyakov changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #2 from Alexey
http://bugs.freedesktop.org/show_bug.cgi?id=21791
--- Comment #15 from Alexey Shildyakov 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 this mail because: --
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:
> >
> > dd26899ca39111e0
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 dd26899ca39111
> >
> 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 spa
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Alex Bennee changed:
What|Removed |Added
CC||bugzi...@bennee.com
--- Comment #1 from
Remove unused #include ('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
---
drivers/gpu/drm/ttm/ttm_bo_util.c |1 -
drivers/gpu/drm/ttm/ttm_bo_vm.c |1 -
drivers/gpu/drm/ttm/ttm_tt.c |1 -
3
On Sun, Jun 21, 2009 at 5:14 PM, Andrew Lutomirski wrote:
> On Sun, Jun 21, 2009 at 3:47 PM, Linus
> Torvalds 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
On Sun, Jun 21, 2009 at 1:16 AM, Dave Airlie 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 the
>> c
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, S
size_t is (some sort of) int on x86-32 and long on x86-64, correct
format specifiers.
Signed-off-by: Krzysztof Halasa
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
+++ b/drivers/gpu/drm/i915/i91
Randy Dunlap 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!
Portland, OR, June 17-19.
On Sun, Jun 21, 2009 at 3:47 PM, Linus
Torvalds 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 assigns a _virtual_ addr
http://bugs.freedesktop.org/show_bug.cgi?id=14094
Alex Bennee changed:
What|Removed |Added
CC||bugzi...@bennee.com
--- Comment #9 from
http://bugs.freedesktop.org/show_bug.cgi?id=22408
Alex Bennee changed:
What|Removed |Added
OS/Version|All |Linux (All)
Platform|Other
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
Seve
58 matches
Mail list logo
