[PATCH] drm/radeon/kms: fix cayman acceleration

[Alex Deucher]

The TCC disable setup was incorrect.  This
prevents the GPU from hanging when draw commands
are issued.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/ni.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index e9e45ea..3d8a763 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -674,7 +674,7 @@ static void cayman_gpu_init(struct radeon_device *rdev)

cc_rb_backend_disable = RREG32(CC_RB_BACKEND_DISABLE);
cc_gc_shader_pipe_config = RREG32(CC_GC_SHADER_PIPE_CONFIG);
-   cgts_tcc_disable = RREG32(CGTS_TCC_DISABLE);
+   cgts_tcc_disable = 0xff00;
gc_user_rb_backend_disable = RREG32(GC_USER_RB_BACKEND_DISABLE);
gc_user_shader_pipe_config = RREG32(GC_USER_SHADER_PIPE_CONFIG);
cgts_user_tcc_disable = RREG32(CGTS_USER_TCC_DISABLE);
-- 
1.7.1.1

[Bug 36939] multitexturing is messed up in quake wars (regression)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36939

--- Comment #3 from Tom Stellard  2011-05-09 22:11:23 
PDT ---
Created an attachment (id=46516)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46516
 Review: https://bugs.freedesktop.org/review?bug=36939=46516

Verbose patch

This patch will give me some more verbose output, could you apply it to master
and post the output with RADEON_DEBUG=fp

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 34252] Unexpected behaviour when switching video cards with vga_switcheroo

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34252





--- Comment #5 from Igor Murzov   2011-05-09 21:56:04 ---
Created an attachment (id=57042)
 --> (https://bugzilla.kernel.org/attachment.cgi?id=57042)
dmesg output

This is a full dmesg output after sending IGD to vgaswitcheroo/switch.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 34252] Unexpected behaviour when switching video cards with vga_switcheroo

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34252





--- Comment #4 from Igor Murzov   2011-05-09 21:53:21 ---
@Florian Mickler:

System is not frozen, only screen is black, because active graphical card gets
turned off. I can log into the system via ssh and turn graphics on.

If I do `echo IGD > /sys/kernel/debug/vgaswitcheroo/switch` just after system
boot, I get following new lines in dmesg:

[ 1230.530299] fbcon: Remapping primary device, fb0, to tty 1-63
[ 1230.570734] radeon: switched off
[ 1230.591094] [drm] Disabling audio support
[ 1230.718090] radeon :01:05.0: PCI INT A disabled

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

long delay when using HMDI output on RS780

[Thomas Fjellstrom]

On May 9, 2011, Thomas Fjellstrom wrote:
> On May 9, 2011, Alex Deucher wrote:
> > On Mon, May 9, 2011 at 5:04 PM, Thomas Fjellstrom 
> 
> wrote:
> > > On May 9, 2011, Thomas Fjellstrom wrote:
> > >> On May 9, 2011, Jerome Glisse wrote:
> > >> > On Mon, May 9, 2011 at 3:50 PM, Thomas Fjellstrom
> > >> > 
> > >> 
> > >> wrote:
> > >> > > On May 7, 2011, Thomas Fjellstrom wrote:
> > >> > >> I just switched to using HDMI with my media center, and its
> > >> > >> causing a 30+ second delay in the screen turning on, as well as
> > >> > >> a 7 second delay in the X startup when it tries to fetch the
> > >> > >> EDID
> > >> > >> information. Basically I don't get any picture at all once KMS
> > >> > >> initializes until after X has been up a few seconds.
> > >> > >> 
> > >> > >> The odd thing is the monitor seems to think something is going
> > >> > >> on, since it doesn't go to sleep or display its "No Signal" OSD,
> > >> > >> but just after X starts up, it pops up the "Input
> > >> > >> detected/switched" OSD, and the picture appears.
> > >> > >> 
> > >> > >> The bios, grub2 (in both text mode and graphics mode), and the
> > >> > >> initial linux kernel messages all display fine and immediately.
> > >> > >> Its only once KMS and radeondrmfb initializes that there's a
> > >> > >> problem (at least till X starts up).
> > >> > >> 
> > >> > >> I've just built with a vanila 2.6.38.4 kernel from the stable git
> > >> > >> repo, and have played with some EDID settings, trying to disable
> > >> > >> edid where I could thinking thats what caused the problem. That
> > >> > >> doesn't seem to be the case though. I also tried playing with the
> > >> > >> video= kernel option, trying to force disable VGA-1, and set a
> > >> > >> static mode for HDMI-A-1, but if I try, it seems to force disable
> > >> > >> HDMI-A-1 instead of force the mode.
> > >> > >> 
> > >> > >> With a DVI-D cable instead, the problem goes away.
> > >> > >> 
> > >> > >> Attached are the dmesg and xorg.log files for the latest boot
> > >> > >> with HDMI (no video= parameter, and EDID enabled, most settings
> > >> > >> at defaults).
> > >> > >> 
> > >> > >> What exactly would cause this, and is there a way I can fix it?
> > >> > > 
> > >> > > I've been playing around with it more, and got it to not blank the
> > >> > > screen after KMS init, /once/. So far no luck repeating that
> > >> > > success.
> > >> > > 
> > >> > > I've tried late, and early kms init, and currently have the radeon
> > >> > > module and firmware compiled into the kernel. Boot times at least
> > >> > > are fairly decent, about 8-10s till X starts, but about 25-35s
> > >> > > till anything shows up.
> > >> > > 
> > >> > > Some strangeness, I have the kernel set to force the hdmi output
> > >> > > to on, with a very specific mode, that X tends to like, the vga
> > >> > > port is forced disabled. X is set to ignore EDID, and also set to
> > >> > > that specific mode that it tends to auto set itself. Regardless X
> > >> > > still wants to pause for 7s 2-3 times while processing EDID info.
> > >> > > 
> > >> > > I've attached the new dmesg and xorg logs from the latest
> > >> > > attempts.
> > >> > > 
> > >> > > Note, this only happens with KMS, with HDMI. disabling KMS, or
> > >> > > using DVI makes the problem go away. Even grub's own graphical
> > >> > > mode works fine, its only once KMS inits that things go bad, and
> > >> > > its not till after X is up for a few seconds that something
> > >> > > displays on my screen.
> > >> > > 
> > >> > > --
> > >> > > Thomas Fjellstrom
> > >> > > thomas at fjellstrom.ca
> > >> > 
> > >> > Please boot with drm.debug=4 and attach dmesg it should be more
> > >> > verbose. You might also want to try booting with radeon.audio=0
> > >> 
> > >> Hi, attached both one with just drm.debug=4, and one with that and
> > >> radeon.audio=0.
> > >> 
> > >> Now, I'm guessing its a bug in my monitor claiming it can do HDMI
> > >> audio? As setting radeon.audio=0 seems to have fixed the blanking
> > >> problem. And the dmesg logs seem to claim that radeon thinks it can
> > >> do HDMI audio.
> > 
> > Most likely the driver is sending the wrong packets for hdmi audio.
> > Until that gets fixed up, it's probably best to disable hdmi audio if
> > it's not working for you.
> 
> Ok. I'll do that for now, since I have no need for HDMI audio atm. My
> receiver is only capable of Dolby Pro Logic input, so eh.
> 
> Would be nice to fix the xorg pauses. And whatever is causing the massive
> amounts of drm log spam (yes, I could disable drm.debug, but that would
> just hide the issue, as whatever it is, will keep doing whatever it is
> doing regardless).

Any hints on where to look to fix the stalls when the xorg radeon driver starts 
up?

> > Alex
> > 
> > >> It also seems to be ignoring the mode I've requested via the video=
> > >> param. It at least sees that I want it forced enabled, but claims its
> > >> 0x0? Or at least it seems its picking the preferred mode.
> > >> 
> > 

[Bug 37040] Radeon driver reports EDID errors every 10 seconds

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37040

--- Comment #3 from Alex Deucher  2011-05-09 21:16:48 PDT 
---
drm_kms_helper.poll=0 will disable the output polling

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 37040] Radeon driver reports EDID errors every 10 seconds

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37040

--- Comment #2 from Alex Deucher  2011-05-09 21:15:52 PDT 
---
RS690 did not support displayport.  I'm not sure how you have one on your
board.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 37040] Radeon driver reports EDID errors every 10 seconds

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37040

Alex Deucher  changed:

   What|Removed |Added

  Attachment #46512|application/octet-stream|text/plain
  mime type||
  Attachment #46512|0   |1
   is patch||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 37040] Radeon driver reports EDID errors every 10 seconds

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37040

--- Comment #1 from teufel at cs.uni-frankfurt.de 2011-05-09 20:38:14 PDT ---
Argh, bad typo:
(it was the same with Linux 2.6.32-5-amd64 (2.6.32-31))
should have been:
(it was the same with Linux 2.6.38-2-amd64 (2.6.38-3))

What I wanted to say: It doesn't matter if the 2.6.38 from wheezy or the
backported 2.6.38 is used, but that may be obvious.

I'm really sorry for that bad copy mistake.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 34252] Unexpected behaviour when switching video cards with vga_switcheroo

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34252





--- Comment #3 from Florian Mickler   2011-05-09 
19:18:48 ---
Do you have a guess, why this is happening (for example, any error messages
from the kernel) ? Can you login via ssh when the system freezes with a black
screen? Do you think the system completely froze, or are, for example, the
sysrq-keys still working? Is there anything in the dmesg that gives a clue? If
there is nothing in the logs, can you try netconsole?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[bug] drmfb does not set physical screen dimensions

[Roger Leigh]

Hi,

drivers/gpu/drm/drm_fb_helper.c is not setting width and height
in struct fb_var_screeninfo.  drm_fb_helper_fill_var sets them to -1
rather than using the real values:
info->var.height = -1;
info->var.width = -1;

Since the physical dimensions are most likely known from the monitor
EDID, it would be ideal if this could be set here.  If not, it might
be nice to assume a default of 96dpi and compute the size based upon
the current resolution (so applications don't need to implement
fallbacks when unset).  On my hardware the radeon driver certainly
does have this information.

This information is needed in order to do accurate font rendering and
drawing.  It's available in X, and it would be great if it was also
available using the framebuffer.

I've also attached a small patch to fbset to allow reporting of the
current state in fb_var_screeninfo such as resolution, size, depth etc.
Could be extended to report more info if desired.
I'm not entirely sure who is best to submit this to, so my apologies
if this is not you.

I've included the dri and fbdev lists because I'm not sure if it's
specific to the drmfb code or the generic framebuffer code.  Likewise
if you set a default 96dpi size, I'm not sure if it's a generic issue
or specific to drmfb.


Thanks,
Roger


diff -urN /tmp/fbset-2.1/fbset.c ./fbset.c
--- /tmp/fbset-2.1/fbset.c  2011-05-09 18:47:47.0 +0100
+++ ./fbset.c   2011-05-09 18:46:32.142945642 +0100
@@ -281,7 +281,8 @@
 static struct VideoMode *FindVideoMode(const char *name);
 static void ModifyVideoMode(struct VideoMode *vmode);
 static void DisplayVModeInfo(struct VideoMode *vmode);
-static void DisplayFBInfo(struct fb_fix_screeninfo *fix);
+static void DisplayFBInfo(struct fb_fix_screeninfo *fix,
+ struct fb_var_screeninfo *var);
 static int FillScanRates(struct VideoMode *vmode);
 static void Usage(void) __attribute__ ((noreturn));
 int main(int argc, char *argv[]);
@@ -758,7 +759,8 @@
  *  Display the Frame Buffer Device Information
  */

-static void DisplayFBInfo(struct fb_fix_screeninfo *fix)
+static void DisplayFBInfo(struct fb_fix_screeninfo *fix,
+ struct fb_var_screeninfo *var)
 {
 int i;

@@ -845,6 +847,16 @@
puts(Accelerators[i].name);
 else
printf("Unknown (%d)\n", fix->accel);
+
+printf("Dimensions  : %dx%d pixels", var->xres, var->yres);
+if (var->width != -1 && var->height != -1)
+  printf(" (%dx%d mm)", var->width, var->height);
+putc('\n', stdout);
+printf("Virtual : %dx%d pixels\n", var->xres_virtual, 
var->yres_virtual);
+printf("Offset  : %dx%d pixels\n", var->xoffset, var->yoffset);
+printf("Bits/Pixel  : %d\n", var->bits_per_pixel);
+if (var->grayscale)
+  printf("Graylevels  : %d\n", var->grayscale);
 }


@@ -1101,7 +1113,7 @@
if (Opt_verbose)
puts("Getting further frame buffer information");
GetFixScreenInfo(fh, );
-   DisplayFBInfo();
+   DisplayFBInfo(, );
 }

 /*

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110509/79e6ddd8/attachment-0001.pgp>

[Bug 34102] radeon drm/kms: please use suspend/hibernate notifiers for allocating memory in suspend routines

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34102


Rafael J. Wysocki  changed:

   What|Removed |Added

 Status|NEEDINFO|ASSIGNED




--- Comment #12 from Rafael J. Wysocki   2011-05-09 19:06:31 ---
It looks like the amount of memory the graphics driver allocates during
hibernation depends on how the GPU is loaded (the more 3D stuff you do before
hibernation, the more memory it needs to allocate).

So, I'd say reserved_size should match not only your hardware configuration,
but also your workload.

I'll try to post the patch from comment #3 for review, let's see if people
will like it. :-)

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

i915/kms/backlight-combo mode problem

[Michael Chang]

[Bug 37047] New: [RADEON:KMS:R600G] broadbandmap.gov crashes firefox/iceweasel when webgl is enabled

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37047

   Summary: [RADEON:KMS:R600G] broadbandmap.gov crashes
firefox/iceweasel when webgl is enabled
   Product: Mesa
   Version: git
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: bpaterni at gmail.com


broadbandmap.gov does appear to be making use of webgl if it is exposed.
Running iceweasel in debug mode produces the following:

Mesa: User error: GL_INVALID_ENUM in
glGetIntegerv(pname=GL_MAX_VERTEX_OUTPUT_COMPONENTS)
Mesa: User error: GL_INVALID_ENUM in
glGetIntegerv(pname=GL_MAX_VERTEX_OUTPUT_COMPONENTS)
[New Thread 0x7fffbf7ff700 (LWP 25412)]
[New Thread 0x7fffbeffe700 (LWP 25413)]
Mesa: User error: GL_INVALID_ENUM in
glGetIntegerv(pname=GL_MAX_VERTEX_OUTPUT_COMPONENTS)

Program received signal SIGSEGV, Segmentation fault.
0x7fffc17be5df in dri2FlushFrontBuffer (driDrawable=0x7fffc51bb420,
loaderPrivate=0x7fffc2cb7cc0) at dri2_glx.c:460
460   struct glx_display *priv = __glXInitialize(pdraw->base.psc->dpy);
(gdb) bt
#0  0x7fffc17be5df in dri2FlushFrontBuffer (driDrawable=0x7fffc51bb420,
loaderPrivate=0x7fffc2cb7cc0) at dri2_glx.c:460
#1  0x7fffc03bd400 in dri_st_framebuffer_flush_front (stfbi=, statt=) at dri_drawable.c:104
#2  0x7fffc03bca34 in dri_unbind_context (cPriv=) at
dri_context.c:152
#3  0x7fffc039f676 in driUnbindContext (pcp=0x7fffc4b31640) at
../../../../src/mesa/drivers/dri/common/dri_util.c:117
#4  0x7fffc17be089 in dri2_unbind_context (context=0x7fffc4859a20,
new=0x7fffd1d93840) at dri2_glx.c:172
#5  0x7fffc1795c05 in MakeContextCurrent (dpy=0x76d76000,
draw=25168521, read=25168521, gc_user=0x7fffd1d93840) at glxcurrent.c:258
#6  0x756a9b17 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#7  0x756a8fd1 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#8  0x756a9159 in
mozilla::gl::GLContextProviderGLX::CreateOffscreen(gfxIntSize const&,
mozilla::gl::ContextFormat const&) () from /usr/lib/xulrunner-2.0/libxul.so
#9  0x74fe525e in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#10 0x7502b1af in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#11 0x7502b6ba in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#12 0x75361e78 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#13 0x7666e9eb in ?? () from /usr/lib/xulrunner-2.0/libmozjs.so
#14 0x76677fc5 in ?? () from /usr/lib/xulrunner-2.0/libmozjs.so
#15 0x76679b05 in ?? () from /usr/lib/xulrunner-2.0/libmozjs.so
#16 0x765f2584 in JS_EvaluateUCScriptForPrincipalsVersion () from
/usr/lib/xulrunner-2.0/libmozjs.so
#17 0x750d954e in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#18 0x74fbbc2b in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#19 0x74fbc684 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#20 0x74fbd72b in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#21 0x74fbda54 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#22 0x74d43733 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#23 0x75640a8b in NS_InvokeByIndex_P () from
/usr/lib/xulrunner-2.0/libxul.so
#24 0x7531e216 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#25 0x75323402 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#26 0x7666e9eb in ?? () from /usr/lib/xulrunner-2.0/libmozjs.so
#27 0x76677fc5 in ?? () from /usr/lib/xulrunner-2.0/libmozjs.so
#28 0x76678462 in ?? () from /usr/lib/xulrunner-2.0/libmozjs.so
#29 0x76679313 in ?? () from /usr/lib/xulrunner-2.0/libmozjs.so
#30 0x765f2011 in JS_CallFunctionValue () from
/usr/lib/xulrunner-2.0/libmozjs.so
#31 0x753190f5 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#32 0x75314aa1 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#33 0x75641625 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#34 0x75640b13 in ?? () from /usr/lib/xulrunner-2.0/libxul.so
#35 0x7fffc70a6720 in ?? ()
#36 0x7fffc1c7c850 in ?? ()
#37 0x7fffc6da9ce0 in ?? ()
#38 0x in ?? ()

System Info
Debian unstable/experimental running distro provided Linux 2.6.39-rc5-amd64
iceweasel version: 4.0.1-2
libdrm, xf86-video-ati @ git
OpenGL renderer string: Gallium 0.4 on AMD RV770
OpenGL version string: 2.1 Mesa 7.11-devel (git-9d792d0)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

long delay when using HMDI output on RS780

[Alex Deucher]

On Mon, May 9, 2011 at 5:04 PM, Thomas Fjellstrom  
wrote:
> On May 9, 2011, Thomas Fjellstrom wrote:
>> On May 9, 2011, Jerome Glisse wrote:
>> > On Mon, May 9, 2011 at 3:50 PM, Thomas Fjellstrom 
>>
>> wrote:
>> > > On May 7, 2011, Thomas Fjellstrom wrote:
>> > >> I just switched to using HDMI with my media center, and its causing a
>> > >> 30+ second delay in the screen turning on, as well as a 7 second delay
>> > >> in the X startup when it tries to fetch the EDID information.
>> > >> Basically I don't get any picture at all once KMS initializes until
>> > >> after X has been up a few seconds.
>> > >>
>> > >> The odd thing is the monitor seems to think something is going on,
>> > >> since it doesn't go to sleep or display its "No Signal" OSD, but just
>> > >> after X starts up, it pops up the "Input detected/switched" OSD, and
>> > >> the picture appears.
>> > >>
>> > >> The bios, grub2 (in both text mode and graphics mode), and the initial
>> > >> linux kernel messages all display fine and immediately. Its only once
>> > >> KMS and radeondrmfb initializes that there's a problem (at least till
>> > >> X starts up).
>> > >>
>> > >> I've just built with a vanila 2.6.38.4 kernel from the stable git
>> > >> repo, and have played with some EDID settings, trying to disable edid
>> > >> where I could thinking thats what caused the problem. That doesn't
>> > >> seem to be the case though. I also tried playing with the video=
>> > >> kernel option, trying to force disable VGA-1, and set a static mode
>> > >> for HDMI-A-1, but if I try, it seems to force disable HDMI-A-1
>> > >> instead of force the mode.
>> > >>
>> > >> With a DVI-D cable instead, the problem goes away.
>> > >>
>> > >> Attached are the dmesg and xorg.log files for the latest boot with
>> > >> HDMI (no video= parameter, and EDID enabled, most settings at
>> > >> defaults).
>> > >>
>> > >> What exactly would cause this, and is there a way I can fix it?
>> > >
>> > > I've been playing around with it more, and got it to not blank the
>> > > screen after KMS init, /once/. So far no luck repeating that success.
>> > >
>> > > I've tried late, and early kms init, and currently have the radeon
>> > > module and firmware compiled into the kernel. Boot times at least are
>> > > fairly decent, about 8-10s till X starts, but about 25-35s till
>> > > anything shows up.
>> > >
>> > > Some strangeness, I have the kernel set to force the hdmi output to on,
>> > > with a very specific mode, that X tends to like, the vga port is forced
>> > > disabled. X is set to ignore EDID, and also set to that specific mode
>> > > that it tends to auto set itself. Regardless X still wants to pause for
>> > > 7s 2-3 times while processing EDID info.
>> > >
>> > > I've attached the new dmesg and xorg logs from the latest attempts.
>> > >
>> > > Note, this only happens with KMS, with HDMI. disabling KMS, or using
>> > > DVI makes the problem go away. Even grub's own graphical mode works
>> > > fine, its only once KMS inits that things go bad, and its not till
>> > > after X is up for a few seconds that something displays on my screen.
>> > >
>> > > --
>> > > Thomas Fjellstrom
>> > > thomas at fjellstrom.ca
>> >
>> > Please boot with drm.debug=4 and attach dmesg it should be more
>> > verbose. You might also want to try booting with radeon.audio=0
>>
>> Hi, attached both one with just drm.debug=4, and one with that and
>> radeon.audio=0.
>>
>> Now, I'm guessing its a bug in my monitor claiming it can do HDMI audio? As
>> setting radeon.audio=0 seems to have fixed the blanking problem. And the
>> dmesg logs seem to claim that radeon thinks it can do HDMI audio.

Most likely the driver is sending the wrong packets for hdmi audio.
Until that gets fixed up, it's probably best to disable hdmi audio if
it's not working for you.

Alex


>>
>> It also seems to be ignoring the mode I've requested via the video= param.
>> It at least sees that I want it forced enabled, but claims its 0x0? Or at
>> least it seems its picking the preferred mode.
>>
>> Still have X blocking for up to 14s though.
>>
>> Theres also a bunch of repeated log messages from drm now, every second
>> about it seems to spam the following lines: (the last one is repeated a
>> bunch of times, with FB:44 or FB:42)
>>
>> [ ? 31.330033] [drm:output_poll_execute], [CONNECTOR:13:VGA-1] status
>> updated from 2 to 2
>> [ ? 31.435455] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected
>> [ ? 31.435463] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status
>> updated from 1 to 1
>> [ ? 31.437391] [drm:drm_mode_addfb], [FB:42]
>>
>> > Cheers,
>> > Jerome
>
> Ok, a bit more news. My monitor does indeed support audio, at least it has
> volume buttons, so I assume it has speakers, and should support HDMI audio (I
> have never used it though).
>
> --
> Thomas Fjellstrom
> thomas at fjellstrom.ca
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> 

[PULL] drm intel fixes

[Keith Packard]

Here are a few very small changes for Intel mode setting.

They should fix the following bugs:

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456
References: https://bugs.freedesktop.org/show_bug.cgi?id=36246

The following changes since commit 0ee5623f9a6e52df90a78bd21179f8ab370e102e:

  Linux 2.6.39-rc6 (2011-05-03 19:59:13 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git 
drm-intel-fixes

Alex Williamson (1):
  drm/i915/lvds: Only act on lid notify when the device is on

Chris Wilson (4):
  drm/i915: Release object along create user fb error path
  drm/i915/dp: Be paranoid in case we disable a DP before it is attached
  drm/i915: Only enable the plane after setting the fb base (pre-ILK)
  drm/i915: fix intel_crtc_clock_get pipe reads after "cleanup cleanup"

 drivers/gpu/drm/i915/intel_display.c |   10 +-
 drivers/gpu/drm/i915/intel_dp.c  |   17 +++--
 drivers/gpu/drm/i915/intel_lvds.c|3 +++
 3 files changed, 23 insertions(+), 7 deletions(-)

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110509/02a40ef3/attachment-0001.pgp>

[PATCH] drm/radeon/nouveau: fix build regression on alpha due to Xen changes.

[Konrad Rzeszutek Wilk]

On Mon, May 09, 2011 at 12:24:04PM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> The Xen changes were using DMA_ERROR_CODE which isn't defined on a few
> platforms, however we reverted the Xen patch that caused use to try and
> use this code path earlier in 2.6.39 cycle, so for now lets just force
> the code to never take this path and allow it to build again on alpha.
> 
> The proper long term answer is probably to store if the dma_addr has
> been assigned to alongside the dma_addr in the higher level code,
> though I think Thomas wanted to rewrite most of this anyways properly.

 Yes, just need to find the time :-)
> 
> Signed-off-by: Dave Airlie 
> Cc: Konrad Rzeszutek Wilk 

Acked-by: Konrad Rzeszutek Wilk 

Thanks for sending this patch out!

> ---
>  drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++-
>  drivers/gpu/drm/radeon/radeon_gart.c|6 +++---
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c 
> b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> index 4bce801..c77111e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
> @@ -42,7 +42,8 @@ nouveau_sgdma_populate(struct ttm_backend *be, unsigned 
> long num_pages,
>  
>   nvbe->nr_pages = 0;
>   while (num_pages--) {
> - if (dma_addrs[nvbe->nr_pages] != DMA_ERROR_CODE) {
> + /* this code path isn't called and is incorrect anyways */
> + if (0) { /*dma_addrs[nvbe->nr_pages] != DMA_ERROR_CODE)*/
>   nvbe->pages[nvbe->nr_pages] =
>   dma_addrs[nvbe->nr_pages];
>   nvbe->ttm_alloced[nvbe->nr_pages] = true;
> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
> b/drivers/gpu/drm/radeon/radeon_gart.c
> index 8a955bb..a533f52 100644
> --- a/drivers/gpu/drm/radeon/radeon_gart.c
> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
> @@ -181,9 +181,9 @@ int radeon_gart_bind(struct radeon_device *rdev, unsigned 
> offset,
>   p = t / (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
>  
>   for (i = 0; i < pages; i++, p++) {
> - /* On TTM path, we only use the DMA API if TTM_PAGE_FLAG_DMA32
> -  * is requested. */
> - if (dma_addr[i] != DMA_ERROR_CODE) {
> + /* we reverted the patch using dma_addr in TTM for now but this
> +  * code stops building on alpha so just comment it out for now 
> */
> + if (0) { /*dma_addr[i] != DMA_ERROR_CODE) */
>   rdev->gart.ttm_alloced[p] = true;
>   rdev->gart.pages_addr[p] = dma_addr[i];
>   } else {
> -- 
> 1.7.1

long delay when using HMDI output on RS780

[Alex Deucher]

On Sat, May 7, 2011 at 8:15 PM, Thomas Fjellstrom  
wrote:
> I just switched to using HDMI with my media center, and its causing a 30+
> second delay in the screen turning on, as well as a 7 second delay in the X
> startup when it tries to fetch the EDID information. Basically I don't get any
> picture at all once KMS initializes until after X has been up a few seconds.
>
> The odd thing is the monitor seems to think something is going on, since it
> doesn't go to sleep or display its "No Signal" OSD, but just after X starts
> up, it pops up the "Input detected/switched" OSD, and the picture appears.
>
> The bios, grub2 (in both text mode and graphics mode), and the initial linux
> kernel messages all display fine and immediately. Its only once KMS and
> radeondrmfb initializes that there's a problem (at least till X starts up).
>
> I've just built with a vanila 2.6.38.4 kernel from the stable git repo, and
> have played with some EDID settings, trying to disable edid where I could
> thinking thats what caused the problem. That doesn't seem to be the case
> though. I also tried playing with the video= kernel option, trying to force
> disable VGA-1, and set a static mode for HDMI-A-1, but if I try, it seems to
> force disable HDMI-A-1 instead of force the mode.
>
> With a DVI-D cable instead, the problem goes away.
>
> Attached are the dmesg and xorg.log files for the latest boot with HDMI (no
> video= parameter, and EDID enabled, most settings at defaults).
>
> What exactly would cause this, and is there a way I can fix it?

Most likely, the monitor doesn't like the hdmi packets it's getting
from the GPU.  If you don't need audio, boot 2.6.38 or newer with
radeon.audio=0

Alex

>
> --
> Thomas Fjellstrom
> thomas at fjellstrom.ca
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

long delay when using HMDI output on RS780

[Jerome Glisse]

On Mon, May 9, 2011 at 3:50 PM, Thomas Fjellstrom  
wrote:
> On May 7, 2011, Thomas Fjellstrom wrote:
>> I just switched to using HDMI with my media center, and its causing a 30+
>> second delay in the screen turning on, as well as a 7 second delay in the X
>> startup when it tries to fetch the EDID information. Basically I don't get
>> any picture at all once KMS initializes until after X has been up a few
>> seconds.
>>
>> The odd thing is the monitor seems to think something is going on, since it
>> doesn't go to sleep or display its "No Signal" OSD, but just after X starts
>> up, it pops up the "Input detected/switched" OSD, and the picture appears.
>>
>> The bios, grub2 (in both text mode and graphics mode), and the initial
>> linux kernel messages all display fine and immediately. Its only once KMS
>> and radeondrmfb initializes that there's a problem (at least till X starts
>> up).
>>
>> I've just built with a vanila 2.6.38.4 kernel from the stable git repo, and
>> have played with some EDID settings, trying to disable edid where I could
>> thinking thats what caused the problem. That doesn't seem to be the case
>> though. I also tried playing with the video= kernel option, trying to force
>> disable VGA-1, and set a static mode for HDMI-A-1, but if I try, it seems
>> to force disable HDMI-A-1 instead of force the mode.
>>
>> With a DVI-D cable instead, the problem goes away.
>>
>> Attached are the dmesg and xorg.log files for the latest boot with HDMI (no
>> video= parameter, and EDID enabled, most settings at defaults).
>>
>> What exactly would cause this, and is there a way I can fix it?
>
> I've been playing around with it more, and got it to not blank the screen
> after KMS init, /once/. So far no luck repeating that success.
>
> I've tried late, and early kms init, and currently have the radeon module and
> firmware compiled into the kernel. Boot times at least are fairly decent, 
> about
> 8-10s till X starts, but about 25-35s till anything shows up.
>
> Some strangeness, I have the kernel set to force the hdmi output to on, with a
> very specific mode, that X tends to like, the vga port is forced disabled. X 
> is
> set to ignore EDID, and also set to that specific mode that it tends to auto
> set itself. Regardless X still wants to pause for 7s 2-3 times while
> processing EDID info.
>
> I've attached the new dmesg and xorg logs from the latest attempts.
>
> Note, this only happens with KMS, with HDMI. disabling KMS, or using DVI makes
> the problem go away. Even grub's own graphical mode works fine, its only once
> KMS inits that things go bad, and its not till after X is up for a few seconds
> that something displays on my screen.
>
> --
> Thomas Fjellstrom
> thomas at fjellstrom.ca
>

Please boot with drm.debug=4 and attach dmesg it should be more
verbose. You might also want to try booting with radeon.audio=0

Cheers,
Jerome

[Bug 37040] New: Radeon driver reports EDID errors every 10 seconds

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37040

   Summary: Radeon driver reports EDID errors every 10 seconds
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: teufel at cs.uni-frankfurt.de


Created an attachment (id=46512)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46512)
an excerpt of /var/log/messages with some comments and an example of the output
 to tty1

Radeon driver reports EDID errors every 10 seconds, which causes related log
files increased over 100M in size every day and makes the system hardly usable
because of the output every 10 seconds to tty1 (and ttyS0 in my case).

See also my related LKML message: https://lkml.org/lkml/2011/4/14/661

I get every 10 seconds:
radeon :01:05.0: HDMI-A-1: EDID block 0 invalid.
together with a block of zeroes (only on tty1, see attachment).

OS: Debian GNU/Linux 6.0.1 (squeeze)
kernel: Linux 2.6.38-bpo.2-amd64 (2.6.38-3~bpo60+1)
(it was the same with Linux 2.6.32-5-amd64 (2.6.32-31))

Mainboard: ASUS M2A-VM
Chipset (onboard): ATI Technologies Inc RS690 [Radeon X1200 Series]
aka 01:05.0 0300: 1002:791e

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 34102] radeon drm/kms: please use suspend/hibernate notifiers for allocating memory in suspend routines

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34102





--- Comment #11 from Martin Steigerwald   2011-05-09 
15:59:09 ---
Ok, now it did it! First with 256 MiB reserved_size then also with 128 MiB
reserved_size. Two KDE 4 sessions with compositing enabled. It had some
problems to freeze tasks initially, cause an rdiff-backup and two KDE 4 desktop
search indexers were running, but after some tries it did it. And if the
rdiff-backup and those desktop searches fill the laptop harddisk with I/O
requests up to its limit, thats just what to be expected. I am now testing 128
MiB and looks whether it works reliably. Still I wonder why 2 MiB was enough
for one KDE 4 session, but two need something around 128 MiB.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

long delay when using HMDI output on RS780

[Thomas Fjellstrom]

On May 9, 2011, Alex Deucher wrote:
> On Mon, May 9, 2011 at 5:04 PM, Thomas Fjellstrom  
wrote:
> > On May 9, 2011, Thomas Fjellstrom wrote:
> >> On May 9, 2011, Jerome Glisse wrote:
> >> > On Mon, May 9, 2011 at 3:50 PM, Thomas Fjellstrom
> >> > 
> >> 
> >> wrote:
> >> > > On May 7, 2011, Thomas Fjellstrom wrote:
> >> > >> I just switched to using HDMI with my media center, and its causing
> >> > >> a 30+ second delay in the screen turning on, as well as a 7 second
> >> > >> delay in the X startup when it tries to fetch the EDID
> >> > >> information. Basically I don't get any picture at all once KMS
> >> > >> initializes until after X has been up a few seconds.
> >> > >> 
> >> > >> The odd thing is the monitor seems to think something is going on,
> >> > >> since it doesn't go to sleep or display its "No Signal" OSD, but
> >> > >> just after X starts up, it pops up the "Input detected/switched"
> >> > >> OSD, and the picture appears.
> >> > >> 
> >> > >> The bios, grub2 (in both text mode and graphics mode), and the
> >> > >> initial linux kernel messages all display fine and immediately.
> >> > >> Its only once KMS and radeondrmfb initializes that there's a
> >> > >> problem (at least till X starts up).
> >> > >> 
> >> > >> I've just built with a vanila 2.6.38.4 kernel from the stable git
> >> > >> repo, and have played with some EDID settings, trying to disable
> >> > >> edid where I could thinking thats what caused the problem. That
> >> > >> doesn't seem to be the case though. I also tried playing with the
> >> > >> video= kernel option, trying to force disable VGA-1, and set a
> >> > >> static mode for HDMI-A-1, but if I try, it seems to force disable
> >> > >> HDMI-A-1 instead of force the mode.
> >> > >> 
> >> > >> With a DVI-D cable instead, the problem goes away.
> >> > >> 
> >> > >> Attached are the dmesg and xorg.log files for the latest boot with
> >> > >> HDMI (no video= parameter, and EDID enabled, most settings at
> >> > >> defaults).
> >> > >> 
> >> > >> What exactly would cause this, and is there a way I can fix it?
> >> > > 
> >> > > I've been playing around with it more, and got it to not blank the
> >> > > screen after KMS init, /once/. So far no luck repeating that
> >> > > success.
> >> > > 
> >> > > I've tried late, and early kms init, and currently have the radeon
> >> > > module and firmware compiled into the kernel. Boot times at least
> >> > > are fairly decent, about 8-10s till X starts, but about 25-35s till
> >> > > anything shows up.
> >> > > 
> >> > > Some strangeness, I have the kernel set to force the hdmi output to
> >> > > on, with a very specific mode, that X tends to like, the vga port
> >> > > is forced disabled. X is set to ignore EDID, and also set to that
> >> > > specific mode that it tends to auto set itself. Regardless X still
> >> > > wants to pause for 7s 2-3 times while processing EDID info.
> >> > > 
> >> > > I've attached the new dmesg and xorg logs from the latest attempts.
> >> > > 
> >> > > Note, this only happens with KMS, with HDMI. disabling KMS, or using
> >> > > DVI makes the problem go away. Even grub's own graphical mode works
> >> > > fine, its only once KMS inits that things go bad, and its not till
> >> > > after X is up for a few seconds that something displays on my
> >> > > screen.
> >> > > 
> >> > > --
> >> > > Thomas Fjellstrom
> >> > > thomas at fjellstrom.ca
> >> > 
> >> > Please boot with drm.debug=4 and attach dmesg it should be more
> >> > verbose. You might also want to try booting with radeon.audio=0
> >> 
> >> Hi, attached both one with just drm.debug=4, and one with that and
> >> radeon.audio=0.
> >> 
> >> Now, I'm guessing its a bug in my monitor claiming it can do HDMI audio?
> >> As setting radeon.audio=0 seems to have fixed the blanking problem. And
> >> the dmesg logs seem to claim that radeon thinks it can do HDMI audio.
> 
> Most likely the driver is sending the wrong packets for hdmi audio.
> Until that gets fixed up, it's probably best to disable hdmi audio if
> it's not working for you.

Ok. I'll do that for now, since I have no need for HDMI audio atm. My receiver 
is only capable of Dolby Pro Logic input, so eh.

Would be nice to fix the xorg pauses. And whatever is causing the massive 
amounts of drm log spam (yes, I could disable drm.debug, but that would just 
hide the issue, as whatever it is, will keep doing whatever it is doing 
regardless).

> Alex
> 
> >> It also seems to be ignoring the mode I've requested via the video=
> >> param. It at least sees that I want it forced enabled, but claims its
> >> 0x0? Or at least it seems its picking the preferred mode.
> >> 
> >> Still have X blocking for up to 14s though.
> >> 
> >> Theres also a bunch of repeated log messages from drm now, every second
> >> about it seems to spam the following lines: (the last one is repeated a
> >> bunch of times, with FB:44 or FB:42)
> >> 
> >> [   31.330033] [drm:output_poll_execute], [CONNECTOR:13:VGA-1] status
> >> updated from 

[Bug 34102] radeon drm/kms: please use suspend/hibernate notifiers for allocating memory in suspend routines

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34102





--- Comment #10 from Martin Steigerwald   2011-05-09 
15:15:49 ---
This wasn't a hang I think, see there.

I tried to hibernate two running KDE 4 sessions with reserved_size upto 64 MiB:

shambhala:/sys/power> cat reserved_size 
67108864

Which failed with:

May  9 16:41:47 localhost kernel: PM: freeze of devices complete after 524.427
msecs
May  9 16:41:47 localhost kernel: PM: late freeze of devices complete after
0.509 msecs
May  9 16:41:47 localhost kernel: ACPI: Preparing to enter system sleep state
S4
May  9 16:41:47 localhost kernel: PM: Saving platform NVS memory
May  9 16:41:47 localhost kernel: Extended CMOS year: 2000
May  9 16:41:47 localhost kernel: PM: Creating hibernation image:
May  9 16:41:47 localhost kernel: PM: Need to copy 218459 pages
May  9 16:41:47 localhost kernel: PM: Normal pages needed: 113686 + 1024,
available pages: 113492
May  9 16:41:47 localhost kernel: PM: Not enough free memory
May  9 16:41:47 localhost kernel: PM: Error -12 creating hibernation image
May  9 16:41:47 localhost kernel: Extended CMOS year: 2000
May  9 16:41:47 localhost kernel: ACPI: Waking up from system sleep state S4
May  9 16:41:47 localhost kernel: PM: early recover of devices complete after
0.366 msecs

Does it make sense to go to even higher values? I am a bit puzzled, since for
one KDE 4 session a value of 2 MiB has turned out to be enough for about 5-10
attempts - it didn't fail once.

Maybe here there is simply not enough memory available no matter what I reserve
for driver allocation? If so, then so be it. That might be just a limit for a 2
GB RAM machine.

Is there a way to tell for sure whether reserved size is too low or there are
general memory constraints? TuxOnIce logged how much of the reserved extra
pages it used. Can in-kernel-hibernation do this too?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

long delay when using HMDI output on RS780

[Thomas Fjellstrom]

On May 9, 2011, Thomas Fjellstrom wrote:
> On May 9, 2011, Jerome Glisse wrote:
> > On Mon, May 9, 2011 at 3:50 PM, Thomas Fjellstrom 
> 
> wrote:
> > > On May 7, 2011, Thomas Fjellstrom wrote:
> > >> I just switched to using HDMI with my media center, and its causing a
> > >> 30+ second delay in the screen turning on, as well as a 7 second delay
> > >> in the X startup when it tries to fetch the EDID information.
> > >> Basically I don't get any picture at all once KMS initializes until
> > >> after X has been up a few seconds.
> > >> 
> > >> The odd thing is the monitor seems to think something is going on,
> > >> since it doesn't go to sleep or display its "No Signal" OSD, but just
> > >> after X starts up, it pops up the "Input detected/switched" OSD, and
> > >> the picture appears.
> > >> 
> > >> The bios, grub2 (in both text mode and graphics mode), and the initial
> > >> linux kernel messages all display fine and immediately. Its only once
> > >> KMS and radeondrmfb initializes that there's a problem (at least till
> > >> X starts up).
> > >> 
> > >> I've just built with a vanila 2.6.38.4 kernel from the stable git
> > >> repo, and have played with some EDID settings, trying to disable edid
> > >> where I could thinking thats what caused the problem. That doesn't
> > >> seem to be the case though. I also tried playing with the video=
> > >> kernel option, trying to force disable VGA-1, and set a static mode
> > >> for HDMI-A-1, but if I try, it seems to force disable HDMI-A-1
> > >> instead of force the mode.
> > >> 
> > >> With a DVI-D cable instead, the problem goes away.
> > >> 
> > >> Attached are the dmesg and xorg.log files for the latest boot with
> > >> HDMI (no video= parameter, and EDID enabled, most settings at
> > >> defaults).
> > >> 
> > >> What exactly would cause this, and is there a way I can fix it?
> > > 
> > > I've been playing around with it more, and got it to not blank the
> > > screen after KMS init, /once/. So far no luck repeating that success.
> > > 
> > > I've tried late, and early kms init, and currently have the radeon
> > > module and firmware compiled into the kernel. Boot times at least are
> > > fairly decent, about 8-10s till X starts, but about 25-35s till
> > > anything shows up.
> > > 
> > > Some strangeness, I have the kernel set to force the hdmi output to on,
> > > with a very specific mode, that X tends to like, the vga port is forced
> > > disabled. X is set to ignore EDID, and also set to that specific mode
> > > that it tends to auto set itself. Regardless X still wants to pause for
> > > 7s 2-3 times while processing EDID info.
> > > 
> > > I've attached the new dmesg and xorg logs from the latest attempts.
> > > 
> > > Note, this only happens with KMS, with HDMI. disabling KMS, or using
> > > DVI makes the problem go away. Even grub's own graphical mode works
> > > fine, its only once KMS inits that things go bad, and its not till
> > > after X is up for a few seconds that something displays on my screen.
> > > 
> > > --
> > > Thomas Fjellstrom
> > > thomas at fjellstrom.ca
> > 
> > Please boot with drm.debug=4 and attach dmesg it should be more
> > verbose. You might also want to try booting with radeon.audio=0
> 
> Hi, attached both one with just drm.debug=4, and one with that and
> radeon.audio=0.
> 
> Now, I'm guessing its a bug in my monitor claiming it can do HDMI audio? As
> setting radeon.audio=0 seems to have fixed the blanking problem. And the
> dmesg logs seem to claim that radeon thinks it can do HDMI audio.
> 
> It also seems to be ignoring the mode I've requested via the video= param.
> It at least sees that I want it forced enabled, but claims its 0x0? Or at
> least it seems its picking the preferred mode.
> 
> Still have X blocking for up to 14s though.
> 
> Theres also a bunch of repeated log messages from drm now, every second
> about it seems to spam the following lines: (the last one is repeated a
> bunch of times, with FB:44 or FB:42)
> 
> [   31.330033] [drm:output_poll_execute], [CONNECTOR:13:VGA-1] status
> updated from 2 to 2
> [   31.435455] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected
> [   31.435463] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status
> updated from 1 to 1
> [   31.437391] [drm:drm_mode_addfb], [FB:42]
> 
> > Cheers,
> > Jerome

Ok, a bit more news. My monitor does indeed support audio, at least it has 
volume buttons, so I assume it has speakers, and should support HDMI audio (I 
have never used it though).

-- 
Thomas Fjellstrom
thomas at fjellstrom.ca

[PATCH] drm/radeon: fix cayman struct accessors.

[Dave Airlie]

From: Dave Airlie 

We are accessing totally the wrong struct in this case, and putting
uninitialised values into the GPU, which it doesn't like unsurprisingly.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/ni.c |   16 
 1 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 7aade20..e9e45ea 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -871,7 +871,7 @@ static void cayman_gpu_init(struct radeon_device *rdev)

smx_dc_ctl0 = RREG32(SMX_DC_CTL0);
smx_dc_ctl0 &= ~NUMBER_OF_SETS(0x1ff);
-   smx_dc_ctl0 |= NUMBER_OF_SETS(rdev->config.evergreen.sx_num_of_sets);
+   smx_dc_ctl0 |= NUMBER_OF_SETS(rdev->config.cayman.sx_num_of_sets);
WREG32(SMX_DC_CTL0, smx_dc_ctl0);

WREG32(SPI_CONFIG_CNTL_1, VTX_DONE_DELAY(4) | 
CRC_SIMD_ID_WADDR_DISABLE);
@@ -887,20 +887,20 @@ static void cayman_gpu_init(struct radeon_device *rdev)

WREG32(TA_CNTL_AUX, DISABLE_CUBE_ANISO);

-   WREG32(SX_EXPORT_BUFFER_SIZES, 
(COLOR_BUFFER_SIZE((rdev->config.evergreen.sx_max_export_size / 4) - 1) |
-   
POSITION_BUFFER_SIZE((rdev->config.evergreen.sx_max_export_pos_size / 4) - 1) |
-   
SMX_BUFFER_SIZE((rdev->config.evergreen.sx_max_export_smx_size / 4) - 1)));
+   WREG32(SX_EXPORT_BUFFER_SIZES, 
(COLOR_BUFFER_SIZE((rdev->config.cayman.sx_max_export_size / 4) - 1) |
+   
POSITION_BUFFER_SIZE((rdev->config.cayman.sx_max_export_pos_size / 4) - 1) |
+   
SMX_BUFFER_SIZE((rdev->config.cayman.sx_max_export_smx_size / 4) - 1)));

-   WREG32(PA_SC_FIFO_SIZE, 
(SC_PRIM_FIFO_SIZE(rdev->config.evergreen.sc_prim_fifo_size) |
-
SC_HIZ_TILE_FIFO_SIZE(rdev->config.evergreen.sc_hiz_tile_fifo_size) |
-
SC_EARLYZ_TILE_FIFO_SIZE(rdev->config.evergreen.sc_earlyz_tile_fifo_size)));
+   WREG32(PA_SC_FIFO_SIZE, 
(SC_PRIM_FIFO_SIZE(rdev->config.cayman.sc_prim_fifo_size) |
+
SC_HIZ_TILE_FIFO_SIZE(rdev->config.cayman.sc_hiz_tile_fifo_size) |
+
SC_EARLYZ_TILE_FIFO_SIZE(rdev->config.cayman.sc_earlyz_tile_fifo_size)));


WREG32(VGT_NUM_INSTANCES, 1);

WREG32(CP_PERFMON_CNTL, 0);

-   WREG32(SQ_MS_FIFO_SIZES, (CACHE_FIFO_SIZE(16 * 
rdev->config.evergreen.sq_num_cf_insts) |
+   WREG32(SQ_MS_FIFO_SIZES, (CACHE_FIFO_SIZE(16 * 
rdev->config.cayman.sq_num_cf_insts) |
  FETCH_FIFO_HIWATER(0x4) |
  DONE_FIFO_HIWATER(0xe0) |
  ALU_UPDATE_FIFO_HIWATER(0x8)));
-- 
1.7.1

long delay when using HMDI output on RS780

[Thomas Fjellstrom]

On May 9, 2011, Jerome Glisse wrote:
> On Mon, May 9, 2011 at 3:50 PM, Thomas Fjellstrom  
wrote:
> > On May 7, 2011, Thomas Fjellstrom wrote:
> >> I just switched to using HDMI with my media center, and its causing a
> >> 30+ second delay in the screen turning on, as well as a 7 second delay
> >> in the X startup when it tries to fetch the EDID information. Basically
> >> I don't get any picture at all once KMS initializes until after X has
> >> been up a few seconds.
> >> 
> >> The odd thing is the monitor seems to think something is going on, since
> >> it doesn't go to sleep or display its "No Signal" OSD, but just after X
> >> starts up, it pops up the "Input detected/switched" OSD, and the
> >> picture appears.
> >> 
> >> The bios, grub2 (in both text mode and graphics mode), and the initial
> >> linux kernel messages all display fine and immediately. Its only once
> >> KMS and radeondrmfb initializes that there's a problem (at least till X
> >> starts up).
> >> 
> >> I've just built with a vanila 2.6.38.4 kernel from the stable git repo,
> >> and have played with some EDID settings, trying to disable edid where I
> >> could thinking thats what caused the problem. That doesn't seem to be
> >> the case though. I also tried playing with the video= kernel option,
> >> trying to force disable VGA-1, and set a static mode for HDMI-A-1, but
> >> if I try, it seems to force disable HDMI-A-1 instead of force the mode.
> >> 
> >> With a DVI-D cable instead, the problem goes away.
> >> 
> >> Attached are the dmesg and xorg.log files for the latest boot with HDMI
> >> (no video= parameter, and EDID enabled, most settings at defaults).
> >> 
> >> What exactly would cause this, and is there a way I can fix it?
> > 
> > I've been playing around with it more, and got it to not blank the screen
> > after KMS init, /once/. So far no luck repeating that success.
> > 
> > I've tried late, and early kms init, and currently have the radeon module
> > and firmware compiled into the kernel. Boot times at least are fairly
> > decent, about 8-10s till X starts, but about 25-35s till anything shows
> > up.
> > 
> > Some strangeness, I have the kernel set to force the hdmi output to on,
> > with a very specific mode, that X tends to like, the vga port is forced
> > disabled. X is set to ignore EDID, and also set to that specific mode
> > that it tends to auto set itself. Regardless X still wants to pause for
> > 7s 2-3 times while processing EDID info.
> > 
> > I've attached the new dmesg and xorg logs from the latest attempts.
> > 
> > Note, this only happens with KMS, with HDMI. disabling KMS, or using DVI
> > makes the problem go away. Even grub's own graphical mode works fine,
> > its only once KMS inits that things go bad, and its not till after X is
> > up for a few seconds that something displays on my screen.
> > 
> > --
> > Thomas Fjellstrom
> > thomas at fjellstrom.ca
> 
> Please boot with drm.debug=4 and attach dmesg it should be more
> verbose. You might also want to try booting with radeon.audio=0

Hi, attached both one with just drm.debug=4, and one with that and 
radeon.audio=0.

Now, I'm guessing its a bug in my monitor claiming it can do HDMI audio? As 
setting radeon.audio=0 seems to have fixed the blanking problem. And the dmesg 
logs seem to claim that radeon thinks it can do HDMI audio.

It also seems to be ignoring the mode I've requested via the video= param. It 
at least sees that I want it forced enabled, but claims its 0x0? Or at least 
it seems its picking the preferred mode.

Still have X blocking for up to 14s though.

Theres also a bunch of repeated log messages from drm now, every second about 
it seems to spam the following lines: (the last one is repeated a bunch of 
times, with FB:44 or FB:42)

[   31.330033] [drm:output_poll_execute], [CONNECTOR:13:VGA-1] status updated 
from 2 to 2
[   31.435455] [drm:radeon_atombios_connected_scratch_regs], DFP1 connected
[   31.435463] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status 
updated from 1 to 1
[   31.437391] [drm:drm_mode_addfb], [FB:42]


> Cheers,
> Jerome
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
Thomas Fjellstrom
thomas at fjellstrom.ca
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.38.5-local (moose at chauncey) (gcc version 
4.6.1 20110428 (prerelease) (Debian 4.6.0-6) ) #14 SMP PREEMPT Sun May 8 
23:19:24 MDT 2011
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38.5-local 
root=UUID=f0797db1-b72e-43bc-9267-1c1f7a3736b5 ro video=HDMI-A-1:1920x1080 at 
59.9D video=VGA-1:d drm.debug=4 quiet
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 

No subject

which contradicts with the topic we are discussed. Regardless of the
combination_mode, the log seems to work ..  weird.

2011/5/9 Melchior FRANZ 

> * Joey Lee -- Monday 09 May 2011:
> > The following is debug patch, and please add kernel parameter
> > drm.debug=0x02 :
>
> The result is with acpi_osi=Linux:
>
>
> boot phase:
> [3.310274] [drm:intel_panel_get_backlight], get backlight val = 2890
> [3.310280] [drm:intel_panel_get_backlight], get backlight PWM = 2890
> [3.310615] [drm:intel_panel_get_backlight], get backlight val = 2890
> [3.310617] [drm:intel_panel_get_backlight], get backlight PWM = 2890
> [3.310619] [drm:intel_panel_set_backlight], set backlight PWM = 0
> [3.310622] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189401930
> [3.310624] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [3.310626] [drm:intel_panel_set_backlight], set backlight level = 0
>
> [3.641522] [drm:intel_panel_set_backlight], set backlight PWM = 2890
> [3.641525] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189399040
> [3.641527] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [3.641529] [drm:intel_panel_set_backlight], set backlight level = 2890
>
> [   11.410563] video LNXVIDEO:01: Restoring backlight state
>
>
>
> brightness up:
>   [no output]
>
>
>
> brightness down:
> [  152.697127] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  152.697136] [drm:intel_panel_set_backlight], set backlight PWM = 283
> [  152.697141] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189401930
> [  152.697146] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  152.697150] [drm:intel_panel_set_backlight], set backlight level = 283
>
> [  166.720631] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  166.720640] [drm:intel_panel_set_backlight], set backlight PWM = 578
> [  166.720645] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189399323
> [  166.720649] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  166.720654] [drm:intel_panel_set_backlight], set backlight level = 578
>
> [  178.091776] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  178.091784] [drm:intel_panel_set_backlight], set backlight PWM = 861
> [  178.091789] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189399618
> [  178.091793] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  178.091797] [drm:intel_panel_set_backlight], set backlight level = 861
>
> [  188.888370] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  188.888379] [drm:intel_panel_set_backlight], set backlight PWM = 1156
> [  188.888383] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189399901
> [  188.888388] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  188.888392] [drm:intel_panel_set_backlight], set backlight level = 1156
>
> [  196.411657] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  196.411665] [drm:intel_panel_set_backlight], set backlight PWM = 1439
> [  196.411670] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189400196
> [  196.411674] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  196.411678] [drm:intel_panel_set_backlight], set backlight level = 1439
>
> [  201.256229] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  201.256238] [drm:intel_panel_set_backlight], set backlight PWM = 1734
> [  201.256243] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189400479
> [  201.256247] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  201.256252] [drm:intel_panel_set_backlight], set backlight level = 1734
>
> [  206.939838] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  206.939846] [drm:intel_panel_set_backlight], set backlight PWM = 2017
> [  206.939851] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189400774
> [  206.939856] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  206.939860] [drm:intel_panel_set_backlight], set backlight level = 2017
>
> [  213.779732] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  213.779740] [drm:intel_panel_set_backlight], set backlight PWM = 2312
> [  213.779744] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189401057
> [  213.779749] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  213.779753] [drm:intel_panel_set_backlight], set backlight level = 2312
>
> [  222.583806] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  222.583814] [drm:intel_panel_set_backlight], set backlight PWM = 2595
> [  222.583819] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189401352
> [  222.583824] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  222.583828] 

long delay when using HMDI output on RS780

[Thomas Fjellstrom]

On May 7, 2011, Thomas Fjellstrom wrote:
> I just switched to using HDMI with my media center, and its causing a 30+
> second delay in the screen turning on, as well as a 7 second delay in the X
> startup when it tries to fetch the EDID information. Basically I don't get
> any picture at all once KMS initializes until after X has been up a few
> seconds.
> 
> The odd thing is the monitor seems to think something is going on, since it
> doesn't go to sleep or display its "No Signal" OSD, but just after X starts
> up, it pops up the "Input detected/switched" OSD, and the picture appears.
> 
> The bios, grub2 (in both text mode and graphics mode), and the initial
> linux kernel messages all display fine and immediately. Its only once KMS
> and radeondrmfb initializes that there's a problem (at least till X starts
> up).
> 
> I've just built with a vanila 2.6.38.4 kernel from the stable git repo, and
> have played with some EDID settings, trying to disable edid where I could
> thinking thats what caused the problem. That doesn't seem to be the case
> though. I also tried playing with the video= kernel option, trying to force
> disable VGA-1, and set a static mode for HDMI-A-1, but if I try, it seems
> to force disable HDMI-A-1 instead of force the mode.
> 
> With a DVI-D cable instead, the problem goes away.
> 
> Attached are the dmesg and xorg.log files for the latest boot with HDMI (no
> video= parameter, and EDID enabled, most settings at defaults).
> 
> What exactly would cause this, and is there a way I can fix it?

I've been playing around with it more, and got it to not blank the screen 
after KMS init, /once/. So far no luck repeating that success.

I've tried late, and early kms init, and currently have the radeon module and 
firmware compiled into the kernel. Boot times at least are fairly decent, about 
8-10s till X starts, but about 25-35s till anything shows up.

Some strangeness, I have the kernel set to force the hdmi output to on, with a 
very specific mode, that X tends to like, the vga port is forced disabled. X is 
set to ignore EDID, and also set to that specific mode that it tends to auto 
set itself. Regardless X still wants to pause for 7s 2-3 times while 
processing EDID info.

I've attached the new dmesg and xorg logs from the latest attempts.

Note, this only happens with KMS, with HDMI. disabling KMS, or using DVI makes 
the problem go away. Even grub's own graphical mode works fine, its only once 
KMS inits that things go bad, and its not till after X is up for a few seconds 
that something displays on my screen.

-- 
Thomas Fjellstrom
thomas at fjellstrom.ca
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.38.5-local (moose at chauncey) (gcc version 
4.6.1 20110428 (prerelease) (Debian 4.6.0-6) ) #14 SMP PREEMPT Sun May 8 
23:19:24 MDT 2011
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38.5-local 
root=UUID=f0797db1-b72e-43bc-9267-1c1f7a3736b5 ro video=HDMI-A-1:1920x1080 at 
59.9D video=VGA-1:d quiet
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f800 (usable)
[0.00]  BIOS-e820: 0009f800 - 000a (reserved)
[0.00]  BIOS-e820: 000f - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 77de (usable)
[0.00]  BIOS-e820: 77de - 77de3000 (ACPI NVS)
[0.00]  BIOS-e820: 77de3000 - 77df (ACPI data)
[0.00]  BIOS-e820: 77df - 77e0 (reserved)
[0.00]  BIOS-e820: e000 - f000 (reserved)
[0.00]  BIOS-e820: fec0 - 0001 (reserved)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.4 present.
[0.00] DMI: Gigabyte Technology Co., Ltd. GA-MA78GM-S2H/GA-MA78GM-S2H, 
BIOS F11 09/16/2009
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x77de0 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C7FFF write-protect
[0.00]   C8000-F uncachable
[0.00] MTRR variable ranges enabled:
[0.00]   0 base  mask C000 write-back
[0.00]   1 base 4000 mask E000 write-back
[0.00]   2 base 6000 mask F000 write-back
[0.00]   3 base 7000 mask F800 write-back
[0.00]   4 base 77E0 mask FFE0 uncachable
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37028

Sven Arvidsson  changed:

   What|Removed |Added

 CC||sa at whiz.se

--- Comment #4 from Sven Arvidsson  2011-05-09 12:52:05 PDT ---
Yeah, I'm having the same problem.

The Amnesia devs posted a nifty compatibility test for the game which can be
used to to quickly recreate these bugs (the black bar seems to start at test
5). It isn't available from their site any longer so I uploaded it here:
http://dl.dropbox.com/u/28577999/RendererFeatTestRound2-Linux32.zip

The game (or at least the RenderFeatTest tool) is rendering correctly with
llmvpipe.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm/radeon/nouveau: fix build regression on alpha due to Xen changes.

[Dave Airlie]

From: Dave Airlie 

The Xen changes were using DMA_ERROR_CODE which isn't defined on a few
platforms, however we reverted the Xen patch that caused use to try and
use this code path earlier in 2.6.39 cycle, so for now lets just force
the code to never take this path and allow it to build again on alpha.

The proper long term answer is probably to store if the dma_addr has
been assigned to alongside the dma_addr in the higher level code,
though I think Thomas wanted to rewrite most of this anyways properly.

Signed-off-by: Dave Airlie 
Cc: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/nouveau/nouveau_sgdma.c |3 ++-
 drivers/gpu/drm/radeon/radeon_gart.c|6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_sgdma.c 
b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
index 4bce801..c77111e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c
@@ -42,7 +42,8 @@ nouveau_sgdma_populate(struct ttm_backend *be, unsigned long 
num_pages,

nvbe->nr_pages = 0;
while (num_pages--) {
-   if (dma_addrs[nvbe->nr_pages] != DMA_ERROR_CODE) {
+   /* this code path isn't called and is incorrect anyways */
+   if (0) { /*dma_addrs[nvbe->nr_pages] != DMA_ERROR_CODE)*/
nvbe->pages[nvbe->nr_pages] =
dma_addrs[nvbe->nr_pages];
nvbe->ttm_alloced[nvbe->nr_pages] = true;
diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
b/drivers/gpu/drm/radeon/radeon_gart.c
index 8a955bb..a533f52 100644
--- a/drivers/gpu/drm/radeon/radeon_gart.c
+++ b/drivers/gpu/drm/radeon/radeon_gart.c
@@ -181,9 +181,9 @@ int radeon_gart_bind(struct radeon_device *rdev, unsigned 
offset,
p = t / (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);

for (i = 0; i < pages; i++, p++) {
-   /* On TTM path, we only use the DMA API if TTM_PAGE_FLAG_DMA32
-* is requested. */
-   if (dma_addr[i] != DMA_ERROR_CODE) {
+   /* we reverted the patch using dma_addr in TTM for now but this
+* code stops building on alpha so just comment it out for now 
*/
+   if (0) { /*dma_addr[i] != DMA_ERROR_CODE) */
rdev->gart.ttm_alloced[p] = true;
rdev->gart.pages_addr[p] = dma_addr[i];
} else {
-- 
1.7.1

[Bug 34102] radeon drm/kms: please use suspend/hibernate notifiers for allocating memory in suspend routines

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=34102





--- Comment #9 from Martin Steigerwald   2011-05-09 
12:15:32 ---
I now had a hang a preallocation (unfortunately before I came around to compile
with your patch from bug 30492). I raised reserved size to 4 MiB for now. Lets
see how that goes. If it works, then I might go back to 2 MiB or even less in
order to trigger bug 30492 with the patch from there compiled in.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Joey Lee -- Monday 09 May 2011:
> The following is debug patch, and please add kernel parameter
> drm.debug=0x02 :

The result is with acpi_osi=Linux:


boot phase:
[3.310274] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310280] [drm:intel_panel_get_backlight], get backlight PWM = 2890
[3.310615] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310617] [drm:intel_panel_get_backlight], get backlight PWM = 2890
[3.310619] [drm:intel_panel_set_backlight], set backlight PWM = 0
[3.310622] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930
[3.310624] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[3.310626] [drm:intel_panel_set_backlight], set backlight level = 0

[3.641522] [drm:intel_panel_set_backlight], set backlight PWM = 2890
[3.641525] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040
[3.641527] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[3.641529] [drm:intel_panel_set_backlight], set backlight level = 2890

[   11.410563] video LNXVIDEO:01: Restoring backlight state



brightness up:
   [no output]



brightness down:
[  152.697127] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  152.697136] [drm:intel_panel_set_backlight], set backlight PWM = 283
[  152.697141] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930
[  152.697146] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  152.697150] [drm:intel_panel_set_backlight], set backlight level = 283

[  166.720631] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  166.720640] [drm:intel_panel_set_backlight], set backlight PWM = 578
[  166.720645] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399323
[  166.720649] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  166.720654] [drm:intel_panel_set_backlight], set backlight level = 578

[  178.091776] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  178.091784] [drm:intel_panel_set_backlight], set backlight PWM = 861
[  178.091789] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399618
[  178.091793] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  178.091797] [drm:intel_panel_set_backlight], set backlight level = 861

[  188.888370] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  188.888379] [drm:intel_panel_set_backlight], set backlight PWM = 1156
[  188.888383] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399901
[  188.888388] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  188.888392] [drm:intel_panel_set_backlight], set backlight level = 1156

[  196.411657] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  196.411665] [drm:intel_panel_set_backlight], set backlight PWM = 1439
[  196.411670] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400196
[  196.411674] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  196.411678] [drm:intel_panel_set_backlight], set backlight level = 1439

[  201.256229] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  201.256238] [drm:intel_panel_set_backlight], set backlight PWM = 1734
[  201.256243] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400479
[  201.256247] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  201.256252] [drm:intel_panel_set_backlight], set backlight level = 1734

[  206.939838] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  206.939846] [drm:intel_panel_set_backlight], set backlight PWM = 2017
[  206.939851] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400774
[  206.939856] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  206.939860] [drm:intel_panel_set_backlight], set backlight level = 2017

[  213.779732] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  213.779740] [drm:intel_panel_set_backlight], set backlight PWM = 2312
[  213.779744] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401057
[  213.779749] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  213.779753] [drm:intel_panel_set_backlight], set backlight level = 2312

[  222.583806] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  222.583814] [drm:intel_panel_set_backlight], set backlight PWM = 2595
[  222.583819] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401352
[  222.583824] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  222.583828] [drm:intel_panel_set_backlight], set backlight level = 2595

[  229.345860] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  229.345870] [drm:intel_panel_set_backlight], set backlight PWM = 2595
[  229.345874] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401635
[  229.345879] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  

i915/kms/backlight-combo mode problem

[Takashi Iwai]

At Mon, 09 May 2011 02:50:50 -0600,
Joey Lee wrote:
> 
> Add Cc. Michael Chang for he is our i915 expert.
> 
> Hi Melchior, 
> 
> ? ??2011-05-08 ? 16:05 +0200?Melchior FRANZ ???
> > 
> > > Does it work to you direct control brightness by access
> > > by /sys/class/backlight/acer-wmi/brightness ?
> > 
> > No. A number written to this virtual file is accepted and remembered,
> > but it doesn't actually change the brightness. It takes setpci to do
> > that. 
> > 
> 
> I thought the video driver still is the KEY component for backlight
> issues, need fix the problem in video driver first.
> 
> > 
> >  
> > > As I remember, use setpci to control brightness is not recommended
> > > because BIOS or ACPI will also touch brightness level. That will be
> > > better control brightness by the function that was provided by BIOS. 
> > > e.g. ACPI or WMI interface, or direct control by EC.
> > 
> > Well, sounds plausible. And I wouldn't do it if it weren't the only
> > way at the moment.  :-)
> > 
> > 
> > 
> > > That means that will be better fix your Fn key control brightness like
> > > before, you just need press Fn key to change brightness and don't need
> > > have any workaround.
> > 
> > OK. I have added a lot of debug messages to intel_panel.c yesterday.
> > All it told me was that it seems to work correctly wiht acpi_osi=Linux.
> > Except that it doesn't actually change the brightness. Without acpi_osi
> > the functions aren't called at all and none of my messages showed up.
> > 
> 
> I traced _Q event in your DSDT, when acpi_osi=Linux, it run the Intel
> OpRegion logic for change brightness. And, finally, intel_opregion will
> access the function the were provided by intel_panel. So, the problem
> still back to intel_panel.
> 
> After discuss with Michael chang, we thought there have problem in your
> brightness level after add combination mode:
> 
> vi driver/gpu/drm/i915/intel_panel.c
> 
> void intel_panel_set_backlight(struct drm_device *dev, u32 level)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> u32 tmp;
> 
> DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);
> 
> if (HAS_PCH_SPLIT(dev))
> return intel_pch_panel_set_backlight(dev, level);
> 
> if (is_backlight_combination_mode(dev)){
> u32 max = intel_panel_get_max_backlight(dev);
> u8 lbpc;
> 
> lbpc = level * 0xfe / max + 1;
> level /= lbpc;/* maybe the level 
> changed by lbpc */
> pci_write_config_byte(dev->pdev, PCI_LBPC, lbpc);
> }
> 
> tmp = I915_READ(BLC_PWM_CTL);
> if (IS_PINEVIEW(dev)) {
> tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
> level <<= 1;
> } else
> tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
> I915_WRITE(BLC_PWM_CTL, tmp | level);
> }
> 
> We need to know some run time value when intel_panel_set_backlight call by 
> funciton key.

Yes, that'll help understanding.

> Please help to apply the attached debug patch to intel_panel.c then attached 
> dmesg.

The patch has an obvious typo :)
Also, we should track the value in intel_panel_get_backlight(), too.


Takashi


> > > Looks like current status is we try to fix bko#31522 but the patch
> > > causes your brightness no work by press Fn key even with acpi_osi=Linux.
> > > Does it right?
> > 
> > The history is: with acpi_osi=Linux everything worked with 2.6.38-rc8.
> > With 2.6.38 the screen stayed black. The patch that only ignored lbpc=0
> > worked (IIRC) including key adjustment. Later patches broke keys.
> > 
> > 
> > 
> > >   replace acpi_osi=Linux by acpi_osi="!Windows 2006"
> > > 
> > > Does it also works to you for backlight control?
> > 
> > No, doesn't work.
> > 
> 
> We can test the acpi_osi="!Windows 2006" again after we fix the i915's
> problem.
> 
> 
> Thank's
> Joey Lee
> 
> The following is debug patch, and please add kernel parameter
> drm.debug=0x02 :
> 
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index f8f86e5..f62dbd9 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -236,17 +236,22 @@ void intel_panel_set_backlight(struct drm_device *dev, 
> u32 level)
>   u32 max = intel_panel_get_max_backlight(dev);
>   u8 lbpc;
>  
> + DRM_DEBUG_DRIVER("set backlight max = % lbpc = 
> level * 0xfe / max + 1;
> + DRM_DEBUG_DRIVER("set backlight lbpc = %d\n", lbpc);
>   level /= lbpc;
>   pci_write_config_byte(dev->pdev, PCI_LBPC, lbpc);
>   }
>  
>   tmp = I915_READ(BLC_PWM_CTL);
> + DRM_DEBUG_DRIVER("set backlight tmp(1) = %d\n", tmp);
>   if (IS_PINEVIEW(dev)) {
>   tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
>   level <<= 1;
>   } else
>   tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
> + 

i915/kms/backlight-combo mode problem

[Takashi Iwai]

At Sat, 7 May 2011 22:22:40 +0200,
Melchior FRANZ wrote:
> 
> * Melchior FRANZ -- Friday 06 May 2011:
> > last patch prevents the backlight from being turned off, but it also
> > breaks the brightness adjustment keys at runtime with acpi_osi=Linux.
> 
> It has turned out that acpi key events seem to be handled correctly
> and even the state of /sys/class/backlight/acer-wmi/brightness is
> updated accordingly. The only problem is that this maintained
> brightness state isn't applied to the actual backlight. It remains
> at highest level. Google pointed me to this workaround for another
> Acer notebook:
> 
>   
> https://help.ubuntu.com/community/AspireTimeline/Fixes#Alternative%20fix%20for%2010.10
> 
> This uses the acpid to write the brightness value to the display
> using setpci. And this works on my notebook as well (Acer Travelmate
> 5735Z-452G32Mnss).

Then we miss something.  With the hack above, you are doing nothing
but writing LBPC register value externally from setpci.  It implies
that the write to LBPC basically works on your machine.


Takashi

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37028

--- Comment #3 from Maggioni Marcello  2011-05-09 
10:45:13 PDT ---
Created an attachment (id=46494)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46494)
Screenshot

I uploaded the wrong screenshot the first time

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37028

Maggioni Marcello  changed:

   What|Removed |Added

  Attachment #46492|0   |1
is obsolete||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37028

--- Comment #2 from Maggioni Marcello  2011-05-09 
10:41:11 PDT ---
I also tried to lower every graphical setting to the minimum, but the bug
remains.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37028

--- Comment #1 from Maggioni Marcello  2011-05-09 
10:40:21 PDT ---
Created an attachment (id=46493)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46493)
game log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 37028] New: Amnesia/HPL2 Demo: Strange graphical bugs on r600g

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37028

   Summary: Amnesia/HPL2 Demo: Strange graphical bugs on r600g
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: hayarms at gmail.com


Created an attachment (id=46492)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46492)
Screenshot

Hi, this game (amnesia dark descent) seems to run on the r600g driver, but with
some graphical bugs that make the experience "not enjoyable".

There's a big black corruption in the bottom part of the screen that covers 1/5
(almost) of the screen and strange white dots appear in the air. Water also
flickers.

The most serious glitch is the first one, the black corruption.

I've attached a screenshot of this.

I also attached the screenshot and the log from the game.

The screenshot and the log is taken from the demo version of the game.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Call for desktop/graphics/mobile tracks for Linux Plumbers' Conf 2011

[Jesse Barnes]

We have both desktop (for general graphics/media stuff) and mobile
tracks at this year's LPC.

So if you're working on a topic related to one of the above areas,
especially one that has open issues or spans multiple parts of the
stack, please submit a topic for discussion at
http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals/new
against the appropriate track.  Proposals for presentations (track
independent talks about a specific topic) are also open until May 15th,
so if you have a topic you'd like to present that doesn't fit into an
existing track, be sure to submit it soon.

Early registration for LPC is open until June 1st, so regardless of
whether you're submitting a topic, if you see discussions or proposed
talks of interest to you, be sure to register soon to get the
discounted rate.

Thanks,
Jesse Barnes
LPC2011 Planning Chair

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms & gallium

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36952

--- Comment #7 from Iaroslav  2011-05-09 09:57:59 PDT 
---
(In reply to comment #4)
> But if I downgrade to mesa 7.10.2, I am still using llvm 2.9 and the
> crackberg screensaver works correctly, so that would point to mesa-git
> being the problem for me.  I cannot compile mesa-git without llvm as the
> build process halts and complains that r300 gallium requires llvm to
> build.  There are three gentoo patches that get applied on top of the
> mesa 7.10.2-r1 build, I haven't looked at what they do yet.
> 
> (In reply to comment #2)
> > I have some problem, and i have  ATI RS482 too, but i think it was the fault
> > llvm, with out llvm or < 2.9 , all woks fine, with llvm > 2.8  openarena,
> > urbanterror and some xscreensaver segfault. see
> > https://bugs.freedesktop.org/show_bug.cgi?id=36738
> > I make backtrace with crackberg.

Can you run crackberg with gdb, and show backtrace? Or run openarena with
mesa-git+llvm-2.9.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms & gallium

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36952

--- Comment #6 from Chris Bandy  2011-05-09 09:52:02 PDT 
---
(In reply to comment #5)
> is there a way to pass commit tags to 'emerge' or specify in the ebuild?

The x11 overlay has live ebuilds. Use EGIT_COMMIT to specify a commit to
checkout.

http://devmanual.gentoo.org/eclass-reference/git-2.eclass/index.html

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Nouveau] [PATCH] drm/nouveau: release vga_ram allocation before tearing down mm's

[Ben Skeggs]

On Sat, 2011-05-07 at 18:03 +0200, Daniel Vetter wrote:
> Otherwise we have a use-after free.
> 
> Tested-and-Reported-by: Bruno Pr?mont 
> Signed-off-by: Daniel Vetter 
Ah, we actually have a patch in the nouveau git tree fixing this
already.

I'll get this upstream ASAP.

Ben.

> ---
>  drivers/gpu/drm/nouveau/nouveau_mem.c   |2 --
>  drivers/gpu/drm/nouveau/nouveau_state.c |2 ++
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c 
> b/drivers/gpu/drm/nouveau/nouveau_mem.c
> index 5045f8b..c3e953b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_mem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
> @@ -152,8 +152,6 @@ nouveau_mem_vram_fini(struct drm_device *dev)
>  {
>   struct drm_nouveau_private *dev_priv = dev->dev_private;
>  
> - nouveau_bo_ref(NULL, _priv->vga_ram);
> -
>   ttm_bo_device_release(_priv->ttm.bdev);
>  
>   nouveau_ttm_global_release(dev_priv);
> diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
> b/drivers/gpu/drm/nouveau/nouveau_state.c
> index a30adec..1fe6503 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_state.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_state.c
> @@ -768,6 +768,8 @@ static void nouveau_card_takedown(struct drm_device *dev)
>   engine->mc.takedown(dev);
>   engine->display.late_takedown(dev);
>  
> + nouveau_bo_ref(NULL, _priv->vga_ram);
> +
>   mutex_lock(>struct_mutex);
>   ttm_bo_clean_mm(_priv->ttm.bdev, TTM_PL_VRAM);
>   ttm_bo_clean_mm(_priv->ttm.bdev, TTM_PL_TT);

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #9 from Dymchenko Bogdan  2011-05-09 
07:25:03 PDT ---
no, there is no any warnings.

With default settings i see 

drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See
dmesg for more info.
and
[63763.072946] [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16403
[63763.072950] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
in dmesg

or with setup command buffer to 32 i see
radeon_common.c:1250: rcommonEnsureCmdBufSpace: Assertion
`rmesa->cmdbuf.cs->cdw' failed.
when try to start a game

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36596] Major 2D performance bottleneck (most noticeable with compiz)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36596

--- Comment #11 from Michel D?nzer  2011-05-09 07:04:50 
PDT ---
(In reply to comment #10)
> (In reply to comment #9)
> > Really sounds like the GPU IRQ doesn't work (reliably). Do the numbers on 
> > the
> > radeon line in /proc/interrupts still increase when the problem occurs?
> 
> Not a lot.  When everything's working, moving wobbly windows involves hundreds
> of interrupts.  When it's at 2 fps, there are only a few, at most.  Possibly
> none.

That probably explains the slowness, as the drivers heavily rely on the IRQ for
tracking GPU progress processing commands. With no interrupts coming in, things
will time out all over the place.

The question now is why there are no interrupts coming in...

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36608] Corrupt GL rendering

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36608

--- Comment #1 from Michel D?nzer  2011-05-09 06:57:44 
PDT ---
Does current Git master work better? At least some of the Gallium code was not
detecting the endianness of this architecture correctly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #8 from Alex Deucher  2011-05-09 06:57:17 PDT 
---
(In reply to comment #7)
> and one moment about  "I'd start with r200EnsureEmitSize() in r200_tcl.c"
> rv200 is an R100-based chipset, so driver is r100

radeonEnsureEmitSize() in radeon_tcl.c is called from radeon_run_tcl_render().
radeonEnsureEmitSize() walks through the pending state to make sure it will all
fit in the current command buffer, but it appears to be missing some additional
state that's being emitted.  If you run the game from the terminal, it should
print out a warning:
   if (emit_end < rmesa->radeon.cmdbuf.cs->cdw)
  WARN_ONCE("Rendering was %d commands larger than predicted size."
  " We might overflow  command buffer.\n", rmesa->radeon.cmdbuf.cs->cdw
- emit_end);


Most likely:
radeonEmitArrays()
radeonEmitEltPrimitive()
radeonEmitPrimitive()
is emitting more state than radeonEnsureEmitSize() thinks it should.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #7 from Dymchenko Bogdan  2011-05-09 
06:48:10 PDT ---
(In reply to comment #2)
> Please attach your xorg log, dmesg output, and glxinfo output.  Some of the
> commands that are added mostly likely for the tcl-related registers are not
> properly accounted for.  I'd start with r200EnsureEmitSize() in r200_tcl.c and
> make sure it's properly accounting for all the state that needs to be 
> emitted. 
> Print out what size it expects vs. what size gets emitted for each bit of 
> state
> and track down where the count is off.

and one moment about  "I'd start with r200EnsureEmitSize() in r200_tcl.c"
rv200 is an R100-based chipset, so driver is r100

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #6 from Dymchenko Bogdan  2011-05-09 
06:41:12 PDT ---
can you tell me, how can i find what size it expects and what size gets emitted
for each bit of state
and track down where the count is off?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #5 from Dymchenko Bogdan  2011-05-09 
06:38:39 PDT ---
Created an attachment (id=46483)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46483)
xorg log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #4 from Dymchenko Bogdan  2011-05-09 
06:38:19 PDT ---
Created an attachment (id=46482)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46482)
glxinfo output

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #3 from Dymchenko Bogdan  2011-05-09 
06:37:56 PDT ---
Created an attachment (id=46481)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46481)
dmesg output

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #2 from Alex Deucher  2011-05-09 06:34:24 PDT 
---
Please attach your xorg log, dmesg output, and glxinfo output.  Some of the
commands that are added mostly likely for the tcl-related registers are not
properly accounted for.  I'd start with r200EnsureEmitSize() in r200_tcl.c and
make sure it's properly accounting for all the state that needs to be emitted. 
Print out what size it expects vs. what size gets emitted for each bit of state
and track down where the count is off.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms & gallium

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36952

--- Comment #5 from dri tester  2011-05-09 
06:28:19 PDT ---
I will try to bisect.  I have to figure out how to install mesa-git without the
ebuild (and without messing up my dependencies), or is there a way to pass
commit tags to 'emerge' or specify in the ebuild?  Either way once I figure
that out I will bisect mesa.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms & gallium

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36952

--- Comment #4 from dri tester  2011-05-09 
06:22:56 PDT ---
But if I downgrade to mesa 7.10.2, I am still using llvm 2.9 and the
crackberg screensaver works correctly, so that would point to mesa-git
being the problem for me.  I cannot compile mesa-git without llvm as the
build process halts and complains that r300 gallium requires llvm to
build.  There are three gentoo patches that get applied on top of the
mesa 7.10.2-r1 build, I haven't looked at what they do yet.

(In reply to comment #2)
> I have some problem, and i have  ATI RS482 too, but i think it was the fault
> llvm, with out llvm or < 2.9 , all woks fine, with llvm > 2.8  openarena,
> urbanterror and some xscreensaver segfault. see
> https://bugs.freedesktop.org/show_bug.cgi?id=36738
> I make backtrace with crackberg.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

One regression fix in the debugfs output, a couple of radeon fixes, and a 
nouveau unload fix. I've got a dirty fix for the DMA_ERROR_CODE dependency 
breaking drm on alpha but waiting for a bit more before you get it, its 
just a workaround until proper fix can happen in 2.6.40 hopefully

Dave.

The following changes since commit 8aeb96f80232e9a701b5c4715504f4c9173978bd:

  drm/radeon/kms: fix gart setup on fusion parts (v2) (2011-05-04 10:16:40 
+1000)

are available in the git repository at:
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Alex Deucher (2):
  drm/radeon/kms: ATPX switcheroo fixes
  drm/radeon/kms: add pci id to acer travelmate quirk for 5730

Daniel Vetter (1):
  drm: mm: fix debug output

Dave Airlie (1):
  Merge remote branch 'nouveau/drm-nouveau-fixes' of 
/ssd/git/drm-nouveau-next into drm-fixes

Ilija Hadzic (1):
  drm/radeon: fix order of doing things in radeon_crtc_cursor_set

Jimmy Rentz (1):
  drm/nouveau: Fix a crash at card takedown for NV40 and older cards

 drivers/gpu/drm/drm_mm.c |6 ++--
 drivers/gpu/drm/nouveau/nouveau_mem.c|2 -
 drivers/gpu/drm/nouveau/nouveau_state.c  |5 
 drivers/gpu/drm/radeon/radeon_atombios.c |4 +-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |   29 -
 drivers/gpu/drm/radeon/radeon_cursor.c   |6 ++--
 include/drm/drm_mm.h |2 +-
 7 files changed, 41 insertions(+), 13 deletions(-)

[Bug 36934] screen corruption after running a game through wine

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

--- Comment #1 from Michel D?nzer  2011-05-09 04:41:10 
PDT ---
Please attach the full Xorg.0.log and the output of dmesg and glxinfo.

This is probably a driver issue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

i915/kms/backlight-combo mode problem

[Joey Lee]

? ??2011-05-09 ? 11:00 +0200?Takashi Iwai ???
> At Mon, 09 May 2011 02:50:50 -0600,
> Joey Lee wrote:
> > 
> > We need to know some run time value when intel_panel_set_backlight call by 
> > funciton key.
> 
> Yes, that'll help understanding.
> 
> > Please help to apply the attached debug patch to intel_panel.c then 
> > attached dmesg.
> 
> The patch has an obvious typo :)
> Also, we should track the value in intel_panel_get_backlight(), too.
> 
> 
> Takashi
> 

Thank's for Takashi's review and sorry for my typo. 
Follow Takashi's suggestion, I added a debug message in get_backlight,
the following is new debug patch:

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index f8f86e5..9695840 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -199,6 +199,7 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CPU_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
} else {
val = I915_READ(BLC_PWM_CTL) & BACKLIGHT_DUTY_CYCLE_MASK;
+   DRM_DEBUG_DRIVER("get backlight val = %d\n", val);
if (IS_PINEVIEW(dev))
val >>= 1;

@@ -236,17 +237,22 @@ void intel_panel_set_backlight(struct drm_device *dev, 
u32 level)
u32 max = intel_panel_get_max_backlight(dev);
u8 lbpc;

+   DRM_DEBUG_DRIVER("set backlight max = %d\n", max);
lbpc = level * 0xfe / max + 1;
+   DRM_DEBUG_DRIVER("set backlight lbpc = %d\n", lbpc);
level /= lbpc;
pci_write_config_byte(dev->pdev, PCI_LBPC, lbpc);
}

tmp = I915_READ(BLC_PWM_CTL);
+   DRM_DEBUG_DRIVER("set backlight tmp(1) = %d\n", tmp);
if (IS_PINEVIEW(dev)) {
tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level <<= 1;
} else
tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
+   DRM_DEBUG_DRIVER("set backlight tmp(2) = %d\n", tmp);
+   DRM_DEBUG_DRIVER("set backlight level = %d\n", level);
I915_WRITE(BLC_PWM_CTL, tmp | level);
 }

i915/kms/backlight-combo mode problem

[Joey Lee]

Add Cc. Michael Chang for he is our i915 expert.

Hi Melchior, 

? ??2011-05-08 ? 16:05 +0200?Melchior FRANZ ???
> 
> > Does it work to you direct control brightness by access
> > by /sys/class/backlight/acer-wmi/brightness ?
> 
> No. A number written to this virtual file is accepted and remembered,
> but it doesn't actually change the brightness. It takes setpci to do
> that. 
> 

I thought the video driver still is the KEY component for backlight
issues, need fix the problem in video driver first.

> 
>  
> > As I remember, use setpci to control brightness is not recommended
> > because BIOS or ACPI will also touch brightness level. That will be
> > better control brightness by the function that was provided by BIOS. 
> > e.g. ACPI or WMI interface, or direct control by EC.
> 
> Well, sounds plausible. And I wouldn't do it if it weren't the only
> way at the moment.  :-)
> 
> 
> 
> > That means that will be better fix your Fn key control brightness like
> > before, you just need press Fn key to change brightness and don't need
> > have any workaround.
> 
> OK. I have added a lot of debug messages to intel_panel.c yesterday.
> All it told me was that it seems to work correctly wiht acpi_osi=Linux.
> Except that it doesn't actually change the brightness. Without acpi_osi
> the functions aren't called at all and none of my messages showed up.
> 

I traced _Q event in your DSDT, when acpi_osi=Linux, it run the Intel
OpRegion logic for change brightness. And, finally, intel_opregion will
access the function the were provided by intel_panel. So, the problem
still back to intel_panel.

After discuss with Michael chang, we thought there have problem in your
brightness level after add combination mode:

vi driver/gpu/drm/i915/intel_panel.c

void intel_panel_set_backlight(struct drm_device *dev, u32 level)
{
struct drm_i915_private *dev_priv = dev->dev_private;
u32 tmp;

DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);

if (HAS_PCH_SPLIT(dev))
return intel_pch_panel_set_backlight(dev, level);

if (is_backlight_combination_mode(dev)){
u32 max = intel_panel_get_max_backlight(dev);
u8 lbpc;

lbpc = level * 0xfe / max + 1;
level /= lbpc;  /* maybe the level changed by 
lbpc */
pci_write_config_byte(dev->pdev, PCI_LBPC, lbpc);
}

tmp = I915_READ(BLC_PWM_CTL);
if (IS_PINEVIEW(dev)) {
tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level <<= 1;
} else
tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
I915_WRITE(BLC_PWM_CTL, tmp | level);
}

We need to know some run time value when intel_panel_set_backlight call by 
funciton key.
Please help to apply the attached debug patch to intel_panel.c then attached 
dmesg.

> 
> 
> > Looks like current status is we try to fix bko#31522 but the patch
> > causes your brightness no work by press Fn key even with acpi_osi=Linux.
> > Does it right?
> 
> The history is: with acpi_osi=Linux everything worked with 2.6.38-rc8.
> With 2.6.38 the screen stayed black. The patch that only ignored lbpc=0
> worked (IIRC) including key adjustment. Later patches broke keys.
> 
> 
> 
> > replace acpi_osi=Linux by acpi_osi="!Windows 2006"
> > 
> > Does it also works to you for backlight control?
> 
> No, doesn't work.
> 

We can test the acpi_osi="!Windows 2006" again after we fix the i915's
problem.


Thank's
Joey Lee

The following is debug patch, and please add kernel parameter
drm.debug=0x02 :

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index f8f86e5..f62dbd9 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -236,17 +236,22 @@ void intel_panel_set_backlight(struct drm_device *dev, 
u32 level)
u32 max = intel_panel_get_max_backlight(dev);
u8 lbpc;

+   DRM_DEBUG_DRIVER("set backlight max = % lbpc = 
level * 0xfe / max + 1;
+   DRM_DEBUG_DRIVER("set backlight lbpc = %d\n", lbpc);
level /= lbpc;
pci_write_config_byte(dev->pdev, PCI_LBPC, lbpc);
}

tmp = I915_READ(BLC_PWM_CTL);
+   DRM_DEBUG_DRIVER("set backlight tmp(1) = %d\n", tmp);
if (IS_PINEVIEW(dev)) {
tmp &= ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level <<= 1;
} else
tmp &= ~BACKLIGHT_DUTY_CYCLE_MASK;
+   DRM_DEBUG_DRIVER("set backlight tmp(2) = %d\n", tmp);
+   DRM_DEBUG_DRIVER("set backlight level = %d\n", level);
I915_WRITE(BLC_PWM_CTL, tmp | level);
 }

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #1 from Dymchenko Bogdan  2011-05-09 
02:47:43 PDT ---
When I increase command buffer to 32 kb via driconf - game starts perfectly
with hardware tcl. But than it's exited with error  
warcraft\war3.exe: radeon_common.c:1250: rcommonEnsureCmdBufSpace: Assertion
`rmesa->cmdbuf.cs->cdw' failed.
Then i try manually edit ~/.drirc and change command buffer to 34 kb and game
runs without errors. 
So this bug has an workaround, but i think that it's need to be fixed

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 36554] Amnesia game causes black screen or kernel locks

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36554

--- Comment #6 from Hicham HAOUARI  2011-05-09 
02:43:12 PDT ---
The game runs fine for me with 1GB of RAM on Fedora 14.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 31943] drm EDID checking is too strict

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31943

--- Comment #17 from Igor Strelnikoff  2011-05-09 
02:29:17 PDT ---
[   23.745086] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   24.438301] start_kdeinit (2339): /proc/2339/oom_adj is deprecated, please
use /proc/2339/oom_score_adj instead.
[   30.772338] ata3.00: configured for UDMA/133
[   30.772344] ata3: EH complete
[   31.570015] eth0: no IPv6 routers present
[   31.885279] EXT4-fs (sda2): re-mounted. Opts: acl,user_xattr,commit=0
[   31.979079] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   32.044963] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   32.140389] EXT4-fs (sda3): re-mounted. Opts: commit=0
[   43.879049] i2c i2c-0: readbytes: ack/nak timeout
[   43.879122] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   52.805480] bootsplash: status on console 0 changed to on
[  209.310829] fuse init (API version 7.15)
[  401.118127] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID

Kernel 2.6.37.6 i586

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 31943] drm EDID checking is too strict

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31943

--- Comment #16 from Igor Strelnikoff  2011-05-09 
02:27:06 PDT ---
Should I expect to fix this bug? I think this regression

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 34740] Invalid EDID on NEC 225WNX

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34740

--- Comment #13 from Igor Strelnikoff  2011-05-09 
02:21:30 PDT ---
[   23.745086] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   24.438301] start_kdeinit (2339): /proc/2339/oom_adj is deprecated, please
use /proc/2339/oom_score_adj instead.
[   30.772338] ata3.00: configured for UDMA/133
[   30.772344] ata3: EH complete
[   31.570015] eth0: no IPv6 routers present
[   31.885279] EXT4-fs (sda2): re-mounted. Opts: acl,user_xattr,commit=0
[   31.979079] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   32.044963] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   32.140389] EXT4-fs (sda3): re-mounted. Opts: commit=0
[   43.879049] i2c i2c-0: readbytes: ack/nak timeout
[   43.879122] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   52.805480] bootsplash: status on console 0 changed to on
[  209.310829] fuse init (API version 7.15)
[  401.118127] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 31943] drm EDID checking is too strict

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31943

--- Comment #15 from Igor Strelnikoff  2011-05-09 
01:59:30 PDT ---
<6>[3.130551] [drm] Initialized drm 1.1.0 20060810
<6>[3.177278] [drm] radeon defaulting to kernel modesetting.
<6>[3.177282] [drm] radeon kernel modesetting enabled.
<7>[3.177297] [drm:drm_init], 
<7>[3.178026] checking generic (e000 100) vs hw (e000 800)
<3>[3.178029] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
removing generic driver
<4>[3.178056] Console: switching to colour dummy device 80x25
<7>[3.178624] [drm:drm_get_pci_dev], 
<4>[3.178748] ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16
<6>[3.178761] radeon :01:00.0: PCI INT A -> Link[APC5] -> GSI 16
(level, low) -> IRQ 16
<7>[3.180391] [drm:drm_get_minor], 
<7>[3.180620] [drm:drm_get_minor], new minor assigned 64
<7>[3.180623] [drm:drm_get_minor], 
<7>[3.180711] [drm:drm_get_minor], new minor assigned 0
<6>[3.180724] [drm] initializing kernel modesetting (R350 0x1002:0x4E48).
<6>[3.180800] [drm] register mmio base: 0xF300
<6>[3.180802] [drm] register mmio size: 65536
<7>[3.181323] [drm:radeon_get_bios], COMBIOS detected
<6>[3.181345] agpgart-amd64 :00:00.0: AGP 3.0 bridge
<6>[3.181361] agpgart-amd64 :00:00.0: putting AGP V3 device into 8x
mode
<6>[3.181387] radeon :01:00.0: putting AGP V3 device into 8x mode
<6>[3.181406] radeon :01:00.0: GTT: 32M 0xF000 - 0xF1FF
<6>[3.181411] [drm] Generation 1 PCI interface in multifunction mode
<6>[3.181413] [drm] Limiting VRAM to one aperture
<6>[3.181418] radeon :01:00.0: VRAM: 128M 0xE000 -
0xE7FF (128M used)
<7>[3.181427] [drm:drm_irq_install], irq=16
<6>[3.181449] [drm] radeon: irq initialized.
<6>[3.181559] [drm] Detected VRAM RAM=128M, BAR=128M
<6>[3.181564] [drm] RAM width 256bits DDR
<6>[3.181637] [TTM] Zone  kernel: Available graphics memory: 438570 kiB.
<6>[3.181640] [TTM] Zone highmem: Available graphics memory: 506126 kiB.
<6>[3.181642] [TTM] Initializing pool allocator.
<6>[3.181662] [drm] radeon: 128M of VRAM memory ready
<6>[3.181665] [drm] radeon: 32M of GTT memory ready.
<6>[3.181700] [drm] radeon: 2 quad pipes, 1 Z pipes initialized.
<6>[3.182643] radeon :01:00.0: WB disabled
<7>[3.182662] [drm:r100_cp_init_microcode], 
<6>[3.184504] [drm] Loading R300 Microcode
<6>[3.186440] [drm] radeon: ring at 0xF0001000
<6>[3.186463] [drm] ring test succeeded in 1 usecs
<6>[3.186680] [drm] radeon: ib pool ready.
<6>[3.186738] [drm] ib test succeeded in 0 usecs
<7>[3.186878] [drm:drm_sysfs_connector_add], adding "VGA-1" to sysfs
<7>[3.186907] [drm:drm_sysfs_hotplug_event], generating hotplug event
<7>[3.186922] [drm:radeon_combios_get_tv_info], Default TV standard: NTSC
<7>[3.186924] [drm:radeon_combios_get_tv_info], 27.0 MHz TV ref clk
<7>[3.186928] [drm:radeon_legacy_get_tmds_info_from_combios], DFP table
revision: 4
<7>[3.186931] [drm:radeon_legacy_get_tmds_info_from_combios], TMDS PLL From
COMBIOS 15500 b01cb
<7>[3.186934] [drm:radeon_legacy_get_tmds_info_from_combios], TMDS PLL From
COMBIOS 2 b01cb
<7>[3.186937] [drm:radeon_legacy_get_tmds_info_from_combios], TMDS PLL From
COMBIOS 0 4e2c
<7>[3.186942] [drm:drm_sysfs_connector_add], adding "DVI-I-1" to sysfs
<7>[3.186969] [drm:drm_sysfs_hotplug_event], generating hotplug event
<7>[3.186980] [drm:radeon_combios_get_tv_info], Default TV standard: NTSC
<7>[3.186983] [drm:radeon_combios_get_tv_info], 27.0 MHz TV ref clk
<7>[3.186985] [drm:drm_sysfs_connector_add], adding "SVIDEO-1" to sysfs
<7>[3.187032] [drm:drm_sysfs_hotplug_event], generating hotplug event
<6>[3.187042] [drm] Radeon Display Connectors
<6>[3.187044] [drm] Connector 0:
<6>[3.187046] [drm]   VGA
<6>[3.187048] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
<6>[3.187050] [drm]   Encoders:
<6>[3.187052] [drm] CRT1: INTERNAL_DAC1
<6>[3.187053] [drm] Connector 1:
<6>[3.187055] [drm]   DVI-I
<6>[3.187056] [drm]   HPD1
<6>[3.187059] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
<6>[3.187060] [drm]   Encoders:
<6>[3.187062] [drm] CRT2: INTERNAL_DAC2
<6>[3.187064] [drm] DFP1: INTERNAL_TMDS1
<6>[3.187066] [drm] Connector 2:
<6>[3.187067] [drm]   S-video
<6>[3.187068] [drm]   Encoders:
<6>[3.187070] [drm] TV1: INTERNAL_DAC2
<7>[3.254137] [drm:radeon_pm_print_states], 1 Power State(s)
<7>[3.254143] [drm:radeon_pm_print_states], State 0: Default
<7>[3.254146] [drm:radeon_pm_print_states], Default
<7>[3.254148] [drm:radeon_pm_print_states], 1 Clock Mode(s)
<7>[3.254151] [drm:radeon_pm_print_states], 0 e: 378000m:
338000v: 0
<7>[3.254161] [drm:radeon_legacy_primary_dac_dpms], 
<7>[3.254164] 

[Bug 31943] drm EDID checking is too strict

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=31943

--- Comment #14 from Igor Strelnikoff  2011-05-09 
01:58:31 PDT ---
RADEON 9800 PRO AGP

Monitor DVI: NEC LCD 225WNX

xrandr --verbose
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 4096 x 4096
VGA-0 disconnected (normal left inverted right x axis y axis)
Identifier: 0x51
Timestamp:  17179
Subpixel:   no subpixels
Clones: DVI-0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
load detection: 1 (0x0001)  range:  (0,1)
DVI-0 connected 1680x1050+0+0 (0x54) normal (normal left inverted right x axis
y axis) 433mm x 270mm
Identifier: 0x52
Timestamp:  17179
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones: VGA-0
CRTC:   0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID:
000038a32f6701010101
1d120103802f1e78eaee95a3544c9926
0f5054bfef8081c0814081808bc09500
9040b300714f21399030621a274018b0
3640b10e111c00fd00384b1f
5311000a20202020202000fc004c
4344323235574e580a20202000ff
00383732303231353459420a2020005f
load detection: 1 (0x0001)  range:  (0,1)
  1680x1050 (0x54)  146.2MHz -HSync +VSync *current +preferred
h: width  1680 start 1960 end 2136 total 2240 skew0 clock   65.3KHz
v: height 1050 start 1053 end 1059 total 1089   clock   60.0Hz
  1400x1050 (0x55)  121.8MHz -HSync +VSync
h: width  1400 start 1488 end 1632 total 1864 skew0 clock   65.3KHz
v: height 1050 start 1053 end 1057 total 1089   clock   60.0Hz
  1280x1024 (0x56)  135.0MHz +HSync +VSync
h: width  1280 start 1296 end 1440 total 1688 skew0 clock   80.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock   75.0Hz
  1280x1024 (0x57)  108.0MHz +HSync +VSync
h: width  1280 start 1328 end 1440 total 1688 skew0 clock   64.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock   60.0Hz
  1440x900 (0x58)  106.5MHz -HSync +VSync
h: width  1440 start 1520 end 1672 total 1904 skew0 clock   55.9KHz
v: height  900 start  903 end  909 total  934   clock   59.9Hz
  1280x960 (0x59)  108.0MHz +HSync +VSync
h: width  1280 start 1376 end 1488 total 1800 skew0 clock   60.0KHz
v: height  960 start  961 end  964 total 1000   clock   60.0Hz
  1360x768 (0x5a)   84.8MHz -HSync +VSync
h: width  1366 start 1431 end 1567 total 1776 skew0 clock   47.7KHz
v: height  768 start  771 end  781 total  798   clock   59.8Hz
  1152x864 (0x5b)  108.0MHz +HSync +VSync
h: width  1152 start 1216 end 1344 total 1600 skew0 clock   67.5KHz
v: height  864 start  865 end  868 total  900   clock   75.0Hz
  1280x720 (0x5c)   74.4MHz -HSync +VSync
h: width  1280 start 1336 end 1472 total 1664 skew0 clock   44.7KHz
v: height  720 start  721 end  724 total  746   clock   60.0Hz
  1024x768 (0x5d)   78.8MHz +HSync +VSync
h: width  1024 start 1040 end 1136 total 1312 skew0 clock   60.1KHz
v: height  768 start  769 end  772 total  800   clock   75.1Hz
  1024x768 (0x5e)   75.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1328 skew0 clock   56.5KHz
v: height  768 start  771 end  777 total  806   clock   70.1Hz
  1024x768 (0x5f)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806   clock   60.0Hz
  832x624 (0x60)   57.3MHz -HSync -VSync
h: width   832 start  864 end  928 total 1152 skew0 clock   49.7KHz
v: height  624 start  625 end  628 total  667   clock   74.6Hz
  800x600 (0x61)   50.0MHz +HSync +VSync
h: width   800 start  856 end  976 total 1040 skew0 clock   48.1KHz
v: height  600 start  637 end  643 total  666   clock   72.2Hz
  800x600 (0x62)   49.5MHz +HSync +VSync
h: width   800 start  816 end  896 total 1056 skew0 clock   46.9KHz
v: height  600 start  601 end  604 total  625   clock   75.0Hz
  800x600 (0x63)   40.0MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock   37.9KHz
v: height  600 start  601 end  605 total  628   clock   60.3Hz
  800x600 (0x64)   36.0MHz +HSync +VSync
h: width   800 start  824 end  896 total 1024 skew0 clock   35.2KHz
v: height  

[PATCH] drm/radeon: fix cayman struct accessors.

[Alex Deucher]

On Mon, May 9, 2011 at 1:02 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> We are accessing totally the wrong struct in this case, and putting
> uninitialised values into the GPU, which it doesn't like unsurprisingly.
>
> Signed-off-by: Dave Airlie 

Reviewed-by: Alex Deucher 


> ---
> ?drivers/gpu/drm/radeon/ni.c | ? 16 
> ?1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 7aade20..e9e45ea 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -871,7 +871,7 @@ static void cayman_gpu_init(struct radeon_device *rdev)
>
> ? ? ? ?smx_dc_ctl0 = RREG32(SMX_DC_CTL0);
> ? ? ? ?smx_dc_ctl0 &= ~NUMBER_OF_SETS(0x1ff);
> - ? ? ? smx_dc_ctl0 |= NUMBER_OF_SETS(rdev->config.evergreen.sx_num_of_sets);
> + ? ? ? smx_dc_ctl0 |= NUMBER_OF_SETS(rdev->config.cayman.sx_num_of_sets);
> ? ? ? ?WREG32(SMX_DC_CTL0, smx_dc_ctl0);
>
> ? ? ? ?WREG32(SPI_CONFIG_CNTL_1, VTX_DONE_DELAY(4) | 
> CRC_SIMD_ID_WADDR_DISABLE);
> @@ -887,20 +887,20 @@ static void cayman_gpu_init(struct radeon_device *rdev)
>
> ? ? ? ?WREG32(TA_CNTL_AUX, DISABLE_CUBE_ANISO);
>
> - ? ? ? WREG32(SX_EXPORT_BUFFER_SIZES, 
> (COLOR_BUFFER_SIZE((rdev->config.evergreen.sx_max_export_size / 4) - 1) |
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> POSITION_BUFFER_SIZE((rdev->config.evergreen.sx_max_export_pos_size / 4) - 1) 
> |
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> SMX_BUFFER_SIZE((rdev->config.evergreen.sx_max_export_smx_size / 4) - 1)));
> + ? ? ? WREG32(SX_EXPORT_BUFFER_SIZES, 
> (COLOR_BUFFER_SIZE((rdev->config.cayman.sx_max_export_size / 4) - 1) |
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> POSITION_BUFFER_SIZE((rdev->config.cayman.sx_max_export_pos_size / 4) - 1) |
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> SMX_BUFFER_SIZE((rdev->config.cayman.sx_max_export_smx_size / 4) - 1)));
>
> - ? ? ? WREG32(PA_SC_FIFO_SIZE, 
> (SC_PRIM_FIFO_SIZE(rdev->config.evergreen.sc_prim_fifo_size) |
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> ?SC_HIZ_TILE_FIFO_SIZE(rdev->config.evergreen.sc_hiz_tile_fifo_size) |
> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> ?SC_EARLYZ_TILE_FIFO_SIZE(rdev->config.evergreen.sc_earlyz_tile_fifo_size)));
> + ? ? ? WREG32(PA_SC_FIFO_SIZE, 
> (SC_PRIM_FIFO_SIZE(rdev->config.cayman.sc_prim_fifo_size) |
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> ?SC_HIZ_TILE_FIFO_SIZE(rdev->config.cayman.sc_hiz_tile_fifo_size) |
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 
> ?SC_EARLYZ_TILE_FIFO_SIZE(rdev->config.cayman.sc_earlyz_tile_fifo_size)));
>
>
> ? ? ? ?WREG32(VGT_NUM_INSTANCES, 1);
>
> ? ? ? ?WREG32(CP_PERFMON_CNTL, 0);
>
> - ? ? ? WREG32(SQ_MS_FIFO_SIZES, (CACHE_FIFO_SIZE(16 * 
> rdev->config.evergreen.sq_num_cf_insts) |
> + ? ? ? WREG32(SQ_MS_FIFO_SIZES, (CACHE_FIFO_SIZE(16 * 
> rdev->config.cayman.sq_num_cf_insts) |
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?FETCH_FIFO_HIWATER(0x4) |
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DONE_FIFO_HIWATER(0xe0) |
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ALU_UPDATE_FIFO_HIWATER(0x8)));
> --
> 1.7.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 36527] [wine] Wolfenstein: Failed to translate rgb instruction.

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=36527

Tom Stellard  changed:

   What|Removed |Added

  Attachment #46071|0   |1
is obsolete||

--- Comment #13 from Tom Stellard  2011-05-09 00:11:49 
PDT ---
Created an attachment (id=46461)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46461
 Review: https://bugs.freedesktop.org/review?bug=36527=46461

Fix v4

I found a bug in the previous patch (v3).  Can you try this new one and make
sure it still works.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: [Mesa-dev] mesa-7.10.1-libdrm-required.patch

[Brian Paul]

On Tue, Apr 5, 2011 at 6:15 PM, Alex Buell alex.bu...@munted.org.uk wrote:
 The patch below is needed to prevent building mesa with libdrm 
 2.4.24.

 Regards,
 Alex

 diff --git a/configure.ac b/configure.ac
 index 6662b8a..ad9eb01 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -18,7 +18,7 @@ AC_CONFIG_AUX_DIR([bin])
  AC_CANONICAL_HOST

  dnl Versions for external dependencies
 -LIBDRM_REQUIRED=2.4.15
 +LIBDRM_REQUIRED=2.4.24
  LIBDRM_RADEON_REQUIRED=2.4.17
  DRI2PROTO_REQUIRED=2.1
  GLPROTO_REQUIRED=1.4.11


Committed.  Thanks.

-Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915/kms/backlight-combo mode problem

[Takashi Iwai]

At Sat, 7 May 2011 22:22:40 +0200,
Melchior FRANZ wrote:
 
 * Melchior FRANZ -- Friday 06 May 2011:
  last patch prevents the backlight from being turned off, but it also
  breaks the brightness adjustment keys at runtime with acpi_osi=Linux.
 
 It has turned out that acpi key events seem to be handled correctly
 and even the state of /sys/class/backlight/acer-wmi/brightness is
 updated accordingly. The only problem is that this maintained
 brightness state isn't applied to the actual backlight. It remains
 at highest level. Google pointed me to this workaround for another
 Acer notebook:
 
   
 https://help.ubuntu.com/community/AspireTimeline/Fixes#Alternative%20fix%20for%2010.10
 
 This uses the acpid to write the brightness value to the display
 using setpci. And this works on my notebook as well (Acer Travelmate
 5735Z-452G32Mnss).

Then we miss something.  With the hack above, you are doing nothing
but writing LBPC register value externally from setpci.  It implies
that the write to LBPC basically works on your machine.


Takashi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 31943] drm EDID checking is too strict

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=31943

--- Comment #14 from Igor Strelnikoff freihe...@mail.ru 2011-05-09 01:58:31 
PDT ---
RADEON 9800 PRO AGP

Monitor DVI: NEC LCD 225WNX

xrandr --verbose
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 4096 x 4096
VGA-0 disconnected (normal left inverted right x axis y axis)
Identifier: 0x51
Timestamp:  17179
Subpixel:   no subpixels
Clones: DVI-0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
load detection: 1 (0x0001)  range:  (0,1)
DVI-0 connected 1680x1050+0+0 (0x54) normal (normal left inverted right x axis
y axis) 433mm x 270mm
Identifier: 0x52
Timestamp:  17179
Subpixel:   horizontal rgb
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones: VGA-0
CRTC:   0
CRTCs:  0 1
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID:
000038a32f6701010101
1d120103802f1e78eaee95a3544c9926
0f5054bfef8081c0814081808bc09500
9040b300714f21399030621a274018b0
3640b10e111c00fd00384b1f
5311000a20202020202000fc004c
4344323235574e580a20202000ff
00383732303231353459420a2020005f
load detection: 1 (0x0001)  range:  (0,1)
  1680x1050 (0x54)  146.2MHz -HSync +VSync *current +preferred
h: width  1680 start 1960 end 2136 total 2240 skew0 clock   65.3KHz
v: height 1050 start 1053 end 1059 total 1089   clock   60.0Hz
  1400x1050 (0x55)  121.8MHz -HSync +VSync
h: width  1400 start 1488 end 1632 total 1864 skew0 clock   65.3KHz
v: height 1050 start 1053 end 1057 total 1089   clock   60.0Hz
  1280x1024 (0x56)  135.0MHz +HSync +VSync
h: width  1280 start 1296 end 1440 total 1688 skew0 clock   80.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock   75.0Hz
  1280x1024 (0x57)  108.0MHz +HSync +VSync
h: width  1280 start 1328 end 1440 total 1688 skew0 clock   64.0KHz
v: height 1024 start 1025 end 1028 total 1066   clock   60.0Hz
  1440x900 (0x58)  106.5MHz -HSync +VSync
h: width  1440 start 1520 end 1672 total 1904 skew0 clock   55.9KHz
v: height  900 start  903 end  909 total  934   clock   59.9Hz
  1280x960 (0x59)  108.0MHz +HSync +VSync
h: width  1280 start 1376 end 1488 total 1800 skew0 clock   60.0KHz
v: height  960 start  961 end  964 total 1000   clock   60.0Hz
  1360x768 (0x5a)   84.8MHz -HSync +VSync
h: width  1366 start 1431 end 1567 total 1776 skew0 clock   47.7KHz
v: height  768 start  771 end  781 total  798   clock   59.8Hz
  1152x864 (0x5b)  108.0MHz +HSync +VSync
h: width  1152 start 1216 end 1344 total 1600 skew0 clock   67.5KHz
v: height  864 start  865 end  868 total  900   clock   75.0Hz
  1280x720 (0x5c)   74.4MHz -HSync +VSync
h: width  1280 start 1336 end 1472 total 1664 skew0 clock   44.7KHz
v: height  720 start  721 end  724 total  746   clock   60.0Hz
  1024x768 (0x5d)   78.8MHz +HSync +VSync
h: width  1024 start 1040 end 1136 total 1312 skew0 clock   60.1KHz
v: height  768 start  769 end  772 total  800   clock   75.1Hz
  1024x768 (0x5e)   75.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1328 skew0 clock   56.5KHz
v: height  768 start  771 end  777 total  806   clock   70.1Hz
  1024x768 (0x5f)   65.0MHz -HSync -VSync
h: width  1024 start 1048 end 1184 total 1344 skew0 clock   48.4KHz
v: height  768 start  771 end  777 total  806   clock   60.0Hz
  832x624 (0x60)   57.3MHz -HSync -VSync
h: width   832 start  864 end  928 total 1152 skew0 clock   49.7KHz
v: height  624 start  625 end  628 total  667   clock   74.6Hz
  800x600 (0x61)   50.0MHz +HSync +VSync
h: width   800 start  856 end  976 total 1040 skew0 clock   48.1KHz
v: height  600 start  637 end  643 total  666   clock   72.2Hz
  800x600 (0x62)   49.5MHz +HSync +VSync
h: width   800 start  816 end  896 total 1056 skew0 clock   46.9KHz
v: height  600 start  601 end  604 total  625   clock   75.0Hz
  800x600 (0x63)   40.0MHz +HSync +VSync
h: width   800 start  840 end  968 total 1056 skew0 clock   37.9KHz
v: height  600 start  601 end  605 total  628   clock   60.3Hz
  800x600 (0x64)   36.0MHz +HSync +VSync
h: width   800 start  824 end  896 total 1024 skew0 clock   35.2KHz
 

[Bug 31943] drm EDID checking is too strict

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=31943

--- Comment #15 from Igor Strelnikoff freihe...@mail.ru 2011-05-09 01:59:30 
PDT ---
6[3.130551] [drm] Initialized drm 1.1.0 20060810
6[3.177278] [drm] radeon defaulting to kernel modesetting.
6[3.177282] [drm] radeon kernel modesetting enabled.
7[3.177297] [drm:drm_init], 
7[3.178026] checking generic (e000 100) vs hw (e000 800)
3[3.178029] fb: conflicting fb hw usage radeondrmfb vs VESA VGA -
removing generic driver
4[3.178056] Console: switching to colour dummy device 80x25
7[3.178624] [drm:drm_get_pci_dev], 
4[3.178748] ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16
6[3.178761] radeon :01:00.0: PCI INT A - Link[APC5] - GSI 16
(level, low) - IRQ 16
7[3.180391] [drm:drm_get_minor], 
7[3.180620] [drm:drm_get_minor], new minor assigned 64
7[3.180623] [drm:drm_get_minor], 
7[3.180711] [drm:drm_get_minor], new minor assigned 0
6[3.180724] [drm] initializing kernel modesetting (R350 0x1002:0x4E48).
6[3.180800] [drm] register mmio base: 0xF300
6[3.180802] [drm] register mmio size: 65536
7[3.181323] [drm:radeon_get_bios], COMBIOS detected
6[3.181345] agpgart-amd64 :00:00.0: AGP 3.0 bridge
6[3.181361] agpgart-amd64 :00:00.0: putting AGP V3 device into 8x
mode
6[3.181387] radeon :01:00.0: putting AGP V3 device into 8x mode
6[3.181406] radeon :01:00.0: GTT: 32M 0xF000 - 0xF1FF
6[3.181411] [drm] Generation 1 PCI interface in multifunction mode
6[3.181413] [drm] Limiting VRAM to one aperture
6[3.181418] radeon :01:00.0: VRAM: 128M 0xE000 -
0xE7FF (128M used)
7[3.181427] [drm:drm_irq_install], irq=16
6[3.181449] [drm] radeon: irq initialized.
6[3.181559] [drm] Detected VRAM RAM=128M, BAR=128M
6[3.181564] [drm] RAM width 256bits DDR
6[3.181637] [TTM] Zone  kernel: Available graphics memory: 438570 kiB.
6[3.181640] [TTM] Zone highmem: Available graphics memory: 506126 kiB.
6[3.181642] [TTM] Initializing pool allocator.
6[3.181662] [drm] radeon: 128M of VRAM memory ready
6[3.181665] [drm] radeon: 32M of GTT memory ready.
6[3.181700] [drm] radeon: 2 quad pipes, 1 Z pipes initialized.
6[3.182643] radeon :01:00.0: WB disabled
7[3.182662] [drm:r100_cp_init_microcode], 
6[3.184504] [drm] Loading R300 Microcode
6[3.186440] [drm] radeon: ring at 0xF0001000
6[3.186463] [drm] ring test succeeded in 1 usecs
6[3.186680] [drm] radeon: ib pool ready.
6[3.186738] [drm] ib test succeeded in 0 usecs
7[3.186878] [drm:drm_sysfs_connector_add], adding VGA-1 to sysfs
7[3.186907] [drm:drm_sysfs_hotplug_event], generating hotplug event
7[3.186922] [drm:radeon_combios_get_tv_info], Default TV standard: NTSC
7[3.186924] [drm:radeon_combios_get_tv_info], 27.0 MHz TV ref clk
7[3.186928] [drm:radeon_legacy_get_tmds_info_from_combios], DFP table
revision: 4
7[3.186931] [drm:radeon_legacy_get_tmds_info_from_combios], TMDS PLL From
COMBIOS 15500 b01cb
7[3.186934] [drm:radeon_legacy_get_tmds_info_from_combios], TMDS PLL From
COMBIOS 2 b01cb
7[3.186937] [drm:radeon_legacy_get_tmds_info_from_combios], TMDS PLL From
COMBIOS 0 4e2c
7[3.186942] [drm:drm_sysfs_connector_add], adding DVI-I-1 to sysfs
7[3.186969] [drm:drm_sysfs_hotplug_event], generating hotplug event
7[3.186980] [drm:radeon_combios_get_tv_info], Default TV standard: NTSC
7[3.186983] [drm:radeon_combios_get_tv_info], 27.0 MHz TV ref clk
7[3.186985] [drm:drm_sysfs_connector_add], adding SVIDEO-1 to sysfs
7[3.187032] [drm:drm_sysfs_hotplug_event], generating hotplug event
6[3.187042] [drm] Radeon Display Connectors
6[3.187044] [drm] Connector 0:
6[3.187046] [drm]   VGA
6[3.187048] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
6[3.187050] [drm]   Encoders:
6[3.187052] [drm] CRT1: INTERNAL_DAC1
6[3.187053] [drm] Connector 1:
6[3.187055] [drm]   DVI-I
6[3.187056] [drm]   HPD1
6[3.187059] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
6[3.187060] [drm]   Encoders:
6[3.187062] [drm] CRT2: INTERNAL_DAC2
6[3.187064] [drm] DFP1: INTERNAL_TMDS1
6[3.187066] [drm] Connector 2:
6[3.187067] [drm]   S-video
6[3.187068] [drm]   Encoders:
6[3.187070] [drm] TV1: INTERNAL_DAC2
7[3.254137] [drm:radeon_pm_print_states], 1 Power State(s)
7[3.254143] [drm:radeon_pm_print_states], State 0: Default
7[3.254146] [drm:radeon_pm_print_states], Default
7[3.254148] [drm:radeon_pm_print_states], 1 Clock Mode(s)
7[3.254151] [drm:radeon_pm_print_states], 0 e: 378000m:
338000v: 0
7[3.254161] [drm:radeon_legacy_primary_dac_dpms], 
7[3.254164] [drm:radeon_legacy_tv_dac_dpms], 
7[3.254170] [drm:radeon_legacy_tmds_int_dpms], 
7[3.254174] [drm:drm_vblank_get], enabling vblank on crtc 0, ret: 0

Re: i915/kms/backlight-combo mode problem

[Takashi Iwai]

At Mon, 09 May 2011 02:50:50 -0600,
Joey Lee wrote:
 
 Add Cc. Michael Chang for he is our i915 expert.
 
 Hi Melchior, 
 
 於 日，2011-05-08 於 16:05 +0200，Melchior FRANZ 提到：
  
   Does it work to you direct control brightness by access
   by /sys/class/backlight/acer-wmi/brightness ?
  
  No. A number written to this virtual file is accepted and remembered,
  but it doesn't actually change the brightness. It takes setpci to do
  that. 
  
 
 I thought the video driver still is the KEY component for backlight
 issues, need fix the problem in video driver first.
 
  
   
   As I remember, use setpci to control brightness is not recommended
   because BIOS or ACPI will also touch brightness level. That will be
   better control brightness by the function that was provided by BIOS. 
   e.g. ACPI or WMI interface, or direct control by EC.
  
  Well, sounds plausible. And I wouldn't do it if it weren't the only
  way at the moment.  :-)
  
  
  
   That means that will be better fix your Fn key control brightness like
   before, you just need press Fn key to change brightness and don't need
   have any workaround.
  
  OK. I have added a lot of debug messages to intel_panel.c yesterday.
  All it told me was that it seems to work correctly wiht acpi_osi=Linux.
  Except that it doesn't actually change the brightness. Without acpi_osi
  the functions aren't called at all and none of my messages showed up.
  
 
 I traced _Q event in your DSDT, when acpi_osi=Linux, it run the Intel
 OpRegion logic for change brightness. And, finally, intel_opregion will
 access the function the were provided by intel_panel. So, the problem
 still back to intel_panel.
 
 After discuss with Michael chang, we thought there have problem in your
 brightness level after add combination mode:
 
 vi driver/gpu/drm/i915/intel_panel.c
 
 void intel_panel_set_backlight(struct drm_device *dev, u32 level)
 {
 struct drm_i915_private *dev_priv = dev-dev_private;
 u32 tmp;
 
 DRM_DEBUG_DRIVER(set backlight PWM = %d\n, level);
 
 if (HAS_PCH_SPLIT(dev))
 return intel_pch_panel_set_backlight(dev, level);
 
 if (is_backlight_combination_mode(dev)){
 u32 max = intel_panel_get_max_backlight(dev);
 u8 lbpc;
 
 lbpc = level * 0xfe / max + 1;
 level /= lbpc;/* maybe the level 
 changed by lbpc */
 pci_write_config_byte(dev-pdev, PCI_LBPC, lbpc);
 }
 
 tmp = I915_READ(BLC_PWM_CTL);
 if (IS_PINEVIEW(dev)) {
 tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
 level = 1;
 } else
 tmp = ~BACKLIGHT_DUTY_CYCLE_MASK;
 I915_WRITE(BLC_PWM_CTL, tmp | level);
 }
 
 We need to know some run time value when intel_panel_set_backlight call by 
 funciton key.

Yes, that'll help understanding.

 Please help to apply the attached debug patch to intel_panel.c then attached 
 dmesg.

The patch has an obvious typo :)
Also, we should track the value in intel_panel_get_backlight(), too.


Takashi


   Looks like current status is we try to fix bko#31522 but the patch
   causes your brightness no work by press Fn key even with acpi_osi=Linux.
   Does it right?
  
  The history is: with acpi_osi=Linux everything worked with 2.6.38-rc8.
  With 2.6.38 the screen stayed black. The patch that only ignored lbpc=0
  worked (IIRC) including key adjustment. Later patches broke keys.
  
  
  
 replace acpi_osi=Linux by acpi_osi=!Windows 2006
   
   Does it also works to you for backlight control?
  
  No, doesn't work.
  
 
 We can test the acpi_osi=!Windows 2006 again after we fix the i915's
 problem.
 
 
 Thank's
 Joey Lee
 
 The following is debug patch, and please add kernel parameter
 drm.debug=0x02 :
 
 diff --git a/drivers/gpu/drm/i915/intel_panel.c 
 b/drivers/gpu/drm/i915/intel_panel.c
 index f8f86e5..f62dbd9 100644
 --- a/drivers/gpu/drm/i915/intel_panel.c
 +++ b/drivers/gpu/drm/i915/intel_panel.c
 @@ -236,17 +236,22 @@ void intel_panel_set_backlight(struct drm_device *dev, 
 u32 level)
   u32 max = intel_panel_get_max_backlight(dev);
   u8 lbpc;
  
 + DRM_DEBUG_DRIVER(set backlight max = % lbpc = 
 level * 0xfe / max + 1;
 + DRM_DEBUG_DRIVER(set backlight lbpc = %d\n, lbpc);
   level /= lbpc;
   pci_write_config_byte(dev-pdev, PCI_LBPC, lbpc);
   }
  
   tmp = I915_READ(BLC_PWM_CTL);
 + DRM_DEBUG_DRIVER(set backlight tmp(1) = %d\n, tmp);
   if (IS_PINEVIEW(dev)) {
   tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
   level = 1;
   } else
   tmp = ~BACKLIGHT_DUTY_CYCLE_MASK;
 + DRM_DEBUG_DRIVER(set backlight tmp(2) = %d\n, tmp);
 + DRM_DEBUG_DRIVER(set backlight level = %d\n, level);
   I915_WRITE(BLC_PWM_CTL, tmp | level);
  }
  
 
 
___
dri-devel mailing 

[Bug 34740] Invalid EDID on NEC 225WNX

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=34740

--- Comment #13 from Igor Strelnikoff freihe...@mail.ru 2011-05-09 02:21:30 
PDT ---
[   23.745086] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   24.438301] start_kdeinit (2339): /proc/2339/oom_adj is deprecated, please
use /proc/2339/oom_score_adj instead.
[   30.772338] ata3.00: configured for UDMA/133
[   30.772344] ata3: EH complete
[   31.570015] eth0: no IPv6 routers present
[   31.885279] EXT4-fs (sda2): re-mounted. Opts: acl,user_xattr,commit=0
[   31.979079] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   32.044963] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   32.140389] EXT4-fs (sda3): re-mounted. Opts: commit=0
[   43.879049] i2c i2c-0: readbytes: ack/nak timeout
[   43.879122] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   52.805480] bootsplash: status on console 0 changed to on
[  209.310829] fuse init (API version 7.15)
[  401.118127] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 31943] drm EDID checking is too strict

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=31943

--- Comment #16 from Igor Strelnikoff freihe...@mail.ru 2011-05-09 02:27:06 
PDT ---
Should I expect to fix this bug? I think this regression

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 31943] drm EDID checking is too strict

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=31943

--- Comment #17 from Igor Strelnikoff freihe...@mail.ru 2011-05-09 02:29:17 
PDT ---
[   23.745086] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   24.438301] start_kdeinit (2339): /proc/2339/oom_adj is deprecated, please
use /proc/2339/oom_score_adj instead.
[   30.772338] ata3.00: configured for UDMA/133
[   30.772344] ata3: EH complete
[   31.570015] eth0: no IPv6 routers present
[   31.885279] EXT4-fs (sda2): re-mounted. Opts: acl,user_xattr,commit=0
[   31.979079] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   32.044963] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   32.140389] EXT4-fs (sda3): re-mounted. Opts: commit=0
[   43.879049] i2c i2c-0: readbytes: ack/nak timeout
[   43.879122] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
[   52.805480] bootsplash: status on console 0 changed to on
[  209.310829] fuse init (API version 7.15)
[  401.118127] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID

Kernel 2.6.37.6 i586

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915/kms/backlight-combo mode problem

[Joey Lee]

於 一，2011-05-09 於 11:00 +0200，Takashi Iwai 提到：
 At Mon, 09 May 2011 02:50:50 -0600,
 Joey Lee wrote:
  
  We need to know some run time value when intel_panel_set_backlight call by 
  funciton key.
 
 Yes, that'll help understanding.
 
  Please help to apply the attached debug patch to intel_panel.c then 
  attached dmesg.
 
 The patch has an obvious typo :)
 Also, we should track the value in intel_panel_get_backlight(), too.
 
 
 Takashi
 

Thank's for Takashi's review and sorry for my typo. 
Follow Takashi's suggestion, I added a debug message in get_backlight,
the following is new debug patch:

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index f8f86e5..9695840 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -199,6 +199,7 @@ u32 intel_panel_get_backlight(struct drm_device *dev)
val = I915_READ(BLC_PWM_CPU_CTL)  BACKLIGHT_DUTY_CYCLE_MASK;
} else {
val = I915_READ(BLC_PWM_CTL)  BACKLIGHT_DUTY_CYCLE_MASK;
+   DRM_DEBUG_DRIVER(get backlight val = %d\n, val);
if (IS_PINEVIEW(dev))
val = 1;
 
@@ -236,17 +237,22 @@ void intel_panel_set_backlight(struct drm_device *dev, 
u32 level)
u32 max = intel_panel_get_max_backlight(dev);
u8 lbpc;
 
+   DRM_DEBUG_DRIVER(set backlight max = %d\n, max);
lbpc = level * 0xfe / max + 1;
+   DRM_DEBUG_DRIVER(set backlight lbpc = %d\n, lbpc);
level /= lbpc;
pci_write_config_byte(dev-pdev, PCI_LBPC, lbpc);
}
 
tmp = I915_READ(BLC_PWM_CTL);
+   DRM_DEBUG_DRIVER(set backlight tmp(1) = %d\n, tmp);
if (IS_PINEVIEW(dev)) {
tmp = ~(BACKLIGHT_DUTY_CYCLE_MASK - 1);
level = 1;
} else
tmp = ~BACKLIGHT_DUTY_CYCLE_MASK;
+   DRM_DEBUG_DRIVER(set backlight tmp(2) = %d\n, tmp);
+   DRM_DEBUG_DRIVER(set backlight level = %d\n, level);
I915_WRITE(BLC_PWM_CTL, tmp | level);
 }
 


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36554] Amnesia game causes black screen or kernel locks

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36554

--- Comment #6 from Hicham HAOUARI hicham.haou...@gmail.com 2011-05-09 
02:43:12 PDT ---
The game runs fine for me with 1GB of RAM on Fedora 14.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #1 from Dymchenko Bogdan dmboh...@gmail.com 2011-05-09 02:47:43 
PDT ---
When I increase command buffer to 32 kb via driconf - game starts perfectly
with hardware tcl. But than it's exited with error  
warcraft\war3.exe: radeon_common.c:1250: rcommonEnsureCmdBufSpace: Assertion
`rmesa-cmdbuf.cs-cdw' failed.
Then i try manually edit ~/.drirc and change command buffer to 34 kb and game
runs without errors. 
So this bug has an workaround, but i think that it's need to be fixed

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Joey Lee -- Monday 09 May 2011:
 The following is debug patch, and please add kernel parameter
 drm.debug=0x02 :

The result is with acpi_osi=Linux:


boot phase:
[3.310274] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310280] [drm:intel_panel_get_backlight], get backlight PWM = 2890
[3.310615] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310617] [drm:intel_panel_get_backlight], get backlight PWM = 2890
[3.310619] [drm:intel_panel_set_backlight], set backlight PWM = 0
[3.310622] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930
[3.310624] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[3.310626] [drm:intel_panel_set_backlight], set backlight level = 0

[3.641522] [drm:intel_panel_set_backlight], set backlight PWM = 2890
[3.641525] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399040
[3.641527] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[3.641529] [drm:intel_panel_set_backlight], set backlight level = 2890

[   11.410563] video LNXVIDEO:01: Restoring backlight state



brightness up:
   [no output]



brightness down:
[  152.697127] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  152.697136] [drm:intel_panel_set_backlight], set backlight PWM = 283
[  152.697141] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401930
[  152.697146] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  152.697150] [drm:intel_panel_set_backlight], set backlight level = 283

[  166.720631] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  166.720640] [drm:intel_panel_set_backlight], set backlight PWM = 578
[  166.720645] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399323
[  166.720649] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  166.720654] [drm:intel_panel_set_backlight], set backlight level = 578

[  178.091776] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  178.091784] [drm:intel_panel_set_backlight], set backlight PWM = 861
[  178.091789] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399618
[  178.091793] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  178.091797] [drm:intel_panel_set_backlight], set backlight level = 861

[  188.888370] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  188.888379] [drm:intel_panel_set_backlight], set backlight PWM = 1156
[  188.888383] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189399901
[  188.888388] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  188.888392] [drm:intel_panel_set_backlight], set backlight level = 1156

[  196.411657] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  196.411665] [drm:intel_panel_set_backlight], set backlight PWM = 1439
[  196.411670] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400196
[  196.411674] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  196.411678] [drm:intel_panel_set_backlight], set backlight level = 1439

[  201.256229] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  201.256238] [drm:intel_panel_set_backlight], set backlight PWM = 1734
[  201.256243] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400479
[  201.256247] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  201.256252] [drm:intel_panel_set_backlight], set backlight level = 1734

[  206.939838] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  206.939846] [drm:intel_panel_set_backlight], set backlight PWM = 2017
[  206.939851] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189400774
[  206.939856] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  206.939860] [drm:intel_panel_set_backlight], set backlight level = 2017

[  213.779732] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  213.779740] [drm:intel_panel_set_backlight], set backlight PWM = 2312
[  213.779744] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401057
[  213.779749] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  213.779753] [drm:intel_panel_set_backlight], set backlight level = 2312

[  222.583806] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  222.583814] [drm:intel_panel_set_backlight], set backlight PWM = 2595
[  222.583819] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401352
[  222.583824] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  222.583828] [drm:intel_panel_set_backlight], set backlight level = 2595

[  229.345860] [drm:intel_panel_get_max_backlight], max backlight PWM = 2890
[  229.345870] [drm:intel_panel_set_backlight], set backlight PWM = 2595
[  229.345874] [drm:intel_panel_set_backlight], set backlight tmp(1) = 189401635
[  229.345879] [drm:intel_panel_set_backlight], set backlight tmp(2) = 189399040
[  229.345883] 

[Bug 36934] screen corruption after running a game through wine

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36934

--- Comment #1 from Michel Dänzer mic...@daenzer.net 2011-05-09 04:41:10 PDT 
---
Please attach the full Xorg.0.log and the output of dmesg and glxinfo.

This is probably a driver issue.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 34102] radeon drm/kms: please use suspend/hibernate notifiers for allocating memory in suspend routines

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=34102





--- Comment #9 from Martin Steigerwald mar...@lichtvoll.de  2011-05-09 
12:15:32 ---
I now had a hang a preallocation (unfortunately before I came around to compile
with your patch from bug 30492). I raised reserved size to 4 MiB for now. Lets
see how that goes. If it works, then I might go back to 2 MiB or even less in
order to trigger bug 30492 with the patch from there compiled in.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms gallium

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36952

--- Comment #4 from dri tester writemeand...@hotmail.com 2011-05-09 06:22:56 
PDT ---
But if I downgrade to mesa 7.10.2, I am still using llvm 2.9 and the
crackberg screensaver works correctly, so that would point to mesa-git
being the problem for me.  I cannot compile mesa-git without llvm as the
build process halts and complains that r300 gallium requires llvm to
build.  There are three gentoo patches that get applied on top of the
mesa 7.10.2-r1 build, I haven't looked at what they do yet.

(In reply to comment #2)
 I have some problem, and i have  ATI RS482 too, but i think it was the fault
 llvm, with out llvm or  2.9 , all woks fine, with llvm  2.8  openarena,
 urbanterror and some xscreensaver segfault. see
 https://bugs.freedesktop.org/show_bug.cgi?id=36738
 I make backtrace with crackberg.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms gallium

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36952

--- Comment #5 from dri tester writemeand...@hotmail.com 2011-05-09 06:28:19 
PDT ---
I will try to bisect.  I have to figure out how to install mesa-git without the
ebuild (and without messing up my dependencies), or is there a way to pass
commit tags to 'emerge' or specify in the ebuild?  Either way once I figure
that out I will bisect mesa.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #2 from Alex Deucher ag...@yahoo.com 2011-05-09 06:34:24 PDT ---
Please attach your xorg log, dmesg output, and glxinfo output.  Some of the
commands that are added mostly likely for the tcl-related registers are not
properly accounted for.  I'd start with r200EnsureEmitSize() in r200_tcl.c and
make sure it's properly accounting for all the state that needs to be emitted. 
Print out what size it expects vs. what size gets emitted for each bit of state
and track down where the count is off.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #3 from Dymchenko Bogdan dmboh...@gmail.com 2011-05-09 06:37:56 
PDT ---
Created an attachment (id=46481)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46481)
dmesg output

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #4 from Dymchenko Bogdan dmboh...@gmail.com 2011-05-09 06:38:19 
PDT ---
Created an attachment (id=46482)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46482)
glxinfo output

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #5 from Dymchenko Bogdan dmboh...@gmail.com 2011-05-09 06:38:39 
PDT ---
Created an attachment (id=46483)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46483)
xorg log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #7 from Dymchenko Bogdan dmboh...@gmail.com 2011-05-09 06:48:10 
PDT ---
(In reply to comment #2)
 Please attach your xorg log, dmesg output, and glxinfo output.  Some of the
 commands that are added mostly likely for the tcl-related registers are not
 properly accounted for.  I'd start with r200EnsureEmitSize() in r200_tcl.c and
 make sure it's properly accounting for all the state that needs to be 
 emitted. 
 Print out what size it expects vs. what size gets emitted for each bit of 
 state
 and track down where the count is off.

and one moment about  I'd start with r200EnsureEmitSize() in r200_tcl.c
rv200 is an R100-based chipset, so driver is r100

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #8 from Alex Deucher ag...@yahoo.com 2011-05-09 06:57:17 PDT ---
(In reply to comment #7)
 and one moment about  I'd start with r200EnsureEmitSize() in r200_tcl.c
 rv200 is an R100-based chipset, so driver is r100

radeonEnsureEmitSize() in radeon_tcl.c is called from radeon_run_tcl_render().
radeonEnsureEmitSize() walks through the pending state to make sure it will all
fit in the current command buffer, but it appears to be missing some additional
state that's being emitted.  If you run the game from the terminal, it should
print out a warning:
   if (emit_end  rmesa-radeon.cmdbuf.cs-cdw)
  WARN_ONCE(Rendering was %d commands larger than predicted size.
   We might overflow  command buffer.\n, rmesa-radeon.cmdbuf.cs-cdw
- emit_end);


Most likely:
radeonEmitArrays()
radeonEmitEltPrimitive()
radeonEmitPrimitive()
is emitting more state than radeonEnsureEmitSize() thinks it should.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36608] Corrupt GL rendering

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36608

--- Comment #1 from Michel Dänzer mic...@daenzer.net 2011-05-09 06:57:44 PDT 
---
Does current Git master work better? At least some of the Gallium code was not
detecting the endianness of this architecture correctly.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915/kms/backlight-combo mode problem

[Michael Chang]

From the log, it looks like is_backlight_combination_mode is evaluated false
which contradicts with the topic we are discussed. Regardless of the
combination_mode, the log seems to work ..  weird.

2011/5/9 Melchior FRANZ melchior.fr...@gmail.com

 * Joey Lee -- Monday 09 May 2011:
  The following is debug patch, and please add kernel parameter
  drm.debug=0x02 :

 The result is with acpi_osi=Linux:


 boot phase:
 [3.310274] [drm:intel_panel_get_backlight], get backlight val = 2890
 [3.310280] [drm:intel_panel_get_backlight], get backlight PWM = 2890
 [3.310615] [drm:intel_panel_get_backlight], get backlight val = 2890
 [3.310617] [drm:intel_panel_get_backlight], get backlight PWM = 2890
 [3.310619] [drm:intel_panel_set_backlight], set backlight PWM = 0
 [3.310622] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189401930
 [3.310624] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [3.310626] [drm:intel_panel_set_backlight], set backlight level = 0

 [3.641522] [drm:intel_panel_set_backlight], set backlight PWM = 2890
 [3.641525] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189399040
 [3.641527] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [3.641529] [drm:intel_panel_set_backlight], set backlight level = 2890

 [   11.410563] video LNXVIDEO:01: Restoring backlight state



 brightness up:
   [no output]



 brightness down:
 [  152.697127] [drm:intel_panel_get_max_backlight], max backlight PWM =
 2890
 [  152.697136] [drm:intel_panel_set_backlight], set backlight PWM = 283
 [  152.697141] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189401930
 [  152.697146] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [  152.697150] [drm:intel_panel_set_backlight], set backlight level = 283

 [  166.720631] [drm:intel_panel_get_max_backlight], max backlight PWM =
 2890
 [  166.720640] [drm:intel_panel_set_backlight], set backlight PWM = 578
 [  166.720645] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189399323
 [  166.720649] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [  166.720654] [drm:intel_panel_set_backlight], set backlight level = 578

 [  178.091776] [drm:intel_panel_get_max_backlight], max backlight PWM =
 2890
 [  178.091784] [drm:intel_panel_set_backlight], set backlight PWM = 861
 [  178.091789] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189399618
 [  178.091793] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [  178.091797] [drm:intel_panel_set_backlight], set backlight level = 861

 [  188.888370] [drm:intel_panel_get_max_backlight], max backlight PWM =
 2890
 [  188.888379] [drm:intel_panel_set_backlight], set backlight PWM = 1156
 [  188.888383] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189399901
 [  188.888388] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [  188.888392] [drm:intel_panel_set_backlight], set backlight level = 1156

 [  196.411657] [drm:intel_panel_get_max_backlight], max backlight PWM =
 2890
 [  196.411665] [drm:intel_panel_set_backlight], set backlight PWM = 1439
 [  196.411670] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189400196
 [  196.411674] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [  196.411678] [drm:intel_panel_set_backlight], set backlight level = 1439

 [  201.256229] [drm:intel_panel_get_max_backlight], max backlight PWM =
 2890
 [  201.256238] [drm:intel_panel_set_backlight], set backlight PWM = 1734
 [  201.256243] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189400479
 [  201.256247] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [  201.256252] [drm:intel_panel_set_backlight], set backlight level = 1734

 [  206.939838] [drm:intel_panel_get_max_backlight], max backlight PWM =
 2890
 [  206.939846] [drm:intel_panel_set_backlight], set backlight PWM = 2017
 [  206.939851] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189400774
 [  206.939856] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [  206.939860] [drm:intel_panel_set_backlight], set backlight level = 2017

 [  213.779732] [drm:intel_panel_get_max_backlight], max backlight PWM =
 2890
 [  213.779740] [drm:intel_panel_set_backlight], set backlight PWM = 2312
 [  213.779744] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189401057
 [  213.779749] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [  213.779753] [drm:intel_panel_set_backlight], set backlight level = 2312

 [  222.583806] [drm:intel_panel_get_max_backlight], max backlight PWM =
 2890
 [  222.583814] [drm:intel_panel_set_backlight], set backlight PWM = 2595
 [  222.583819] [drm:intel_panel_set_backlight], set backlight tmp(1) =
 189401352
 [  222.583824] [drm:intel_panel_set_backlight], set backlight tmp(2) =
 189399040
 [  222.583828] [drm:intel_panel_set_backlight], set 

[Bug 36978] Radeon 7500 [rv200] - hardware tcl don't work corretly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36978

--- Comment #9 from Dymchenko Bogdan dmboh...@gmail.com 2011-05-09 07:25:03 
PDT ---
no, there is no any warnings.

With default settings i see 

drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See
dmesg for more info.
and
[63763.072946] [drm:radeon_cs_parser_init] *ERROR* cs IB too big: 16403
[63763.072950] [drm:radeon_cs_ioctl] *ERROR* Failed to initialize parser !
in dmesg

or with setup command buffer to 32 i see
radeon_common.c:1250: rcommonEnsureCmdBufSpace: Assertion
`rmesa-cmdbuf.cs-cdw' failed.
when try to start a game

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 34102] radeon drm/kms: please use suspend/hibernate notifiers for allocating memory in suspend routines

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=34102





--- Comment #10 from Martin Steigerwald mar...@lichtvoll.de  2011-05-09 
15:15:49 ---
This wasn't a hang I think, see there.

I tried to hibernate two running KDE 4 sessions with reserved_size upto 64 MiB:

shambhala:/sys/power cat reserved_size 
67108864

Which failed with:

May  9 16:41:47 localhost kernel: PM: freeze of devices complete after 524.427
msecs
May  9 16:41:47 localhost kernel: PM: late freeze of devices complete after
0.509 msecs
May  9 16:41:47 localhost kernel: ACPI: Preparing to enter system sleep state
S4
May  9 16:41:47 localhost kernel: PM: Saving platform NVS memory
May  9 16:41:47 localhost kernel: Extended CMOS year: 2000
May  9 16:41:47 localhost kernel: PM: Creating hibernation image:
May  9 16:41:47 localhost kernel: PM: Need to copy 218459 pages
May  9 16:41:47 localhost kernel: PM: Normal pages needed: 113686 + 1024,
available pages: 113492
May  9 16:41:47 localhost kernel: PM: Not enough free memory
May  9 16:41:47 localhost kernel: PM: Error -12 creating hibernation image
May  9 16:41:47 localhost kernel: Extended CMOS year: 2000
May  9 16:41:47 localhost kernel: ACPI: Waking up from system sleep state S4
May  9 16:41:47 localhost kernel: PM: early recover of devices complete after
0.366 msecs

Does it make sense to go to even higher values? I am a bit puzzled, since for
one KDE 4 session a value of 2 MiB has turned out to be enough for about 5-10
attempts - it didn't fail once.

Maybe here there is simply not enough memory available no matter what I reserve
for driver allocation? If so, then so be it. That might be just a limit for a 2
GB RAM machine.

Is there a way to tell for sure whether reserved size is too low or there are
general memory constraints? TuxOnIce logged how much of the reserved extra
pages it used. Can in-kernel-hibernation do this too?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 34102] radeon drm/kms: please use suspend/hibernate notifiers for allocating memory in suspend routines

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=34102





--- Comment #11 from Martin Steigerwald mar...@lichtvoll.de  2011-05-09 
15:59:09 ---
Ok, now it did it! First with 256 MiB reserved_size then also with 128 MiB
reserved_size. Two KDE 4 sessions with compositing enabled. It had some
problems to freeze tasks initially, cause an rdiff-backup and two KDE 4 desktop
search indexers were running, but after some tries it did it. And if the
rdiff-backup and those desktop searches fill the laptop harddisk with I/O
requests up to its limit, thats just what to be expected. I am now testing 128
MiB and looks whether it works reliably. Still I wonder why 2 MiB was enough
for one KDE 4 session, but two need something around 128 MiB.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms gallium

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36952

--- Comment #6 from Chris Bandy cba...@jbandy.com 2011-05-09 09:52:02 PDT ---
(In reply to comment #5)
 is there a way to pass commit tags to 'emerge' or specify in the ebuild?

The x11 overlay has live ebuilds. Use EGIT_COMMIT to specify a commit to
checkout.

http://devmanual.gentoo.org/eclass-reference/git-2.eclass/index.html

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 36952] segfault in crackberg xscreensaver on ATI RS482 in mesa git running kms gallium

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=36952

--- Comment #7 from Iaroslav pontost...@gmail.com 2011-05-09 09:57:59 PDT ---
(In reply to comment #4)
 But if I downgrade to mesa 7.10.2, I am still using llvm 2.9 and the
 crackberg screensaver works correctly, so that would point to mesa-git
 being the problem for me.  I cannot compile mesa-git without llvm as the
 build process halts and complains that r300 gallium requires llvm to
 build.  There are three gentoo patches that get applied on top of the
 mesa 7.10.2-r1 build, I haven't looked at what they do yet.
 
 (In reply to comment #2)
  I have some problem, and i have  ATI RS482 too, but i think it was the fault
  llvm, with out llvm or  2.9 , all woks fine, with llvm  2.8  openarena,
  urbanterror and some xscreensaver segfault. see
  https://bugs.freedesktop.org/show_bug.cgi?id=36738
  I make backtrace with crackberg.

Can you run crackberg with gdb, and show backtrace? Or run openarena with
mesa-git+llvm-2.9.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Call for desktop/graphics/mobile tracks for Linux Plumbers' Conf 2011

[Jesse Barnes]

We have both desktop (for general graphics/media stuff) and mobile
tracks at this year's LPC.

So if you're working on a topic related to one of the above areas,
especially one that has open issues or spans multiple parts of the
stack, please submit a topic for discussion at
http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals/new
against the appropriate track.  Proposals for presentations (track
independent talks about a specific topic) are also open until May 15th,
so if you have a topic you'd like to present that doesn't fit into an
existing track, be sure to submit it soon.

Early registration for LPC is open until June 1st, so regardless of
whether you're submitting a topic, if you see discussions or proposed
talks of interest to you, be sure to register soon to get the
discounted rate.

Thanks,
Jesse Barnes
LPC2011 Planning Chair
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37028] New: Amnesia/HPL2 Demo: Strange graphical bugs on r600g

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37028

   Summary: Amnesia/HPL2 Demo: Strange graphical bugs on r600g
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: haya...@gmail.com


Created an attachment (id=46492)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46492)
Screenshot

Hi, this game (amnesia dark descent) seems to run on the r600g driver, but with
some graphical bugs that make the experience not enjoyable.

There's a big black corruption in the bottom part of the screen that covers 1/5
(almost) of the screen and strange white dots appear in the air. Water also
flickers.

The most serious glitch is the first one, the black corruption.

I've attached a screenshot of this.

I also attached the screenshot and the log from the game.

The screenshot and the log is taken from the demo version of the game.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=37028

--- Comment #1 from Maggioni Marcello haya...@gmail.com 2011-05-09 10:40:21 
PDT ---
Created an attachment (id=46493)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46493)
game log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel