Completely ignore EDID for KMS, use user-supplied kernel param (video=)?

[Paul Sokolovsky]

Hello,

On Tue, 23 Nov 2010 02:00:51 -0500
Alex Deucher  wrote:

[]

> > My specific issue is that there's an LVDS (of MSI X410/X430
> > notebook) which has right dimensions and refresh rate, but wrong,
> > if not say unrelated, clock settings. The end result is that
> > there's tearing-off, broken sync like on an old dying TV. More
> > details are at
> > http://.ubuntuforums.org/showthread.php?p=10120939 . That's on
> > 2.6.35 (stock Ubuntu 10.10 kernel). I was able to set CVT timings
> > on X which gave stable picture, but no luck persuading kernel to do
> > the same (I used video=LVDS-1:1366x768M at 60 param, also tried more
> > conventional modes like 1024x768).
> >
> > I'd appreciate any hints.
> 
> Assuming your laptop contains a radeon, the panel timing comes from a
> table in the vbios.  The timing problem is most likely not due to an
> EDID problem, but to pll dividers that that panel doesn't like.  Try
> booting with radeon.new_pll=0 on the kernel command line or try kernel
> 2.6.37.

Pure magic! ;-) Thanks for quick reply, that worked, even though I
really thought that's a case of broken EDID, as X had the same
behavior, which I could work around by setting CVT timing using xrandr
(while nomodeset for kernel). Just for the info, that was for Radeon HD
3200, though the same issue was reported for Radeon X1250.

However, can you please elaborate about overring mode for KMS-based
driver on the kernel command line? I studied kernel source more myself,
and see that video= parsing for KMS is being performed by
drm_fb_helper.c, and its routines seem to be called by the radeon
driver. So, based on the code

DRM_DEBUG_KMS("cmdline mode for connector %s
%dx%d@%dHz%s%s%s\n", drm_get_connector_name(connector), xres,
yres, (refresh) ? refresh : 60, (rb) ? " reduced blanking" :
"", (margins) ? " with margins" : "", (interlace) ?
" interlaced" : "");

I set following kernel params:

drm.debug=7 video=LVDS-1:1366x768M at 60

But expected output didn't appear in dmesg. I also tried
"video=LVDS:1366x768M at 60" with the same result. What could be wrong?

> 
> Alex


-- 
Best regards,
 Paul  mailto:pmiscml at gmail.com

[PATCH] MAINTAINERS: INTEL DRM DRIVERS list (intel-gfx) is subscribers-only

[Joe Perches]

Mark it so.

Signed-off-by: Joe Perches 
---
 MAINTAINERS |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9ac6540..07aa850 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2080,7 +2080,7 @@ F:include/drm/

 INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets)
 M: Chris Wilson 
-L: intel-gfx at lists.freedesktop.org
+L: intel-gfx at lists.freedesktop.org (subscribers-only)
 L: dri-devel at lists.freedesktop.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git
 S: Supported

[PATCH] drm: Add __attribute__((format (printf...) to drm_ut_debug_printk and fix fallout

[Joe Perches]

Add __attribute__((format (printf... to drm_ut_debug_printk.
Make arguments and formats match in drm and drm/i915.
Change non-debug DRM_ to use no_printk.

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/drm_irq.c|7 ---
 drivers/gpu/drm/i915/intel_bios.c|5 ++---
 drivers/gpu/drm/i915/intel_display.c |4 ++--
 include/drm/drmP.h   |   23 ---
 4 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 4e82d0d..df81817 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -694,9 +694,10 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev, int crtc,
 */
*vblank_time = ns_to_timeval(timeval_to_ns(_time) - delta_ns);

-   DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %d.%d -> %d.%d [e %d us, %d rep]\n",
- crtc, (int) vbl_status, hpos, vpos, raw_time.tv_sec,
- raw_time.tv_usec, vblank_time->tv_sec, vblank_time->tv_usec,
+   DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d 
rep]\n",
+ crtc, (int) vbl_status, hpos, vpos,
+ raw_time.tv_sec, (unsigned long)raw_time.tv_usec,
+ vblank_time->tv_sec, (unsigned long)vblank_time->tv_usec,
  (int) duration_ns/1000, i);

vbl_status = DRM_VBLANKTIME_SCANOUTPOS_METHOD;
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index b0b1200..2af2966 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -214,9 +214,8 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
i915_lvds_downclock) {
dev_priv->lvds_downclock_avail = 1;
dev_priv->lvds_downclock = temp_downclock;
-   DRM_DEBUG_KMS("LVDS downclock is found in VBT. ",
-   "Normal Clock %dKHz, downclock %dKHz\n",
-   temp_downclock, panel_fixed_mode->clock);
+   DRM_DEBUG_KMS("LVDS downclock is found in VBT. Normal Clock 
%dKHz, downclock %dKHz\n",
+ temp_downclock, panel_fixed_mode->clock);
}
return;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bee24b1..080d094 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2891,11 +2891,11 @@ static unsigned long intel_calculate_wm(unsigned long 
clock_in_khz,
1000;
entries_required = DIV_ROUND_UP(entries_required, wm->cacheline_size);

-   DRM_DEBUG_KMS("FIFO entries required for mode: %d\n", entries_required);
+   DRM_DEBUG_KMS("FIFO entries required for mode: %ld\n", 
entries_required);

wm_size = wm->fifo_size - (entries_required + wm->guard_size);

-   DRM_DEBUG_KMS("FIFO watermark level: %d\n", wm_size);
+   DRM_DEBUG_KMS("FIFO watermark level: %ld\n", wm_size);

/* Don't promote wm_size to unsigned... */
if (wm_size > (long)wm->max_wm)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2b33980..0d46009 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -122,10 +122,11 @@ struct drm_device;
  * using the DRM_DEBUG_KMS and DRM_DEBUG.
  */

-extern void drm_ut_debug_printk(unsigned int request_level,
-   const char *prefix,
-   const char *function_name,
-   const char *format, ...);
+extern __attribute__((format (printf, 4, 5)))
+void drm_ut_debug_printk(unsigned int request_level,
+const char *prefix,
+const char *function_name,
+const char *format, ...);
 /***/
 /** \name DRM template customization defaults */
 /*@{*/
@@ -238,13 +239,13 @@ extern void drm_ut_debug_printk(unsigned int 
request_level,
NULL, fmt, ##args); \
} while (0)
 #else
-#define DRM_DEBUG_DRIVER(fmt, args...) do { } while (0)
-#define DRM_DEBUG_KMS(fmt, args...)do { } while (0)
-#define DRM_DEBUG(fmt, arg...)  do { } while (0)
-#define DRM_LOG(fmt, arg...)   do { } while (0)
-#define DRM_LOG_KMS(fmt, args...) do { } while (0)
-#define DRM_LOG_MODE(fmt, arg...) do { } while (0)
-#define DRM_LOG_DRIVER(fmt, arg...) do { } while (0)
+#define DRM_DEBUG_DRIVER(fmt, args...) no_printk(fmt, ##args)
+#define DRM_DEBUG_KMS(fmt, args...)no_printk(fmt, ##args)
+#define DRM_DEBUG(fmt, args...)no_printk(fmt, ##args)
+#define DRM_LOG(fmt, args...)  no_printk(fmt, ##args)
+#define DRM_LOG_KMS(fmt, args...)  no_printk(fmt, ##args)
+#define DRM_LOG_MODE(fmt, args...) no_printk(fmt, ##args)
+#define DRM_LOG_DRIVER(fmt, args...)   no_printk(fmt, ##args)

 #endif

[Bug 30754] X server crashes with SEGFAULT when using virtualbox on Evergreen

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

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

--- Comment #4 from Fr?d?ric L. W. Meunier  
2010-11-23 21:44:52 PST ---
Created an attachment (id=40526)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=40526)
X backtrace

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

[Bug 30754] X server crashes with SEGFAULT when using virtualbox on Evergreen

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

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

--- Comment #3 from Fr?d?ric L. W. Meunier  
2010-11-23 21:43:50 PST ---
I also get random crashes with Bluefish, an editor.

Is this a new issue or the same ? I'm attaching the backtrace.

You can compare with the one I added at
https://bugs.freedesktop.org/show_bug.cgi?id=31299

This time, I'm using xorg-server 1.9.2, Mesa 7.9 git (20101122) and
xf86-video-ati 6.13.99 git (20101119).

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

[Bug 31881] New: [i915g] SIGSEGV piglit vpfp-generic vp-arl-constant-array-huge-varying

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

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

   Summary: [i915g] SIGSEGV piglit vpfp-generic
vp-arl-constant-array-huge-varying
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/i915g
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com
CC: wallbraker at gmail.com


mesa: 78a340fd487c56468ace7347a53f95a0c751c419 (master)

chipset: 945GM (Intel GMA 950)
system architecture: i686
xserver-xorg-video-intel: 2:2.12.0-1ubuntu5.1
libdrm-intel1: 2.4.21-1ubuntu2.1
kernel version: 2.6.35-22-generic
Linux distribution: Ubuntu 10.10 i386

Run piglit vpfp-generic vp-arl-constant-array-huge-varying test. The test hits
a segmentation fault.

$ ./bin/vpfp-generic tests/shaders/generic/vp-arl-constant-array-huge-varying
-auto
Program terminated with signal 11, Segmentation fault.
#0  0x0165cd0c in llvm::ConstantInt::get(llvm::LLVMContext&, llvm::APInt
const&) () from
/home/mks-hackers/mesa/build/linux-x86-debug/gallium/targets/dri-i915/i915_dri.so
(gdb) bt
#0  0x0165cd0c in llvm::ConstantInt::get(llvm::LLVMContext&, llvm::APInt
const&) () from mesa/build/linux-x86-debug/gallium/targets/dri-i915/i915_dri.so
#1  0x0048 in ?? ()
#2  0xbff03300 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

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

[Regression, post-2.6.37-rc2] Unable to start KDE with 2.6.37-rc3 on Acer Ferrari One

[Alex Deucher]

On Tue, Nov 23, 2010 at 8:45 PM, Rafael J. Wysocki  wrote:
> On Wednesday, November 24, 2010, Alex Deucher wrote:
>> 2010/11/23 Rafael J. Wysocki :
>> > On Wednesday, November 24, 2010, Rafael J. Wysocki wrote:
>> >> Hi,
>> >>
>> >> I cannot start KDE with the 2.6.37-rc3 kernel. ?The X server and display
>> >> manager start normally, but when I attempt to log into KDE, it attempts to
>> >> start, but then the X apparently crashes and this appears in the dmesg 
>> >> output:
>> >>
>> >> [ ? 24.342287] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
>> >> 46097920 4325376 too big
>> >> [ ? 24.342298] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
>> >> stream 502
>> >> [ ? 24.342304] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
>> >> [ ? 24.694106] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>> >> [ ? 93.938946] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
>> >> 46097920 4325376 too big
>> >> [ ? 93.938956] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
>> >> stream 502
>> >> [ ? 93.938962] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
>> >> [ ? 94.278050] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>> >> [ ?114.898043] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
>> >> 46097920 4325376 too big
>> >> [ ?114.898053] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
>> >> stream 502
>> >> [ ?114.898058] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
>> >> [ ?115.266113] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>> >> [ ?129.722472] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>> >> [ ?142.984314] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
>> >> 46097920 4325376 too big
>> >> [ ?142.984324] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
>> >> stream 502
>> >> [ ?142.984330] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
>> >> [ ?143.370083] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>> >>
>> >> This doesn't happen with 2.6.37-rc2.
>> >
>> > Reverting the following commit:
>> >
>> > commit 16790569eddf4d406a16a65f4750f405fa669c52
>> > Author: Alex Deucher 
>> > Date: ? Sun Nov 14 20:24:35 2010 -0500
>> >
>> > ? ?drm/radeon/kms: fix and unify tiled buffer alignment checking for 
>> > r6xx/7xx
>> >
>> > fixes the issue for me (so everyone involved is already in the Cc list 
>> > ;-)).
>> >
>>
>> Are you sure you've got the right commit?
>
> Well, as I said, I reverted that particular commit and things started to work.
>
>> That shouldn't change the calculation that's failing at all. ?I'd guess it's
>> probably one of these:
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d33ef52d9db8a36900dd53f2e32db9a521ace259
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f30df2fad0c901e74ac9a52a488a54c69a373a41
>
> I don't know. ?Perhaps there are some interactions between the two and the
> reverted one. ?I can try reverting these tomorrow if you want me to.

Can you try just reverting this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d33ef52d9db8a36900dd53f2e32db9a521ace259

I think the real issue is a bug in the 3D driver (probably a flush at
the wrong time) that one of these commits exposing.

Alex

>
>> Can you attach your xorg log as well?
>
> Sure, attached (the working case).
>
> Thanks,
> Rafael
>

[Bug 31880] [i915g] src/gallium/auxiliary/draw/draw_pt_emit.c:93:draw_pt_emit_prepare: Assertion `emit_sz != 0' failed.

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

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

Vinson Lee  changed:

   What|Removed |Added

Summary|[i915g] |[i915g]
   ||src/gallium/auxiliary/draw/
   ||draw_pt_emit.c:93:draw_pt_e
   ||mit_prepare: Assertion
   ||`emit_sz != 0' failed.

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

[Bug 31880] New: [i915g]

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

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

   Summary: [i915g]
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/i915g
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at vmware.com
CC: wallbraker at gmail.com


mesa: 78a340fd487c56468ace7347a53f95a0c751c419 (master)

chipset: 945GM (Intel GMA 950)
system architecture: i686
xserver-xorg-video-intel: 2:2.12.0-1ubuntu5.1
libdrm-intel1: 2.4.21-1ubuntu2.1
kernel version: 2.6.35-22-generic
Linux distribution: Ubuntu 10.10 i386

Run piglit vpfp-generic vp-arl-constant-array-huge test.

$ ./bin/vpfp-generic tests/shaders/generic/vp-arl-constant-array-huge.vpfp
-auto
Probe at (50,50)
  Expected: 0.50 1.00 1.00 0.00
  Observed: 0.00 0.00 0.00 0.00
Test tests/shaders/generic/vp-arl-constant-array-huge.vpfp:137 failed
src/gallium/auxiliary/draw/draw_pt_emit.c:93:draw_pt_emit_prepare: Assertion
`emit_sz != 0' failed.

(gdb) bt
#0  0x010d122b in _debug_assert_fail (expr=0x1958c40 "emit_sz != 0",
file=0x1958c14 "src/gallium/auxiliary/draw/draw_pt_emit.c", line=93,
function=0x1958c6e "draw_pt_emit_prepare")
at src/gallium/auxiliary/util/u_debug.c:233
#1  0x01100798 in draw_pt_emit_prepare (emit=0x8fca078, prim=7,
max_vertices=0x8fc73cc) at src/gallium/auxiliary/draw/draw_pt_emit.c:93
#2  0x010fdc16 in llvm_middle_end_prepare (middle=0x8fc9fc0, in_prim=7, opt=3,
max_vertices=0x8fc73cc) at
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:120
#3  0x010a5b2a in vsplit_prepare (frontend=0x8fc73b0, in_prim=7,
middle=0x8fc9fc0, opt=3) at src/gallium/auxiliary/draw/draw_pt_vsplit.c:170
#4  0x0109b3be in draw_pt_arrays (draw=0x8f74340, prim=7, start=0, count=4) at
src/gallium/auxiliary/draw/draw_pt.c:111
#5  0x0109bf91 in draw_vbo (draw=0x8f74340, info=0xbfeb58a4) at
src/gallium/auxiliary/draw/draw_pt.c:481
#6  0x0106c988 in i915_draw_vbo (pipe=0x8f79368, info=0xbfeb58a4) at
src/gallium/drivers/i915/i915_context.c:81
#7  0x0181dba5 in st_draw_vbo (ctx=0x8fdee50, arrays=0x9022e30,
prims=0x9021804, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0,
max_index=3) at src/mesa/state_tracker/st_draw.c:732
#8  0x018a2f0d in vbo_exec_vtx_flush (exec=0x9021690, unmap=1 '\001') at
src/mesa/vbo/vbo_exec_draw.c:381
#9  0x0189edfe in vbo_exec_FlushVertices_internal (ctx=0x8fdee50, unmap=1
'\001') at src/mesa/vbo/vbo_exec_api.c:937
#10 0x0189ee9d in vbo_exec_FlushVertices (ctx=0x8fdee50, flags=1) at
src/mesa/vbo/vbo_exec_api.c:971
#11 0x017be818 in _mesa_ReadPixels (x=50, y=50, width=1, height=1, format=6408,
type=5126, pixels=0xbfeb5a98) at src/mesa/main/readpix.c:171
#12 0x0805010f in piglit_probe_pixel_rgba (x=50, y=50, expected=0x90149f8) at
piglit/tests/util/piglit-util.c:189
#13 0x0804d896 in Test::run (this=0x90149e8) at
piglit/tests/shaders/vpfp-generic.cpp:199
#14 0x0804d9c3 in TestGroup::run (this=0x8056444) at
piglit/tests/shaders/vpfp-generic.cpp:226
#15 0x0804e2aa in piglit_display () at
piglit/tests/shaders/vpfp-generic.cpp:372
#16 0x08051e43 in display () at piglit/tests/util/piglit-framework.c:52
#17 0x00125820 in fghRedrawWindow (window=DWARF-2 expression error: DW_OP_reg
operations must be used either alone or in conjuction with DW_OP_piece or
DW_OP_bit_piece.
) at freeglut_main.c:210
#18 fghcbDisplayWindow (window=DWARF-2 expression error: DW_OP_reg operations
must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.
) at freeglut_main.c:227
#19 0x00129660 in fgEnumWindows (enumCallback=0x125790 ,
enumerator=0xbfeb5c28) at freeglut_structure.c:394
#20 0x00125cdb in fghDisplayAll () at freeglut_main.c:249
#21 glutMainLoopEvent () at freeglut_main.c:1450
#22 0x00126605 in glutMainLoop () at freeglut_main.c:1498
#23 0x08051fec in main (argc=2, argv=0xbfeb5eb4) at
piglit/tests/util/piglit-framework.c:118

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

XvMC gets iDCT support (at least on R600)

[Alex Deucher]

2010/11/23 Christian K?nig :
> Am Sonntag, den 21.11.2010, 11:28 -0500 schrieb Alex Deucher:
>> Make sure you are using the latest drm patches. ?Dave and I fixed a
>> number of bugs in the CS checker in 2.6.37. ?Also, make sure you have
>> the latest mesa bits. ?I fixed the buffer alignment handling in r600g.
> Just merged my mesa branch with master yesterday, I will update the
> kernel as soon as I find time to do so.
>
> But i don't think that this is already fixed: If i add a new colour
> format to the r600_translate_colorswap function in r600_state_inlines.h,
> but forget to also add those to the r600_translate_colorformat function
> I get a nice opps because of a divide by zero in the drm code,
> completely crashing the graphics subsystem.

That should be fixed already.

>
> Trying to use a constant as a texture locations also results in an gpu
> hangup/reset. This should also be prevented in the cb checker (or does
> it checks only the "real" command buffer and not the shaders itself?).
>

It doesn't check the shaders, it just checks the command stream to
make sure the enabled buffers are valid and to translate the bo
handles to MC addresses.

> And when the drm code detects a hanging command buffer and resets the
> gpu, it would be nice to kill the process that issued this command
> buffer, because it make no sense that an userspace application keeps
> issuing the same invalid command buffer over and over again (after an
> reasonable amounts of retries of course).
>
>> Using tiled surfaces may help if you are doing a lot of texture
>> lookups. ?There is support in r600g if you are using the latest drm
>> and mesa code.
> How far goes tilling on r600 hardware? Is it one, two or tree layer
> tilling? What i mean is this:
>
> Normal linear layout:
> A B C D E F G H I J K L M N O P
>
> One layer tilling:
> A B E F I J M N
> C D G H K L O P
>
> Two layer tilling:
> A B E F
> C D G H
> I J M N
> K L O P
>
> And so on, (if I understood the concept of tilling right).

There are two types of tiling you can enable, 1D, and 2D.  1D
basically divides up the buffer into 8x8 pixel micro tiles.  2D tiling
uses larger macro tiles made up of micro tiles, hence the 1D and 2D.
Tiling is meant to maximize cache locality and memory bandwidth.  1D
tiles map roughly to a cache line and you get better cache utilization
for a tile rather than a scanline as you have similar addresses in 2D
space closer together.  Macro tiles maximize bandwidth by optimally
distributing load across all memory channels.  For optimal
performance, tiling should always be enabled, but it requires a fair
amount of driver infrastructure which is just now coming online.
E.g., if you want to manipulate a tiled buffer with the CPU, you'd
need to either calculate the addresses yourself on a per-pixel basis,
or you need to use the 3D engine to blit to a linear buffer.

>
> For an iDCT of a 8x8 pixel block I would need tree layer tilling, so a
> 8x8 block of 64 elements are stored linear "near" to each other in
> memory. Would that work on the hardware?

It's transparent to the application, but it sounds like it would
probably help in this case.

>
> Another thing that would really help is if I could calculate 4 elements
> in one pixel shader run instead of just one, but for this to I would
> need R32G32B32A32 colour buffers, and I simply can't get them to work
> probably.
>
> I added the following lines to the r600_cb function in r600_state.c:
> ? ? ? ?desc = util_format_description(rtex->resource.base.b.format);
> ? ? ? ?if (desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB)
> ? ? ? ? ? ? ? ?ntype = V_0280A0_NUMBER_SRGB;
> ? ? ? ?else if (desc->layout == UTIL_FORMAT_LAYOUT_PLAIN) {
> ? ? ? ? ? ? ? ?switch(desc->channel[0].type) {
> ? ? ? ? ? ? ? ?case UTIL_FORMAT_TYPE_UNSIGNED:
> ? ? ? ? ? ? ? ? ? ? ? ?ntype = V_0280A0_NUMBER_UNORM;
> ? ? ? ? ? ? ? ? ? ? ? ?break;
>
> ? ? ? ? ? ? ? ?case UTIL_FORMAT_TYPE_SIGNED:
> ? ? ? ? ? ? ? ? ? ? ? ?ntype = V_0280A0_NUMBER_SNORM;
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?}
> ? ? ? ?}
> This seems to get R16_SNORM colour buffers working, but texture uploads
> and even a simple R32_FLOAT colour buffer won't work right. I looks like
> a have to use the right combination of V_0280A0_FORMAT, V_0280A0_NUMBER,
> V_0280A0_BLEND_CLAMP, V_0280A0_BLEND_BYPASS etc, but I just keep having
> strange artefacts every n pixel (for example R32_FLOAT only renders the
> even rows correctly).
>

Yeah, you'd need to sort out the state properly for these new formats.

Alex

> Any help with this would be really appreciated.
>
> Regards,
> Christian.
>
>

[Regression, post-2.6.37-rc2] Unable to start KDE with 2.6.37-rc3 on Acer Ferrari One

[Alex Deucher]

2010/11/23 Rafael J. Wysocki :
> On Wednesday, November 24, 2010, Rafael J. Wysocki wrote:
>> Hi,
>>
>> I cannot start KDE with the 2.6.37-rc3 kernel. ?The X server and display
>> manager start normally, but when I attempt to log into KDE, it attempts to
>> start, but then the X apparently crashes and this appears in the dmesg 
>> output:
>>
>> [ ? 24.342287] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
>> 46097920 4325376 too big
>> [ ? 24.342298] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
>> stream 502
>> [ ? 24.342304] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
>> [ ? 24.694106] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>> [ ? 93.938946] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
>> 46097920 4325376 too big
>> [ ? 93.938956] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
>> stream 502
>> [ ? 93.938962] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
>> [ ? 94.278050] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>> [ ?114.898043] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
>> 46097920 4325376 too big
>> [ ?114.898053] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
>> stream 502
>> [ ?114.898058] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
>> [ ?115.266113] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>> [ ?129.722472] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>> [ ?142.984314] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
>> 46097920 4325376 too big
>> [ ?142.984324] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
>> stream 502
>> [ ?142.984330] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
>> [ ?143.370083] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
>>
>> This doesn't happen with 2.6.37-rc2.
>
> Reverting the following commit:
>
> commit 16790569eddf4d406a16a65f4750f405fa669c52
> Author: Alex Deucher 
> Date: ? Sun Nov 14 20:24:35 2010 -0500
>
> ? ?drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx
>
> fixes the issue for me (so everyone involved is already in the Cc list ;-)).
>

Are you sure you've got the right commit?  That shouldn't change the
calculation that's failing at all.  I'd guess it's probably one of
these:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d33ef52d9db8a36900dd53f2e32db9a521ace259
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f30df2fad0c901e74ac9a52a488a54c69a373a41

Can you attach your xorg log as well?

Alex

> Thanks,
> Rafael
>

Completely ignore EDID for KMS, use user-supplied kernel param (video=)?

[Alex Deucher]

On Tue, Nov 23, 2010 at 3:38 PM, Paul Sokolovsky  wrote:
> Hello,
>
> On Tue, 23 Nov 2010 02:00:51 -0500
> Alex Deucher  wrote:
>
> []
>
>> > My specific issue is that there's an LVDS (of MSI X410/X430
>> > notebook) which has right dimensions and refresh rate, but wrong,
>> > if not say unrelated, clock settings. The end result is that
>> > there's tearing-off, broken sync like on an old dying TV. More
>> > details are at
>> > http://.ubuntuforums.org/showthread.php?p=10120939 . That's on
>> > 2.6.35 (stock Ubuntu 10.10 kernel). I was able to set CVT timings
>> > on X which gave stable picture, but no luck persuading kernel to do
>> > the same (I used video=LVDS-1:1366x768M at 60 param, also tried more
>> > conventional modes like 1024x768).
>> >
>> > I'd appreciate any hints.
>>
>> Assuming your laptop contains a radeon, the panel timing comes from a
>> table in the vbios. ?The timing problem is most likely not due to an
>> EDID problem, but to pll dividers that that panel doesn't like. ?Try
>> booting with radeon.new_pll=0 on the kernel command line or try kernel
>> 2.6.37.
>
> Pure magic! ;-) Thanks for quick reply, that worked, even though I
> really thought that's a case of broken EDID, as X had the same
> behavior, which I could work around by setting CVT timing using xrandr
> (while nomodeset for kernel). Just for the info, that was for Radeon HD
> 3200, though the same issue was reported for Radeon X1250.
>

X using KMS and the console use the same code to set the mode.  They
both call into the radeon KMS drm.  The modesetting paths in UMS are
slightly different from KMS so likely a slightly different set of pll
dividers was selected.

> However, can you please elaborate about overring mode for KMS-based
> driver on the kernel command line? I studied kernel source more myself,
> and see that video= parsing for KMS is being performed by
> drm_fb_helper.c, and its routines seem to be called by the radeon
> driver. So, based on the code
>
> ? ? ? ?DRM_DEBUG_KMS("cmdline mode for connector %s
> ? ? ? ?%dx%d@%dHz%s%s%s\n", drm_get_connector_name(connector), xres,
> ? ? ? ?yres, (refresh) ? refresh : 60, (rb) ? " reduced blanking" :
> ? ? ? ? ? ? ? ?"", (margins) ? " with margins" : "", (interlace) ?
> ? ? ? ? ? ? ? ?" interlaced" : "");
>
> I set following kernel params:
>
> drm.debug=7 video=LVDS-1:1366x768M at 60
>
> But expected output didn't appear in dmesg. I also tried
> "video=LVDS:1366x768M at 60" with the same result. What could be wrong?
>

There's no way to override the panel mode on LVDS, the driver doesn't
let you (same for UMS).  The timing is too sensitive;  the driver
always uses the panel's native timing.

Alex

>>
>> Alex
>
>
> --
> Best regards,
> ?Paul ? ? ? ? ? ? ? ? ? ? ? ? ?mailto:pmiscml at gmail.com
>

[Bug 31876] New: r600g crashes in screen init

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

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

   Summary: r600g crashes in screen init
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: snorp at snorp.net


gdb --args glxinfo
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/glxinfo...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/glxinfo 
[Thread debugging using libthread_db enabled]
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 4.3.0 r600 (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/gallium/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri/gallium/r600_dri.so
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenByBusid: Searching for BusID pci::01:05.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenByBusid: drmOpenMinor returns 6
drmOpenByBusid: Interface 1.4 failed, trying 1.1
drmOpenByBusid: drmGetBusid reports pci::01:05.0

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x006b4ecd in driCreateNewScreen (scrn=0, ddx_version=0xb208, 
dri_version=0xb1fc, drm_version=0xb1f0, frame_buffer=0xb1d4, 
pSAREA=0xb7ffb000, fd=6, extensions=0x17e2cc, driver_modes=0xb218, 
loaderPrivate=0x805b628) at ../common/dri_util.c:830
#2  0x0016a820 in CallCreateNewScreen (screen=0, priv=0x805a2e0)
at dri_glx.c:434
#3  driCreateScreen (screen=0, priv=0x805a2e0) at dri_glx.c:875
#4  0x00147a2c in AllocAndFetchScreenConfigs (dpy=0x8050008) at glxext.c:762
#5  __glXInitialize (dpy=0x8050008) at glxext.c:859
#6  0x0014485a in GetGLXPrivScreenConfig (dpy=0x8050008, scrn=0, 
ppriv=0xb44c, ppsc=0xb448) at glxcmds.c:130
#7  0x001459c6 in glXChooseVisual (dpy=0x8050008, screen=0, 
attribList=0x804f0e0) at glxcmds.c:1152
#8  0x080493a8 in ?? ()
#9  0x0804a44c in ?? ()
#10 0x002f9bd6 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#11 0x08048e11 in ?? ()

This is with xorg-edgers in Ubuntu Lucid, which has Mesa as of 20101122.  I'm
running on a 785G.

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

i915: display doesn't get on back after returning from standby in 2.6.27-rc*

[Michal Hocko]

Hi,
since early 2.6.37 (I haven't bisected when exactly) my screen doesn't
get on after it got into standby mode. I have to either change to a
text console and back (if it gets to standby by the screen saver) or
close the lid on my laptop if I try:
xset dpms force standby

Changing to a text cosole doesn't help in dpms case.

When I boot back to 2.6.36-00022-g2b666ca this works fine.
Is this a known issue?

$ lspci -vv
[...]
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 
943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA 
controller])
Subsystem: Fujitsu Limited. Device 137a
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: 
Kernel driver in use: i915
[...]

Nothing appears in the log during dpms standby and the lid close. dmesg
output is attached.
Config is attached as well.

Let me know if you need further information.

Thanks
-- 
Michal Hocko
L3 team 
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
-- next part --
#
# Automatically generated make config: don't edit
# Linux/i386 2.6.37-rc3 Kernel Configuration
# Mon Nov 22 13:52:47 2010
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
# CONFIG_NEED_DMA_MAP_STATE is not set
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_X86_32_LAZY_GS=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx"
CONFIG_KTIME_SCALAR=y
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_AUDIT is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
# CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED is not set
CONFIG_HAVE_SPARSE_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
# CONFIG_AUTO_IRQ_AFFINITY is not set
# CONFIG_IRQ_PER_CPU is not set
# CONFIG_HARDIRQS_SW_RESEND is not set
# CONFIG_SPARSE_IRQ is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_TRACE is not set
CONFIG_RCU_FANOUT=32
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_LZO=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y

[Bug 31827] r300g fails to link a GL program (Mesa 7.9)

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

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

--- Comment #8 from Hicham HAOUARI  2010-11-23 
13:07:20 PST ---
(In reply to comment #7)
> Please query GL_LINK_STATUS and post what it says.

I think that is what I have done in the testcase, or am I missing something ?

Anyway, I retested with Fedora rawhide, which ships mesa-7.10 snapshot from
20101118 and I still get the same failure.

kernel : 2.6.36

libdrm : 2.4.23 branch git snapshot from 20101123

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

[Bug 31827] r300g fails to link a GL program (Mesa 7.9)

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

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

--- Comment #7 from Marek Ol??k  2010-11-23 13:01:54 PST 
---
Please query GL_LINK_STATUS and post what it says.

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

[Bug 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

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

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

--- Comment #12 from diska  2010-11-23 12:34:42 
PST ---
it work for me

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

[Bug 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Alex Deucher  2010-11-23 12:21:01 PST 
---
Should be fixed in:
ed8b5fb24e098c97a7618a76aab783883f331625

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

[Bug 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

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

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

diska  changed:

   What|Removed |Added

Product|DRI |Mesa
Version|unspecified |git
  Component|DRM/Radeon  |Drivers/DRI/Radeon

--- Comment #10 from diska  2010-11-23 12:01:39 
PST ---
the problem is in mesa drm code 

mesa/src/gallium/winsys/radeon/drm/radeon_drm.h

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

[Bug 31827] r300g fails to link a GL program (Mesa 7.9)

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

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

--- Comment #6 from Hydrar  2010-11-23 11:53:46 
PST ---
Just updated both my computers to latest git today, the test case prints
"program linking succeeded" on my RV530(X1600), but fails on my RV410(Mobility
X700), with same git versions of libdrm, mesa and xf86-video-ati.

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

[Bug 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

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

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

--- Comment #9 from diska  2010-11-23 11:53:26 
PST ---
68c1  Redwood [Radeon HD 5600 Series]

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

[Bug 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

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

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

--- Comment #8 from diska  2010-11-23 11:51:15 
PST ---
my pciid is 68c1

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

[PATCH 2/2] drm/radeon/kms: de-inline radeon_bo_wait

[Dave Airlie]

From: Dave Airlie 

this function is much to large to be inlined practically.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/radeon_gem.c|   19 +++
 drivers/gpu/drm/radeon/radeon_object.h |   18 --
 2 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index df95eb8..d6fe39f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -30,6 +30,25 @@
 #include "radeon_drm.h"
 #include "radeon.h"

+static int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type,
+   bool no_wait)
+{
+   int r;
+
+   r = ttm_bo_reserve(>tbo, true, no_wait, false, 0);
+   if (unlikely(r != 0))
+   return r;
+   spin_lock(>tbo.bdev->fence_lock);
+   if (mem_type)
+   *mem_type = bo->tbo.mem.mem_type;
+   if (bo->tbo.sync_obj)
+   r = ttm_bo_wait(>tbo, true, true, no_wait);
+   spin_unlock(>tbo.bdev->fence_lock);
+   ttm_bo_unreserve(>tbo);
+   return r;
+}
+
+
 int radeon_gem_object_init(struct drm_gem_object *obj)
 {
/* we do nothings here */
diff --git a/drivers/gpu/drm/radeon/radeon_object.h 
b/drivers/gpu/drm/radeon/radeon_object.h
index 22d4c23..938419e 100644
--- a/drivers/gpu/drm/radeon/radeon_object.h
+++ b/drivers/gpu/drm/radeon/radeon_object.h
@@ -118,24 +118,6 @@ static inline u64 radeon_bo_mmap_offset(struct radeon_bo 
*bo)
return bo->tbo.addr_space_offset;
 }

-static inline int radeon_bo_wait(struct radeon_bo *bo, u32 *mem_type,
-   bool no_wait)
-{
-   int r;
-
-   r = ttm_bo_reserve(>tbo, true, no_wait, false, 0);
-   if (unlikely(r != 0))
-   return r;
-   spin_lock(>tbo.bdev->fence_lock);
-   if (mem_type)
-   *mem_type = bo->tbo.mem.mem_type;
-   if (bo->tbo.sync_obj)
-   r = ttm_bo_wait(>tbo, true, true, no_wait);
-   spin_unlock(>tbo.bdev->fence_lock);
-   ttm_bo_unreserve(>tbo);
-   return r;
-}
-
 extern int radeon_bo_create(struct radeon_device *rdev,
struct drm_gem_object *gobj, unsigned long size,
int byte_align,
-- 
1.7.3.2

[PATCH 1/2] drm/radeon: add initial tracepoint support.

[Dave Airlie]

From: Dave Airlie 

this adds a bo create, and fence seq tracking tracepoints.

This is just an initial set to play around with, we should investigate
what others we need would be useful.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/Makefile  |5 +-
 drivers/gpu/drm/radeon/radeon_fence.c|4 +
 drivers/gpu/drm/radeon/radeon_object.c   |2 +
 drivers/gpu/drm/radeon/radeon_trace.h|   82 ++
 drivers/gpu/drm/radeon/radeon_trace_points.c |9 +++
 5 files changed, 101 insertions(+), 1 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_trace.h
 create mode 100644 drivers/gpu/drm/radeon/radeon_trace_points.c

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 6cae4f2..e97e6f8 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -65,10 +65,13 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit.o r600_blit_shaders.o \
r600_blit_kms.o radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
-   evergreen.o evergreen_cs.o evergreen_blit_shaders.o evergreen_blit_kms.o
+   evergreen.o evergreen_cs.o evergreen_blit_shaders.o 
evergreen_blit_kms.o \
+   radeon_trace_points.o

 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
 radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o
 radeon-$(CONFIG_ACPI) += radeon_acpi.o

 obj-$(CONFIG_DRM_RADEON)+= radeon.o
+
+CFLAGS_radeon_trace_points.o := -I$(src)
\ No newline at end of file
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c 
b/drivers/gpu/drm/radeon/radeon_fence.c
index daacb28..171b0b2 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -38,6 +38,7 @@
 #include "drm.h"
 #include "radeon_reg.h"
 #include "radeon.h"
+#include "radeon_trace.h"

 int radeon_fence_emit(struct radeon_device *rdev, struct radeon_fence *fence)
 {
@@ -57,6 +58,7 @@ int radeon_fence_emit(struct radeon_device *rdev, struct 
radeon_fence *fence)
} else
radeon_fence_ring_emit(rdev, fence);

+   trace_radeon_fence_emit(rdev->ddev, fence->seq);
fence->emited = true;
list_del(>list);
list_add_tail(>list, >fence_drv.emited);
@@ -213,6 +215,7 @@ int radeon_fence_wait(struct radeon_fence *fence, bool intr)
 retry:
/* save current sequence used to check for GPU lockup */
seq = rdev->fence_drv.last_seq;
+   trace_radeon_fence_wait_begin(rdev->ddev, seq);
if (intr) {
radeon_irq_kms_sw_irq_get(rdev);
r = wait_event_interruptible_timeout(rdev->fence_drv.queue,
@@ -227,6 +230,7 @@ retry:
 radeon_fence_signaled(fence), timeout);
radeon_irq_kms_sw_irq_put(rdev);
}
+   trace_radeon_fence_wait_end(rdev->ddev, seq);
if (unlikely(!radeon_fence_signaled(fence))) {
/* we were interrupted for some reason and fence isn't
 * isn't signaled yet, resume wait
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index a8594d2..8bdf0ba 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -34,6 +34,7 @@
 #include 
 #include "radeon_drm.h"
 #include "radeon.h"
+#include "radeon_trace.h"


 int radeon_ttm_init(struct radeon_device *rdev);
@@ -137,6 +138,7 @@ retry:
list_add_tail(>list, >gem.objects);
mutex_unlock(>rdev->gem.mutex);
}
+   trace_radeon_bo_create(bo);
return 0;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_trace.h 
b/drivers/gpu/drm/radeon/radeon_trace.h
new file mode 100644
index 000..eafd816
--- /dev/null
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -0,0 +1,82 @@
+#if !defined(_RADEON_TRACE_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _RADEON_TRACE_H_
+
+#include 
+#include 
+#include 
+
+#include 
+
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM radeon
+#define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM)
+#define TRACE_INCLUDE_FILE radeon_trace
+
+TRACE_EVENT(radeon_bo_create,
+   TP_PROTO(struct radeon_bo *bo),
+   TP_ARGS(bo),
+   TP_STRUCT__entry(
+__field(struct radeon_bo *, bo)
+__field(u32, pages)
+),
+
+   TP_fast_assign(
+  __entry->bo = bo;
+  __entry->pages = bo->tbo.num_pages;
+  ),
+   TP_printk("bo=%p, pages=%u", __entry->bo, __entry->pages)
+);
+
+DECLARE_EVENT_CLASS(radeon_fence_request,
+
+   TP_PROTO(struct drm_device *dev, u32 seqno),
+
+   TP_ARGS(dev, seqno),
+
+   TP_STRUCT__entry(
+__field(u32, dev)
+

[Bug 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

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

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

--- Comment #7 from Benjamin Franzke  
2010-11-23 11:36:58 PST ---
diska is using egl_gallium which differentiates between r300 and r600 in
drm-mode using the function "is_r3xx" provided by
winsys/radeon/drm/radeon_drm.h

This function just checks a range of pci ids, the evergreen ids lay in the
range:
static INLINE boolean is_r3xx(int pciid)
{
return (pciid > 0x3150) && (pciid < 0x796f);
}

Thats why state_trackers/egl/drm/native_drm.c loads pipe_r300.

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

[Bug 31870] New: [evergreen] Graphics freezes when selecting Atlantis from XScreenSaver

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

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

   Summary: [evergreen] Graphics freezes when selecting Atlantis
from XScreenSaver
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: jlp.bugs at gmail.com


Hardware: ATI Mobility Radeon HD 5470
Software:
XScreenSaver 5.12
KDE SC 4.5.3
Linux 2.6.37-RC3
Xorg Server 1.9.2.901
Mesa, libdrm, xf86-vide-ati all from git

Steps to reproduce:
1. Open KDE Screen Saver settings module
2. find Atlantis in OpenGL Screen Savers
3. Click on it

Actual result:
Mouse stops moving and graphics freezes. I can't use Ctrl+Alt+F1 to switch to
console. I can still SSH into that machine and can't see any process using much
CPU.

Expected:
A preview of Atlantis should be shown in the preview area.

Reproducable: Always

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

[Bug 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

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

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

--- Comment #6 from diska  2010-11-23 10:20:41 
PST ---
 export MESA_DEBUG=1
 export EGL_LOG_LEVEL=debug
/compositor 
libEGL debug: EGL search path is /usr/lib/egl
libEGL debug: added /usr/lib/egl/egl_gallium.so to module array
libEGL debug: added /usr/lib/egl/egl_dri2.so to module array
libEGL debug: added /usr/lib/egl/egl_glx.so to module array
libEGL debug: dlopen(/usr/lib/egl/egl_gallium.so)
libEGL info: use DRM for display 0x5
libEGL debug: searching for pipe module r300
libEGL debug: loaded /usr/lib/egl/pipe_r300.so
r300: Warning: Unknown chipset 0x68c1
libEGL debug: Failed to get KMS resources.  Disable modeset.
libEGL debug: the best driver is Gallium (score 100)
libEGL debug: searching for st module GLESv2
libEGL debug: loaded /usr/lib/egl/st_GLESv2.so

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

[Bug 31842] Implement GL_FIXED support

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

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

--- Comment #1 from James Willcox  2010-11-23 07:56:16 PST 
---
Oops, I meant "looks like r600g does NOT support".

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

[Bug 30167] Heroes of Newerth: Setting shader quality to medium results in corrupt rendering

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

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

--- Comment #16 from Sven Arvidsson  2010-11-23 07:31:49 PST ---
(In reply to comment #15)
> Can you try this again with the latest git master?

The problem remains (corrupt rendering with medium and high) but seems to be
slightly different now. I have uploaded new screenshots:

high:
http://www.flickr.com/photos/whizse/5201781578/

medium:
http://www.flickr.com/photos/whizse/5201187031/

all previous screenshots are here, for comparison:
http://www.flickr.com/photos/whizse/

I also noticed this error message:
 r300: ERROR: FS input generic 17 unassigned, not enough hardware slots.

Let me know if you need new debug dumps or screenshots with noopt.

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

[Bug 30166] [wine] Shader issues in rthdribl 1.2

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

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

--- Comment #5 from Sven Arvidsson  2010-11-23 07:18:17 PST ---
No change here.

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

[Bug 31836] Strange colors with R600

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

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

--- Comment #3 from Yann Le Doar?  2010-11-23 
06:19:51 PST ---
Created an attachment (id=40508)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=40508)
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 31836] Strange colors with R600

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

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

--- Comment #2 from Yann Le Doar?  2010-11-23 
06:09:09 PST ---
I enabled kms, this makes :

 (EE) AIGLX error: Calling driver entry point failed
 (EE) AIGLX: reverting to software rendering
 (II) AIGLX: Screen 0 is not DRI capable

into Xorg log

I updated libdrm-2.4.21 to libdrm-2.4.22, xf86-video-ati-6.13.1 to 
xf86-video-ati-6.13.2, Mesa 7.8.2 to 7.9, but I have again the AIGLX error.

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

Completely ignore EDID for KMS, use user-supplied kernel param (video=)?

[Paul Sokolovsky]

Hello,

There're cases when EDID may be present, but be just severely (or
seemingly) broken. Is it possible to completely and unconditionally
ignore any EDID info for KMS, and instead use user-supplied parameters?
I googled the following message:
http://www.mail-archive.com/dri-devel at lists.sourceforge.net/msg46741.html
which suggested that it's possible, but I don't have any effect doing
it myself.

It's also very hard to diagnose these issues. For example, mode
selection is driven by EDID, but there're whole 0 occurances of that
string in kernel dmesg. Passing drm.debug=1 starts to dump some
internal registers, but still no hints which and why mode was selected.

My specific issue is that there's an LVDS (of MSI X410/X430 notebook)
which has right dimensions and refresh rate, but wrong, if not say
unrelated, clock settings. The end result is that there's tearing-off,
broken sync like on an old dying TV. More details are at
http://.ubuntuforums.org/showthread.php?p=10120939 . That's on
2.6.35 (stock Ubuntu 10.10 kernel). I was able to set CVT timings on X
which gave stable picture, but no luck persuading kernel to do the same
(I used video=LVDS-1:1366x768M at 60 param, also tried more conventional
modes like 1024x768).

I'd appreciate any hints.


-- 
Best regards,
 Paul  mailto:pmiscml at gmail.com

Completely ignore EDID for KMS, use user-supplied kernel param (video=)?

[Alex Deucher]

On Mon, Nov 22, 2010 at 11:02 PM, Paul Sokolovsky  wrote:
> Hello,
>
> There're cases when EDID may be present, but be just severely (or
> seemingly) broken. Is it possible to completely and unconditionally
> ignore any EDID info for KMS, and instead use user-supplied parameters?
> I googled the following message:
> http://www.mail-archive.com/dri-devel at lists.sourceforge.net/msg46741.html
> which suggested that it's possible, but I don't have any effect doing
> it myself.
>
> It's also very hard to diagnose these issues. For example, mode
> selection is driven by EDID, but there're whole 0 occurances of that
> string in kernel dmesg. Passing drm.debug=1 starts to dump some
> internal registers, but still no hints which and why mode was selected.
>
> My specific issue is that there's an LVDS (of MSI X410/X430 notebook)
> which has right dimensions and refresh rate, but wrong, if not say
> unrelated, clock settings. The end result is that there's tearing-off,
> broken sync like on an old dying TV. More details are at
> http://.ubuntuforums.org/showthread.php?p=10120939 . That's on
> 2.6.35 (stock Ubuntu 10.10 kernel). I was able to set CVT timings on X
> which gave stable picture, but no luck persuading kernel to do the same
> (I used video=LVDS-1:1366x768M at 60 param, also tried more conventional
> modes like 1024x768).
>
> I'd appreciate any hints.

Assuming your laptop contains a radeon, the panel timing comes from a
table in the vbios.  The timing problem is most likely not due to an
EDID problem, but to pll dividers that that panel doesn't like.  Try
booting with radeon.new_pll=0 on the kernel command line or try kernel
2.6.37.

Alex

[Bug 31193] [regression] aa43176e break water reflections

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

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

--- Comment #7 from Fabio Pedretti  2010-11-23 01:36:32 
PST ---
Confirmed, thanks! The last 0ad problem is bug #31159, though this is
reproducible also with swrastg.

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

[Bug 31827] r300g fails to link a GL program (Mesa 7.9)

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

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

--- Comment #5 from Da Fox  2010-11-23 00:54:49 
PST ---
(In reply to comment #4)
> I don't have 51b895041c65f7ec9ecda48e79279dde29258b07 in my Mesa tree, which
> means it doesn't exist. Don't you have some patches applied locally?

You are correct. I must have copy the wrong line...
Gitk shows "e7c74a7dfab789496761226fe62a08f2d9fea5c7 - st/mesa: set
MaxUniformComponents" for mesa.

51b895041c65f7ec9ecda48e79279dde29258b07 appears to be from libdrm.

Sorry for the mixup.

-- 
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/kms: improve pflip precision on r1xx-r4xx

[Alex Deucher]

The update pending bit has a separate enable bit.

Cc: Mario Kleiner 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/r100.c   |8 +---
 drivers/gpu/drm/radeon/radeon_reg.h |2 ++
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 2316f73..300b4a6 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -76,6 +76,8 @@ void r100_pre_page_flip(struct radeon_device *rdev, int crtc)
/* make sure flip is at vb rather than hb */
tmp = RREG32(RADEON_CRTC_OFFSET_CNTL + radeon_crtc->crtc_offset);
tmp &= ~RADEON_CRTC_OFFSET_FLIP_CNTL;
+   /* make sure pending bit is asserted */
+   tmp |= RADEON_CRTC_GUI_TRIG_OFFSET_LEFT_EN;
WREG32(RADEON_CRTC_OFFSET_CNTL + radeon_crtc->crtc_offset, tmp);

/* set pageflip to happen as late as possible in the vblank interval.
@@ -104,9 +106,9 @@ u32 r100_page_flip(struct radeon_device *rdev, int crtc_id, 
u64 crtc_base)
/* update the scanout addresses */
WREG32(RADEON_CRTC_OFFSET + radeon_crtc->crtc_offset, tmp);

-   /* Note: We don't wait for update_pending to assert, as this never
-* happens for some reason on R1xx - R4xx. Adds a bit of imprecision.
-*/
+   /* Wait for update_pending to go high. */
+   while (!(RREG32(RADEON_CRTC_OFFSET + radeon_crtc->crtc_offset) & 
RADEON_CRTC_OFFSET__GUI_TRIG_OFFSET));
+   DRM_DEBUG("Update pending now high. Unlocking vupdate_lock.\n");

/* Unlock the lock, so double-buffering can take place inside vblank */
tmp &= ~RADEON_CRTC_OFFSET__OFFSET_LOCK;
diff --git a/drivers/gpu/drm/radeon/radeon_reg.h 
b/drivers/gpu/drm/radeon/radeon_reg.h
index 26c43e2..0a310b7 100644
--- a/drivers/gpu/drm/radeon/radeon_reg.h
+++ b/drivers/gpu/drm/radeon/radeon_reg.h
@@ -510,6 +510,8 @@
 #   define RADEON_CRTC_TILE_EN  (1 << 15)
 #   define RADEON_CRTC_OFFSET_FLIP_CNTL (1 << 16)
 #   define RADEON_CRTC_STEREO_OFFSET_EN (1 << 17)
+#   define RADEON_CRTC_GUI_TRIG_OFFSET_LEFT_EN  (1 << 28)
+#   define RADEON_CRTC_GUI_TRIG_OFFSET_RIGHT_EN (1 << 29)

 #define R300_CRTC_TILE_X0_Y0   0x0350
 #define R300_CRTC2_TILE_X0_Y0  0x0358
-- 
1.7.1.1

[Bug 31193] [regression] aa43176e break water reflections

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

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

Tom Stellard  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tom Stellard  2010-11-23 00:15:36 
PST ---
Thanks for the link to the game, that was a big help.

This is fixed in mesa git by commit 4265c2f81980eae37f6081979c65b2d1bae60b82

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

[Bug 31193] [regression] aa43176e break water reflections

[bugzilla-daemon]

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

Tom Stellard tstel...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Tom Stellard tstel...@gmail.com 2010-11-23 00:15:36 PST 
---
Thanks for the link to the game, that was a big help.

This is fixed in mesa git by commit 4265c2f81980eae37f6081979c65b2d1bae60b82

-- 
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 31827] r300g fails to link a GL program (Mesa 7.9)

[bugzilla-daemon]

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

--- Comment #5 from Da Fox da_...@mad.scientist.com 2010-11-23 00:54:49 PST 
---
(In reply to comment #4)
 I don't have 51b895041c65f7ec9ecda48e79279dde29258b07 in my Mesa tree, which
 means it doesn't exist. Don't you have some patches applied locally?

You are correct. I must have copypasted the wrong line...
Gitk shows e7c74a7dfab789496761226fe62a08f2d9fea5c7 - st/mesa: set
MaxUniformComponents for mesa.

51b895041c65f7ec9ecda48e79279dde29258b07 appears to be from libdrm.

Sorry for the mixup.

-- 
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 31193] [regression] aa43176e break water reflections

[bugzilla-daemon]

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

--- Comment #7 from Fabio Pedretti fabio@libero.it 2010-11-23 01:36:32 
PST ---
Confirmed, thanks! The last 0ad problem is bug #31159, though this is
reproducible also with swrastg.

-- 
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 31836] Strange colors with R600

[bugzilla-daemon]

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

--- Comment #2 from Yann Le Doaré y...@linuxconsole.org 2010-11-23 06:09:09 
PST ---
I enabled kms, this makes :

 (EE) AIGLX error: Calling driver entry point failed
 (EE) AIGLX: reverting to software rendering
 (II) AIGLX: Screen 0 is not DRI capable

into Xorg log

I updated libdrm-2.4.21 to libdrm-2.4.22, xf86-video-ati-6.13.1 to 
xf86-video-ati-6.13.2, Mesa 7.8.2 to 7.9, but I have again the AIGLX error.

-- 
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 31836] Strange colors with R600

[bugzilla-daemon]

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

--- Comment #3 from Yann Le Doaré y...@linuxconsole.org 2010-11-23 06:19:51 
PST ---
Created an attachment (id=40508)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=40508)
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 30166] [wine] Shader issues in rthdribl 1.2

[bugzilla-daemon]

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

--- Comment #5 from Sven Arvidsson s...@whiz.se 2010-11-23 07:18:17 PST ---
No change here.

-- 
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 31842] Implement GL_FIXED support

[bugzilla-daemon]

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

--- Comment #1 from James Willcox sn...@snorp.net 2010-11-23 07:56:16 PST ---
Oops, I meant looks like r600g does NOT support.

-- 
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 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

[bugzilla-daemon]

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

--- Comment #6 from diska discardi.nic...@gmail.com 2010-11-23 10:20:41 PST 
---
 export MESA_DEBUG=1
 export EGL_LOG_LEVEL=debug
/compositor 
libEGL debug: EGL search path is /usr/lib/egl
libEGL debug: added /usr/lib/egl/egl_gallium.so to module array
libEGL debug: added /usr/lib/egl/egl_dri2.so to module array
libEGL debug: added /usr/lib/egl/egl_glx.so to module array
libEGL debug: dlopen(/usr/lib/egl/egl_gallium.so)
libEGL info: use DRM for display 0x5
libEGL debug: searching for pipe module r300
libEGL debug: loaded /usr/lib/egl/pipe_r300.so
r300: Warning: Unknown chipset 0x68c1
libEGL debug: Failed to get KMS resources.  Disable modeset.
libEGL debug: the best driver is Gallium (score 100)
libEGL debug: searching for st module GLESv2
libEGL debug: loaded /usr/lib/egl/st_GLESv2.so

-- 
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 31870] New: [evergreen] Graphics freezes when selecting Atlantis from XScreenSaver

[bugzilla-daemon]

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

   Summary: [evergreen] Graphics freezes when selecting Atlantis
from XScreenSaver
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: jlp.b...@gmail.com


Hardware: ATI Mobility Radeon HD 5470
Software:
XScreenSaver 5.12
KDE SC 4.5.3
Linux 2.6.37-RC3
Xorg Server 1.9.2.901
Mesa, libdrm, xf86-vide-ati all from git

Steps to reproduce:
1. Open KDE Screen Saver settings module
2. find Atlantis in OpenGL Screen Savers
3. Click on it

Actual result:
Mouse stops moving and graphics freezes. I can't use Ctrl+Alt+F1 to switch to
console. I can still SSH into that machine and can't see any process using much
CPU.

Expected:
A preview of Atlantis should be shown in the preview area.

Reproducable: Always

-- 
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 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

[bugzilla-daemon]

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

--- Comment #8 from diska discardi.nic...@gmail.com 2010-11-23 11:51:15 PST 
---
my pciid is 68c1

-- 
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 31827] r300g fails to link a GL program (Mesa 7.9)

[bugzilla-daemon]

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

--- Comment #6 from Hydrar hydrardraco...@gmail.com 2010-11-23 11:53:46 PST 
---
Just updated both my computers to latest git today, the test case prints
program linking succeeded on my RV530(X1600), but fails on my RV410(Mobility
X700), with same git versions of libdrm, mesa and xf86-video-ati.

-- 
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 31841] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

[bugzilla-daemon]

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

diska discardi.nic...@gmail.com changed:

   What|Removed |Added

Product|DRI |Mesa
Version|unspecified |git
  Component|DRM/Radeon  |Drivers/DRI/Radeon

--- Comment #10 from diska discardi.nic...@gmail.com 2010-11-23 12:01:39 PST 
---
the problem is in mesa drm code 

mesa/src/gallium/winsys/radeon/drm/radeon_drm.h

-- 
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 31827] r300g fails to link a GL program (Mesa 7.9)

[bugzilla-daemon]

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

--- Comment #7 from Marek Olšák mar...@gmail.com 2010-11-23 13:01:54 PST ---
Please query GL_LINK_STATUS and post what it says.

-- 
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 31827] r300g fails to link a GL program (Mesa 7.9)

[bugzilla-daemon]

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

--- Comment #8 from Hicham HAOUARI hicham.haou...@gmail.com 2010-11-23 
13:07:20 PST ---
(In reply to comment #7)
 Please query GL_LINK_STATUS and post what it says.

I think that is what I have done in the testcase, or am I missing something ?

Anyway, I retested with Fedora rawhide, which ships mesa-7.10 snapshot from
20101118 and I still get the same failure.

kernel : 2.6.36

libdrm : 2.4.23 branch git snapshot from 20101123

-- 
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 31876] New: r600g crashes in screen init

[bugzilla-daemon]

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

   Summary: r600g crashes in screen init
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: sn...@snorp.net


gdb --args glxinfo
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/glxinfo...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/glxinfo 
[Thread debugging using libthread_db enabled]
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 4.3.0 r600 (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/gallium/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/dri/gallium/r600_dri.so
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenByBusid: Searching for BusID pci::01:05.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmOpenByBusid: drmOpenMinor returns 6
drmOpenByBusid: Interface 1.4 failed, trying 1.1
drmOpenByBusid: drmGetBusid reports pci::01:05.0

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x006b4ecd in driCreateNewScreen (scrn=0, ddx_version=0xb208, 
dri_version=0xb1fc, drm_version=0xb1f0, frame_buffer=0xb1d4, 
pSAREA=0xb7ffb000, fd=6, extensions=0x17e2cc, driver_modes=0xb218, 
loaderPrivate=0x805b628) at ../common/dri_util.c:830
#2  0x0016a820 in CallCreateNewScreen (screen=0, priv=0x805a2e0)
at dri_glx.c:434
#3  driCreateScreen (screen=0, priv=0x805a2e0) at dri_glx.c:875
#4  0x00147a2c in AllocAndFetchScreenConfigs (dpy=0x8050008) at glxext.c:762
#5  __glXInitialize (dpy=0x8050008) at glxext.c:859
#6  0x0014485a in GetGLXPrivScreenConfig (dpy=0x8050008, scrn=0, 
ppriv=0xb44c, ppsc=0xb448) at glxcmds.c:130
#7  0x001459c6 in glXChooseVisual (dpy=0x8050008, screen=0, 
attribList=0x804f0e0) at glxcmds.c:1152
#8  0x080493a8 in ?? ()
#9  0x0804a44c in ?? ()
#10 0x002f9bd6 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#11 0x08048e11 in ?? ()

This is with xorg-edgers in Ubuntu Lucid, which has Mesa as of 20101122.  I'm
running on a 785G.

-- 
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: [Regression, post-2.6.37-rc2] Unable to start KDE with 2.6.37-rc3 on Acer Ferrari One

[Rafael J. Wysocki]

On Wednesday, November 24, 2010, Rafael J. Wysocki wrote:
 Hi,
 
 I cannot start KDE with the 2.6.37-rc3 kernel.  The X server and display
 manager start normally, but when I attempt to log into KDE, it attempts to
 start, but then the X apparently crashes and this appears in the dmesg output:
 
 [   24.342287] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
 46097920 4325376 too big
 [   24.342298] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
 stream 502
 [   24.342304] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 [   24.694106] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 [   93.938946] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
 46097920 4325376 too big
 [   93.938956] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
 stream 502
 [   93.938962] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 [   94.278050] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 [  114.898043] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
 46097920 4325376 too big
 [  114.898053] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
 stream 502
 [  114.898058] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 [  115.266113] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 [  129.722472] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 [  142.984314] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
 46097920 4325376 too big
 [  142.984324] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
 stream 502
 [  142.984330] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 [  143.370083] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 
 This doesn't happen with 2.6.37-rc2.

Reverting the following commit:

commit 16790569eddf4d406a16a65f4750f405fa669c52
Author: Alex Deucher alexdeuc...@gmail.com
Date:   Sun Nov 14 20:24:35 2010 -0500

drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx

fixes the issue for me (so everyone involved is already in the Cc list ;-)).

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

Re: [Regression, post-2.6.37-rc2] Unable to start KDE with 2.6.37-rc3 on Acer Ferrari One

[Alex Deucher]

2010/11/23 Rafael J. Wysocki r...@sisk.pl:
 On Wednesday, November 24, 2010, Rafael J. Wysocki wrote:
 Hi,

 I cannot start KDE with the 2.6.37-rc3 kernel.  The X server and display
 manager start normally, but when I attempt to log into KDE, it attempts to
 start, but then the X apparently crashes and this appears in the dmesg 
 output:

 [   24.342287] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
 46097920 4325376 too big
 [   24.342298] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
 stream 502
 [   24.342304] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 [   24.694106] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 [   93.938946] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
 46097920 4325376 too big
 [   93.938956] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
 stream 502
 [   93.938962] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 [   94.278050] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 [  114.898043] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
 46097920 4325376 too big
 [  114.898053] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
 stream 502
 [  114.898058] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 [  115.266113] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 [  129.722472] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 [  142.984314] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
 46097920 4325376 too big
 [  142.984324] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
 stream 502
 [  142.984330] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
 [  143.370083] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id

 This doesn't happen with 2.6.37-rc2.

 Reverting the following commit:

 commit 16790569eddf4d406a16a65f4750f405fa669c52
 Author: Alex Deucher alexdeuc...@gmail.com
 Date:   Sun Nov 14 20:24:35 2010 -0500

    drm/radeon/kms: fix and unify tiled buffer alignment checking for r6xx/7xx

 fixes the issue for me (so everyone involved is already in the Cc list ;-)).


Are you sure you've got the right commit?  That shouldn't change the
calculation that's failing at all.  I'd guess it's probably one of
these:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d33ef52d9db8a36900dd53f2e32db9a521ace259
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f30df2fad0c901e74ac9a52a488a54c69a373a41

Can you attach your xorg log as well?

Alex

 Thanks,
 Rafael

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

Re: XvMC gets iDCT support (at least on R600)

[Alex Deucher]

2010/11/23 Christian König deathsim...@vodafone.de:
 Am Sonntag, den 21.11.2010, 11:28 -0500 schrieb Alex Deucher:
 Make sure you are using the latest drm patches.  Dave and I fixed a
 number of bugs in the CS checker in 2.6.37.  Also, make sure you have
 the latest mesa bits.  I fixed the buffer alignment handling in r600g.
 Just merged my mesa branch with master yesterday, I will update the
 kernel as soon as I find time to do so.

 But i don't think that this is already fixed: If i add a new colour
 format to the r600_translate_colorswap function in r600_state_inlines.h,
 but forget to also add those to the r600_translate_colorformat function
 I get a nice opps because of a divide by zero in the drm code,
 completely crashing the graphics subsystem.

That should be fixed already.


 Trying to use a constant as a texture locations also results in an gpu
 hangup/reset. This should also be prevented in the cb checker (or does
 it checks only the real command buffer and not the shaders itself?).


It doesn't check the shaders, it just checks the command stream to
make sure the enabled buffers are valid and to translate the bo
handles to MC addresses.

 And when the drm code detects a hanging command buffer and resets the
 gpu, it would be nice to kill the process that issued this command
 buffer, because it make no sense that an userspace application keeps
 issuing the same invalid command buffer over and over again (after an
 reasonable amounts of retries of course).

 Using tiled surfaces may help if you are doing a lot of texture
 lookups.  There is support in r600g if you are using the latest drm
 and mesa code.
 How far goes tilling on r600 hardware? Is it one, two or tree layer
 tilling? What i mean is this:

 Normal linear layout:
 A B C D E F G H I J K L M N O P

 One layer tilling:
 A B E F I J M N
 C D G H K L O P

 Two layer tilling:
 A B E F
 C D G H
 I J M N
 K L O P

 And so on, (if I understood the concept of tilling right).

There are two types of tiling you can enable, 1D, and 2D.  1D
basically divides up the buffer into 8x8 pixel micro tiles.  2D tiling
uses larger macro tiles made up of micro tiles, hence the 1D and 2D.
Tiling is meant to maximize cache locality and memory bandwidth.  1D
tiles map roughly to a cache line and you get better cache utilization
for a tile rather than a scanline as you have similar addresses in 2D
space closer together.  Macro tiles maximize bandwidth by optimally
distributing load across all memory channels.  For optimal
performance, tiling should always be enabled, but it requires a fair
amount of driver infrastructure which is just now coming online.
E.g., if you want to manipulate a tiled buffer with the CPU, you'd
need to either calculate the addresses yourself on a per-pixel basis,
or you need to use the 3D engine to blit to a linear buffer.


 For an iDCT of a 8x8 pixel block I would need tree layer tilling, so a
 8x8 block of 64 elements are stored linear near to each other in
 memory. Would that work on the hardware?

It's transparent to the application, but it sounds like it would
probably help in this case.


 Another thing that would really help is if I could calculate 4 elements
 in one pixel shader run instead of just one, but for this to I would
 need R32G32B32A32 colour buffers, and I simply can't get them to work
 probably.

 I added the following lines to the r600_cb function in r600_state.c:
        desc = util_format_description(rtex-resource.base.b.format);
        if (desc-colorspace == UTIL_FORMAT_COLORSPACE_SRGB)
                ntype = V_0280A0_NUMBER_SRGB;
        else if (desc-layout == UTIL_FORMAT_LAYOUT_PLAIN) {
                switch(desc-channel[0].type) {
                case UTIL_FORMAT_TYPE_UNSIGNED:
                        ntype = V_0280A0_NUMBER_UNORM;
                        break;

                case UTIL_FORMAT_TYPE_SIGNED:
                        ntype = V_0280A0_NUMBER_SNORM;
                        break;
                }
        }
 This seems to get R16_SNORM colour buffers working, but texture uploads
 and even a simple R32_FLOAT colour buffer won't work right. I looks like
 a have to use the right combination of V_0280A0_FORMAT, V_0280A0_NUMBER,
 V_0280A0_BLEND_CLAMP, V_0280A0_BLEND_BYPASS etc, but I just keep having
 strange artefacts every n pixel (for example R32_FLOAT only renders the
 even rows correctly).


Yeah, you'd need to sort out the state properly for these new formats.

Alex

 Any help with this would be really appreciated.

 Regards,
 Christian.


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

Re: [Regression, post-2.6.37-rc2] Unable to start KDE with 2.6.37-rc3 on Acer Ferrari One

[Rafael J. Wysocki]

On Wednesday, November 24, 2010, Alex Deucher wrote:
 2010/11/23 Rafael J. Wysocki r...@sisk.pl:
  On Wednesday, November 24, 2010, Rafael J. Wysocki wrote:
  Hi,
 
  I cannot start KDE with the 2.6.37-rc3 kernel.  The X server and display
  manager start normally, but when I attempt to log into KDE, it attempts to
  start, but then the X apparently crashes and this appears in the dmesg 
  output:
 
  [   24.342287] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
  46097920 4325376 too big
  [   24.342298] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
  stream 502
  [   24.342304] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
  [   24.694106] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
  [   93.938946] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
  46097920 4325376 too big
  [   93.938956] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
  stream 502
  [   93.938962] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
  [   94.278050] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
  [  114.898043] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
  46097920 4325376 too big
  [  114.898053] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
  stream 502
  [  114.898058] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
  [  115.266113] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
  [  129.722472] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
  [  142.984314] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
  46097920 4325376 too big
  [  142.984324] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
  stream 502
  [  142.984330] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
  [  143.370083] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 
  This doesn't happen with 2.6.37-rc2.
 
  Reverting the following commit:
 
  commit 16790569eddf4d406a16a65f4750f405fa669c52
  Author: Alex Deucher alexdeuc...@gmail.com
  Date:   Sun Nov 14 20:24:35 2010 -0500
 
 drm/radeon/kms: fix and unify tiled buffer alignment checking for 
  r6xx/7xx
 
  fixes the issue for me (so everyone involved is already in the Cc list ;-)).
 
 
 Are you sure you've got the right commit?

Well, as I said, I reverted that particular commit and things started to work.

 That shouldn't change the calculation that's failing at all.  I'd guess it's
 probably one of these:
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d33ef52d9db8a36900dd53f2e32db9a521ace259
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f30df2fad0c901e74ac9a52a488a54c69a373a41

I don't know.  Perhaps there are some interactions between the two and the
reverted one.  I can try reverting these tomorrow if you want me to.

 Can you attach your xorg log as well?

Sure, attached (the working case).

Thanks,
Rafael
[11.926] 
X.Org X Server 1.8.0
Release Date: 2010-04-02
[11.927] X Protocol Version 11, Revision 0
[11.927] Build Operating System: openSUSE SUSE LINUX
[11.927] Current Operating System: Linux ferrari 2.6.37-rc2-rjw+ #162 SMP PREEMPT Tue Nov 16 23:33:09 CET 2010 x86_64
[11.927] Kernel command line: root=/dev/sda3 resume=/dev/sda2
[11.927] Build Date: 19 August 2010  03:34:22PM
[11.927]  
[11.927] Current version of pixman: 0.18.0
[11.927] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[11.927] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[11.928] (==) Log file: /var/log/Xorg.0.log, Time: Wed Nov 24 01:44:11 2010
[11.928] (==) Using config directory: /etc/X11/xorg.conf.d
[11.929] (==) No Layout section.  Using the first Screen section.
[11.929] (**) |--Screen Default Screen (0)
[11.929] (**) |   |--Monitor Default Monitor
[11.929] (**) |   |--Device Default Device
[11.929] (==) Automatically adding devices
[11.929] (==) Automatically enabling devices
[11.930] (WW) The directory /usr/share/fonts/TTF/ does not exist.
[11.930] 	Entry deleted from font path.
[11.930] (WW) The directory /usr/share/fonts/OTF/ does not exist.
[11.930] 	Entry deleted from font path.
[11.930] (WW) The directory /usr/share/fonts/misc/sgi does not exist.
[11.930] 	Entry deleted from font path.
[11.930] (==) FontPath set to:
	/usr/share/fonts/misc:unscaled,
	/usr/share/fonts/Type1/,
	/usr/share/fonts/100dpi:unscaled,
	/usr/share/fonts/75dpi:unscaled,
	/usr/share/fonts/URW/,
	/usr/share/fonts/cyrillic:unscaled,
	/usr/share/fonts/truetype/
[11.930] (==) ModulePath set to /usr/lib64/xorg/modules/updates,/usr/lib64/xorg/modules
[11.930] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[11.930] (II) 

Re: [Regression, post-2.6.37-rc2] Unable to start KDE with 2.6.37-rc3 on Acer Ferrari One

[Alex Deucher]

On Tue, Nov 23, 2010 at 8:45 PM, Rafael J. Wysocki r...@sisk.pl wrote:
 On Wednesday, November 24, 2010, Alex Deucher wrote:
 2010/11/23 Rafael J. Wysocki r...@sisk.pl:
  On Wednesday, November 24, 2010, Rafael J. Wysocki wrote:
  Hi,
 
  I cannot start KDE with the 2.6.37-rc3 kernel.  The X server and display
  manager start normally, but when I attempt to log into KDE, it attempts to
  start, but then the X apparently crashes and this appears in the dmesg 
  output:
 
  [   24.342287] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
  46097920 4325376 too big
  [   24.342298] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
  stream 502
  [   24.342304] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
  [   24.694106] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
  [   93.938946] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
  46097920 4325376 too big
  [   93.938956] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
  stream 502
  [   93.938962] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
  [   94.278050] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
  [  114.898043] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
  46097920 4325376 too big
  [  114.898053] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
  stream 502
  [  114.898058] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
  [  115.266113] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
  [  129.722472] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
  [  142.984314] radeon :01:05.0: r600_cs_track_validate_cb offset[0] 0 
  46097920 4325376 too big
  [  142.984324] radeon :01:05.0: r600_packet3_check:1331 invalid cmd 
  stream 502
  [  142.984330] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
  [  143.370083] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
 
  This doesn't happen with 2.6.37-rc2.
 
  Reverting the following commit:
 
  commit 16790569eddf4d406a16a65f4750f405fa669c52
  Author: Alex Deucher alexdeuc...@gmail.com
  Date:   Sun Nov 14 20:24:35 2010 -0500
 
     drm/radeon/kms: fix and unify tiled buffer alignment checking for 
  r6xx/7xx
 
  fixes the issue for me (so everyone involved is already in the Cc list 
  ;-)).
 

 Are you sure you've got the right commit?

 Well, as I said, I reverted that particular commit and things started to work.

 That shouldn't change the calculation that's failing at all.  I'd guess it's
 probably one of these:
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d33ef52d9db8a36900dd53f2e32db9a521ace259
 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f30df2fad0c901e74ac9a52a488a54c69a373a41

 I don't know.  Perhaps there are some interactions between the two and the
 reverted one.  I can try reverting these tomorrow if you want me to.

Can you try just reverting this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d33ef52d9db8a36900dd53f2e32db9a521ace259

I think the real issue is a bug in the 3D driver (probably a flush at
the wrong time) that one of these commits exposing.

Alex


 Can you attach your xorg log as well?

 Sure, attached (the working case).

 Thanks,
 Rafael

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

[Bug 31880] New: [i915g]

[bugzilla-daemon]

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

   Summary: [i915g]
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/i915g
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: v...@vmware.com
CC: wallbra...@gmail.com


mesa: 78a340fd487c56468ace7347a53f95a0c751c419 (master)

chipset: 945GM (Intel GMA 950)
system architecture: i686
xserver-xorg-video-intel: 2:2.12.0-1ubuntu5.1
libdrm-intel1: 2.4.21-1ubuntu2.1
kernel version: 2.6.35-22-generic
Linux distribution: Ubuntu 10.10 i386

Run piglit vpfp-generic vp-arl-constant-array-huge test.

$ ./bin/vpfp-generic tests/shaders/generic/vp-arl-constant-array-huge.vpfp
-auto
Probe at (50,50)
  Expected: 0.50 1.00 1.00 0.00
  Observed: 0.00 0.00 0.00 0.00
Test tests/shaders/generic/vp-arl-constant-array-huge.vpfp:137 failed
src/gallium/auxiliary/draw/draw_pt_emit.c:93:draw_pt_emit_prepare: Assertion
`emit_sz != 0' failed.

(gdb) bt
#0  0x010d122b in _debug_assert_fail (expr=0x1958c40 emit_sz != 0,
file=0x1958c14 src/gallium/auxiliary/draw/draw_pt_emit.c, line=93,
function=0x1958c6e draw_pt_emit_prepare)
at src/gallium/auxiliary/util/u_debug.c:233
#1  0x01100798 in draw_pt_emit_prepare (emit=0x8fca078, prim=7,
max_vertices=0x8fc73cc) at src/gallium/auxiliary/draw/draw_pt_emit.c:93
#2  0x010fdc16 in llvm_middle_end_prepare (middle=0x8fc9fc0, in_prim=7, opt=3,
max_vertices=0x8fc73cc) at
src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:120
#3  0x010a5b2a in vsplit_prepare (frontend=0x8fc73b0, in_prim=7,
middle=0x8fc9fc0, opt=3) at src/gallium/auxiliary/draw/draw_pt_vsplit.c:170
#4  0x0109b3be in draw_pt_arrays (draw=0x8f74340, prim=7, start=0, count=4) at
src/gallium/auxiliary/draw/draw_pt.c:111
#5  0x0109bf91 in draw_vbo (draw=0x8f74340, info=0xbfeb58a4) at
src/gallium/auxiliary/draw/draw_pt.c:481
#6  0x0106c988 in i915_draw_vbo (pipe=0x8f79368, info=0xbfeb58a4) at
src/gallium/drivers/i915/i915_context.c:81
#7  0x0181dba5 in st_draw_vbo (ctx=0x8fdee50, arrays=0x9022e30,
prims=0x9021804, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0,
max_index=3) at src/mesa/state_tracker/st_draw.c:732
#8  0x018a2f0d in vbo_exec_vtx_flush (exec=0x9021690, unmap=1 '\001') at
src/mesa/vbo/vbo_exec_draw.c:381
#9  0x0189edfe in vbo_exec_FlushVertices_internal (ctx=0x8fdee50, unmap=1
'\001') at src/mesa/vbo/vbo_exec_api.c:937
#10 0x0189ee9d in vbo_exec_FlushVertices (ctx=0x8fdee50, flags=1) at
src/mesa/vbo/vbo_exec_api.c:971
#11 0x017be818 in _mesa_ReadPixels (x=50, y=50, width=1, height=1, format=6408,
type=5126, pixels=0xbfeb5a98) at src/mesa/main/readpix.c:171
#12 0x0805010f in piglit_probe_pixel_rgba (x=50, y=50, expected=0x90149f8) at
piglit/tests/util/piglit-util.c:189
#13 0x0804d896 in Test::run (this=0x90149e8) at
piglit/tests/shaders/vpfp-generic.cpp:199
#14 0x0804d9c3 in TestGroup::run (this=0x8056444) at
piglit/tests/shaders/vpfp-generic.cpp:226
#15 0x0804e2aa in piglit_display () at
piglit/tests/shaders/vpfp-generic.cpp:372
#16 0x08051e43 in display () at piglit/tests/util/piglit-framework.c:52
#17 0x00125820 in fghRedrawWindow (window=DWARF-2 expression error: DW_OP_reg
operations must be used either alone or in conjuction with DW_OP_piece or
DW_OP_bit_piece.
) at freeglut_main.c:210
#18 fghcbDisplayWindow (window=DWARF-2 expression error: DW_OP_reg operations
must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.
) at freeglut_main.c:227
#19 0x00129660 in fgEnumWindows (enumCallback=0x125790 fghcbDisplayWindow,
enumerator=0xbfeb5c28) at freeglut_structure.c:394
#20 0x00125cdb in fghDisplayAll () at freeglut_main.c:249
#21 glutMainLoopEvent () at freeglut_main.c:1450
#22 0x00126605 in glutMainLoop () at freeglut_main.c:1498
#23 0x08051fec in main (argc=2, argv=0xbfeb5eb4) at
piglit/tests/util/piglit-framework.c:118

-- 
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 31880] [i915g] src/gallium/auxiliary/draw/draw_pt_emit.c:93:draw_pt_emit_prepare: Assertion `emit_sz != 0' failed.

[bugzilla-daemon]

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

Vinson Lee v...@vmware.com changed:

   What|Removed |Added

Summary|[i915g] |[i915g]
   ||src/gallium/auxiliary/draw/
   ||draw_pt_emit.c:93:draw_pt_e
   ||mit_prepare: Assertion
   ||`emit_sz != 0' failed.

-- 
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 31881] New: [i915g] SIGSEGV piglit vpfp-generic vp-arl-constant-array-huge-varying

[bugzilla-daemon]

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

   Summary: [i915g] SIGSEGV piglit vpfp-generic
vp-arl-constant-array-huge-varying
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/i915g
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: v...@vmware.com
CC: wallbra...@gmail.com


mesa: 78a340fd487c56468ace7347a53f95a0c751c419 (master)

chipset: 945GM (Intel GMA 950)
system architecture: i686
xserver-xorg-video-intel: 2:2.12.0-1ubuntu5.1
libdrm-intel1: 2.4.21-1ubuntu2.1
kernel version: 2.6.35-22-generic
Linux distribution: Ubuntu 10.10 i386

Run piglit vpfp-generic vp-arl-constant-array-huge-varying test. The test hits
a segmentation fault.

$ ./bin/vpfp-generic tests/shaders/generic/vp-arl-constant-array-huge-varying
-auto
Program terminated with signal 11, Segmentation fault.
#0  0x0165cd0c in llvm::ConstantInt::get(llvm::LLVMContext, llvm::APInt
const) () from
/home/mks-hackers/mesa/build/linux-x86-debug/gallium/targets/dri-i915/i915_dri.so
(gdb) bt
#0  0x0165cd0c in llvm::ConstantInt::get(llvm::LLVMContext, llvm::APInt
const) () from mesa/build/linux-x86-debug/gallium/targets/dri-i915/i915_dri.so
#1  0x0048 in ?? ()
#2  0xbff03300 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

-- 
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 30754] X server crashes with SEGFAULT when using virtualbox on Evergreen

[bugzilla-daemon]

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

--- Comment #3 from Frédéric L. W. Meunier othe...@pervalidus.net 2010-11-23 
21:43:50 PST ---
I also get random crashes with Bluefish, an editor.

Is this a new issue or the same ? I'm attaching the backtrace.

You can compare with the one I added at
https://bugs.freedesktop.org/show_bug.cgi?id=31299

This time, I'm using xorg-server 1.9.2, Mesa 7.9 git (20101122) and
xf86-video-ati 6.13.99 git (20101119).

-- 
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: Completely ignore EDID for KMS, use user-supplied kernel param (video=)?

[Paul Sokolovsky]

Hello,

On Tue, 23 Nov 2010 02:00:51 -0500
Alex Deucher alexdeuc...@gmail.com wrote:

[]

  My specific issue is that there's an LVDS (of MSI X410/X430
  notebook) which has right dimensions and refresh rate, but wrong,
  if not say unrelated, clock settings. The end result is that
  there's tearing-off, broken sync like on an old dying TV. More
  details are at
  http://.ubuntuforums.org/showthread.php?p=10120939 . That's on
  2.6.35 (stock Ubuntu 10.10 kernel). I was able to set CVT timings
  on X which gave stable picture, but no luck persuading kernel to do
  the same (I used video=LVDS-1:1366x7...@60 param, also tried more
  conventional modes like 1024x768).
 
  I'd appreciate any hints.
 
 Assuming your laptop contains a radeon, the panel timing comes from a
 table in the vbios.  The timing problem is most likely not due to an
 EDID problem, but to pll dividers that that panel doesn't like.  Try
 booting with radeon.new_pll=0 on the kernel command line or try kernel
 2.6.37.

Pure magic! ;-) Thanks for quick reply, that worked, even though I
really thought that's a case of broken EDID, as X had the same
behavior, which I could work around by setting CVT timing using xrandr
(while nomodeset for kernel). Just for the info, that was for Radeon HD
3200, though the same issue was reported for Radeon X1250.

However, can you please elaborate about overring mode for KMS-based
driver on the kernel command line? I studied kernel source more myself,
and see that video= parsing for KMS is being performed by
drm_fb_helper.c, and its routines seem to be called by the radeon
driver. So, based on the code

DRM_DEBUG_KMS(cmdline mode for connector %s
%d...@%dhz%s%s%s\n, drm_get_connector_name(connector), xres,
yres, (refresh) ? refresh : 60, (rb) ?  reduced blanking :
, (margins) ?  with margins : , (interlace) ?
 interlaced : );

I set following kernel params:

drm.debug=7 video=LVDS-1:1366x7...@60

But expected output didn't appear in dmesg. I also tried
video=LVDS:1366x7...@60 with the same result. What could be wrong?

 
 Alex


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel