Hi
I try to compile 2.6.32-rc5-git3 with enabled CONFIG_DRM_I915_KMS, but got
black screen on boot. After short investigation, i notice that i915.modeset=0
is fine for me.
Here is what i got with modeset=1
[1.053570] [drm] Initialized drm 1.1.0 20060810
[1.063552] [drm] set up 7M of sto
http://bugs.freedesktop.org/show_bug.cgi?id=24734
Jesus Rodriguez changed:
What|Removed |Added
CC||faibis...@gmail.com
--- Comment #2
http://bugs.freedesktop.org/show_bug.cgi?id=24734
--- Comment #3 from Chris Wilson 2009-10-27
02:36:18 PST ---
Indeed, looks like a compilation/distribution issue. If you are only using
packaged components, please raise the issue with your packagers.
--
Configure bugmail: http://bugs.fre
http://bugs.freedesktop.org/show_bug.cgi?id=16692
--- Comment #5 from Fabio 2009-10-27 03:02:55 PST ---
This appears to be fixed since mesa 7.6 at least on my RV530. Can someone
confirm it?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
http://bugs.freedesktop.org/show_bug.cgi?id=16692
--- Comment #6 from Alexey Kuznetsov 2009-10-27 03:03:53 PST ---
ya. f12 x1600 done
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the
http://bugs.freedesktop.org/show_bug.cgi?id=24734
Tormod Volden changed:
What|Removed |Added
CC||bugzi07.fdo.tor...@xoxy.net
--- Comme
http://bugs.freedesktop.org/show_bug.cgi?id=24734
--- Comment #6 from Roland Scheidegger
2009-10-27 06:44:21 PST ---
Created an attachment (id=30741)
--> (http://bugs.freedesktop.org/attachment.cgi?id=30741)
possible fix
Looks like this function was also used in the i830/i915 texstate, as
http://bugs.freedesktop.org/show_bug.cgi?id=24734
--- Comment #5 from Tormod Volden 2009-10-27
06:33:38 PST ---
$ grep -r intel_miptree_image_offset src/mesa/drivers/dri
src/mesa/drivers/dri/i915/i830_texstate.c:
intel_miptree_image_offset(intelObj->mt, 0, intelObj->firstLevel, 0);
http://bugs.freedesktop.org/show_bug.cgi?id=24761
Summary: Text corruption in Unreal Tournament 2004 under KMS
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
Severity: normal
http://bugs.freedesktop.org/show_bug.cgi?id=24761
--- Comment #1 from had...@gmx.de 2009-10-27 08:59:56 PST ---
Created an attachment (id=30752)
--> (http://bugs.freedesktop.org/attachment.cgi?id=30752)
Xorg.0.log
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
-
http://bugs.freedesktop.org/show_bug.cgi?id=24761
--- Comment #2 from had...@gmx.de 2009-10-27 09:01:19 PST ---
Created an attachment (id=30753)
--> (http://bugs.freedesktop.org/attachment.cgi?id=30753)
A screenshot showing the corruption
--
Configure bugmail: http://bugs.freedesktop.org/
http://bugs.freedesktop.org/show_bug.cgi?id=24761
--- Comment #3 from had...@gmx.de 2009-10-27 09:05:12 PST ---
Created an attachment (id=30754)
--> (http://bugs.freedesktop.org/attachment.cgi?id=30754)
another screenshot
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab
http://bugs.freedesktop.org/show_bug.cgi?id=24761
had...@gmx.de changed:
What|Removed |Added
Attachment #30753|0 |1
is obsolete|
A couple of small modesetting fixes.
Alex
From 84248ff437864aab1d0d3aba971aa4d32c248526 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Tue, 27 Oct 2009 11:16:09 -0400
Subject: [PATCH] drm/radeon/kms/atom: loosen pll min output limits
Limiting the pll output range is a good thing generally as
http://bugs.freedesktop.org/show_bug.cgi?id=24734
Ian Romanick changed:
What|Removed |Added
AssignedTo|dri-|e...@anholt.net
|de...@
>From 89f132ea7ebe3b513835a1a975e4524caa26c691 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Mathias=20Fr=C3=B6hlich?=
Date: Tue, 27 Oct 2009 15:08:01 -0400
Subject: [PATCH] drm/radeon/kms/atom: Make card_info per device
Make the struct card_info, which is a per struct radeon_device dataset, a
struct
On Thu, 8 Oct 2009, Dave Airlie wrote:
>
> Please pull the 'drm-linus' branch from
> ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus
>
> Its had a recent merge because it was definitely getting non-trivial to
> fixup,
>
> non-radeon-kms: adds proper fb layer col
> I don't think you tested this very extensively.
>
> I'm bisecting a bug where my new Dell Inspiron 11z has corrupted LUT or
> gamma tables or something. And while I have a lot of commits left to go,
> only two of them still touch the i915 driver. And the two commits are:
Ive got a fix already
For those of you having issues with the spread spectrum patch, this
patch should fix it up. If not, we should probably get rid the ss
patch until it's gotten some more testing.
Alex
From 4a5d68c399f950bd603e7af752ac7eb430ee1d19 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Tue, 27 Oct 2009 1
I believe this is a typo.
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9c92461..dc8e374 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -707,7 +707,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
http://bugs.freedesktop.org/show_bug.cgi?id=24643
--- Comment #4 from Paul Heldens 2009-10-27 14:33:56 PST
---
fwiw r600 git doesn't work either, it lacks GL_ARB_occlusion_query at detection
time
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are re
Hi!
This patch takes a little explaining. After the cleaned up of the fbdev
api a few years back I realized the fbdev api had many short comings. One
of them was the mapping of 1 to 1 for the framebuffer to display. So I
started to move that way gradually. What ended up was a new struct
fb_
http://bugzilla.kernel.org/show_bug.cgi?id=14331
--- Comment #9 from Alex Villacis Lasso
2009-10-28 00:49:41 ---
Still present in 2.6.32-rc5.
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the
So for drm KMS we wrote a bunch of ioctls that were 64-bit clean in theory.
They used uint64_t to represent userspace pointers and userspace
casted into those and the kernel casts back out and passes it to copy_*_user
Now I thought cool I don't need to worry about compat ioctl hackery I can
run 3
Hi Linus,
Please pull the 'drm-fixes' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes
This is just 3 fast track fixes, one for the colormap issues with 1.7 and
2.9.0 intel driver (note final 1.7 + 2.9.1 is fine, and 1.6 is fine with
any Intel). The oth
From: Dave Airlie
Date: Wed, 28 Oct 2009 11:22:18 +1000
> Is there really no way to avoid compat ioctls? was I delusional in
> thinking there was?
If you use pointers in your interfaces in any way, no.
And for this drm_radeon_info thing the pointer is "pointless",
you're just returning 32-bit v
On Wed, Oct 28, 2009 at 12:25 PM, David Miller wrote:
> From: Dave Airlie
> Date: Wed, 28 Oct 2009 11:22:18 +1000
>
>> Is there really no way to avoid compat ioctls? was I delusional in
>> thinking there was?
>
> If you use pointers in your interfaces in any way, no.
>
> And for this drm_radeon_i
On Wed, Oct 28, 2009 at 12:53 PM, Andi Kleen wrote:
> Dave Airlie writes:
>
>> They used uint64_t to represent userspace pointers and userspace
>> casted into those and the kernel casts back out and passes it to copy_*_user
>
> uint64_t is actually dangerous due to different alignment on x86-32 v
Dave Airlie writes:
> They used uint64_t to represent userspace pointers and userspace
> casted into those and the kernel casts back out and passes it to copy_*_user
uint64_t is actually dangerous due to different alignment on x86-32 vs 64,
better use compat_u64/s64
> Now I thought cool I don't
On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
> We've designed that into a/c also, we pad all 64-bit values to 64-bit
> alignment on all the
> ioctls we've added to the drm in the past couple of years. Just because of
> this particular insanity.
That's actually not needed, just use
On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen wrote:
> On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
>> We've designed that into a/c also, we pad all 64-bit values to 64-bit
>> alignment on all the
>> ioctls we've added to the drm in the past couple of years. Just because of
>> this p
On Wed, Oct 28, 2009 at 01:28:10PM +1000, Dave Airlie wrote:
> You mean its impossible to design a 32/64-bit safe ioctl no matter what?
Not impossible, but there's always a rate of mistakes.
> and we should live with having compat ioctls? This isn't something that was
> very
> clearly stated or
From: Andi Kleen
Date: Wed, 28 Oct 2009 03:53:17 +0100
> Dave Airlie writes:
>
>> Now I thought cool I don't need to worry about compat ioctl hackery I can
>> run 32 on 64 bit apps fine and it'll all just work.
>>
>> Now Dave Miller points out that I'm obivously deluded and we really need
>> to
From: Dave Airlie
Date: Wed, 28 Oct 2009 13:05:08 +1000
> DrNick on irc suggested just doing:
> if (is_compat_task()) ptr &= 0x;
>
> Is there a one liner I can just do in the actual ioctls instead of
> adding 20 compat
> ones?
Just do the right thing and pass all userland compat
From: Dave Airlie
Date: Wed, 28 Oct 2009 13:28:10 +1000
> On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen wrote:
>> On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote:
>>> We've designed that into a/c also, we pad all 64-bit values to 64-bit
>>> alignment on all the
>>> ioctls we've added t
From: Andi Kleen
Date: Wed, 28 Oct 2009 04:34:55 +0100
> On Wed, Oct 28, 2009 at 01:28:10PM +1000, Dave Airlie wrote:
>> Well this was what I was trying to gather, so maybe I just need to write
>> something up to state that compat_ioctl is always required for new ioctls
>> that pass pointers or 6
>
> > DrNick on irc suggested just doing:
> > if (is_compat_task()) ptr &= 0x;
> >
> > Is there a one liner I can just do in the actual ioctls instead of
> > adding 20 compat
> > ones?
>
> Just do the right thing and pass all userland compat pointers
> through the correct compat_
From: Dave Airlie
Date: Wed, 28 Oct 2009 03:43:07 + (GMT)
> we already opencoded this (probably before it was macroisied or we just
> pasted it), so the radeon one is buggy, I should just go and compat_* all
> of these then and we should be all happy?
It should be, it's only working becaus
On Tue, Oct 27, 2009 at 08:45:30PM -0700, David Miller wrote:
> From: Dave Airlie
> Date: Wed, 28 Oct 2009 03:43:07 + (GMT)
>
> > we already opencoded this (probably before it was macroisied or we just
> > pasted it), so the radeon one is buggy, I should just go and compat_* all
> > of thes
>
> > we already opencoded this (probably before it was macroisied or we just
> > pasted it), so the radeon one is buggy, I should just go and compat_* all
> > of these then and we should be all happy?
>
> It should be, it's only working because:
>
> 1) A malicious userland hasn't put garbage
On Tue, Oct 27, 2009 at 08:37:09PM -0700, David Miller wrote:
> On sparc64, in order to make debugging easier, we trap any time
> the kernel does a userspace access to a compat task and any
> of the upper 32-bits are non-zero.
Interesting. That definitely means Dave needs a special path.
> > Howe
Looks like the issue was actually a potential oops. New patch attached.
Alex
On Tue, Oct 27, 2009 at 4:44 PM, Alex Deucher wrote:
> For those of you having issues with the spread spectrum patch, this
> patch should fix it up. If not, we should probably get rid the ss
> patch until it's gotten
From: Dave Airlie
Date: Wed, 28 Oct 2009 03:54:34 + (GMT)
>>
>> > we already opencoded this (probably before it was macroisied or we just
>> > pasted it), so the radeon one is buggy, I should just go and compat_* all
>> > of these then and we should be all happy?
>>
>> It should be, it's
From: Andi Kleen
Date: Wed, 28 Oct 2009 05:36:11 +0100
> On Tue, Oct 27, 2009 at 08:37:09PM -0700, David Miller wrote:
>> On sparc64, in order to make debugging easier, we trap any time
>> the kernel does a userspace access to a compat task and any
>> of the upper 32-bits are non-zero.
>
> Inter
> Please don't do this.
>
> This is exactly what I feared people would do when is_compat_task()
> was added. is_compat_task() is for situations where there is
> otherwise no other way to handle the compat situation properly.
>
> It's not that much work for you to hook up the compat ioctls prope
>From d8a247c57fddc2dc01b41320988c25aa5dfcb0d7 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Wed, 28 Oct 2009 01:46:54 -0400
Subject: [PATCH] drm/radeon/kms: add quirk for hp dc5750
Doesn't have a tv-out port
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_combios.c |6 ++
From: Dave Airlie
Date: Wed, 28 Oct 2009 05:42:27 + (GMT)
> I'll add this to my TODO for before the next merge window as its
> definitely more than I can manage now.
I'll do it.
--
Come build with us! The BlackBerry
47 matches
Mail list logo