Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list

[Guennadi Liakhovetski]

On Sat, 14 May 2011, Mauro Carvalho Chehab wrote:

> Em 18-04-2011 17:15, Jesse Barker escreveu:
> > One of the big issues we've been faced with at Linaro is around GPU
> > and multimedia device integration, in particular the memory management
> > requirements for supporting them on ARM.  This next cycle, we'll be
> > focusing on driving consensus around a unified memory management
> > solution for embedded systems that support multiple architectures and
> > SoCs.  This is listed as part of our working set of requirements for
> > the next six-month cycle (in spite of the URL, this is not being
> > treated as a graphics-specific topic - we also have participation from
> > multimedia and kernel working group folks):
> > 
> >   https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics
> 
> As part of the memory management needs, Linaro organized several discussions
> during Linaro Development Summit (LDS), at Budapest, and invited me and other
> members of the V4L and DRI community to discuss about the requirements.
> I wish to thank Linaro for its initiative.

[snip]

> Btw, the need of managing buffers is currently being covered by the proposal
> for new ioctl()s to support multi-sized video-buffers [1].
> 
> [1] http://www.spinics.net/lists/linux-media/msg30869.html
> 
> It makes sense to me to discuss such proposal together with the above 
> discussions, 
> in order to keep the API consistent.

The author of that RFC would have been thankful, if he had been put on 
Cc: ;) But anyway, yes, consistency is good, but is my understanding 
correct, that functionally these two extensions - multi-size and 
buffer-forwarding/reuse are independent? We have to think about making the 
APIs consistent, e.g., by reusing data structures. But it's also good to 
make incremental smaller changes where possible, isn't it? So, yes, we 
should think about consistency, but develop and apply those two extensions 
separately?

Thanks
Guennadi

> On my understanding, the SoC people that are driving those changes will
> be working on providing the API proposals for it. They should also be
> providing the needed patches, open source drivers and userspace 
> application(s) 
> that allows testing and validating the GPU <==> V4L transfers using the newly 
> API.
> 
> Thanks,
> Mauro
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[Bug 36745] wine 1.3.19 and 3Dmark2001SE Dragothic demo upset kernel 2.6.38.4

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

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

--- Comment #17 from Andrew Randrianasulu  2011-05-16 
20:23:42 PDT ---
(In reply to comment #16)
> (In reply to comment #15)
> > Andrew,
> > 
> > could you please make an OpenGL trace file using apitrace?
> > 
> > Get it here:
> > https://github.com/apitrace/apitrace
> > 
> > Compile it using cmake, then run something like:
> > 
> > TRACE_FILE=/home/..user../3dmark.trace 
> > LD_PRELOAD=/path-to-apitrace/glxtrace.so
> > ./executable
> > 
> > where executable is 3Dmark2001SE. Then send the 3dmark.trace file to me.
> > 
> > That will capture all the 3D commands and I can replay it here.
> 
> file is 37M big (bz2 compressed)

https://rapidshare.com/files/1581552170/3dmark.trace.gz

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

[Bug 36745] wine 1.3.19 and 3Dmark2001SE Dragothic demo upset kernel 2.6.38.4

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

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

--- Comment #16 from Andrew Randrianasulu  2011-05-16 
19:28:03 PDT ---
(In reply to comment #15)
> Andrew,
> 
> could you please make an OpenGL trace file using apitrace?
> 
> Get it here:
> https://github.com/apitrace/apitrace
> 
> Compile it using cmake, then run something like:
> 
> TRACE_FILE=/home/..user../3dmark.trace 
> LD_PRELOAD=/path-to-apitrace/glxtrace.so
> ./executable
> 
> where executable is 3Dmark2001SE. Then send the 3dmark.trace file to me.
> 
> That will capture all the 3D commands and I can replay it here.

file is 37M big (bz2 compressed)

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

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

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

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

--- Comment #16 from Marek Ol??k  2011-05-16 17:19:46 PDT 
---
It's possible the bisection went wrong and the upload buffer size has nothing
to do with this issue.

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

[Bug 36753] Some textures now rendered as completely black after register allocator rewrite.

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

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

--- Comment #6 from Chris Rankin  2011-05-16 
16:33:46 PDT ---
Created an attachment (id=46786)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46786)
Output of RADEON_DEBUG=nohiz,fp

(In reply to comment #5)
> The patch will give me some extra debug info.  Can you apply it and post the
> output of RADEON_DEBUG=fp.

As requested.

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

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

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

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

--- Comment #16 from Marek Ol??k  2011-05-16 16:23:27 PDT 
---
Nope, I've run out of ideas and I don't have the GPU.

(Milan, are you near Brno by any chance?)

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

[Bug 34313] RV770 lock-up with OpenGL

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

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

--- Comment #18 from Bob Ham  2011-05-16 15:36:12 PDT ---
Neither reducing the VRAM size to 32MB or increasing the GART size to 1GB makes
a difference.

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

nouveau: vm flush timeout: 0x00000022

[Eric Paris]

I've got a box which I recently updated to F15.  Everything about it
seemed rock solid perfect back on RHEL4, RHEL5, and RHEL6.  This is a
pre-release OEM box which I can't update BIOS because they dropped
support for the motherboard so if you want a way out, blame BIOS.

After I installed F15 with gnome-shell it's the first time this box has
ever done anything even slightly graphics related.  On the latest distro
kernels: 2.6.39-0.rc7.git6.1.fc16.x86_64 it doesn't seem to be
completely crashing like my -38 based kernels, but it doesn't work
smoothly.  I get pauses sometimes when the box does some sort of
graphicsy/3Dy operation.  The pause on the screen (mouse still works
just fine) lasts anywhere from 1-15 seconds.  The pause always seems to
be accompanied with one or more (usually more) message like:

[drm] nouveau :60:00.0: vm flush timeout: 0x0022

At this point at least the .39 kernel doesn't seem to be completely
killing it, but it's hardly useable...

With a .38 kernel (kernel-2.6.38.6-26.rc1.fc15.x86_64) I originally had
different problems with 2 different (both nvidia cards) talking about
DMAR problem (In every case the visible result was that the screen just
hung indefinitely when doing some spiffy animation).  I tried
intel_iommu={on,off} and eventually disabled VT-d in BIOS.  That seems
to have shut up the dmar messages and gave me new interesting message
when the graphics hung like so:

[random snippet]
[drm] nouveau :60:00.0: PGRAPH - ERROR nsource: DMA_VTX_PROTECTION nstatus: 
PROTECTION_FAULT
[drm] nouveau :60:00.0: PGRAPH - ch 7 (0x001e7010) subc 7 class 0x4097 mthd 
0x1dac data 0x
[drm] nouveau :60:00.0: PGRAPH - ERROR nsource: DMA_VTX_PROTECTION nstatus: 
PROTECTION_FAULT
[drm] nouveau :60:00.0: PGRAPH - ch 7 (0x001e7010) subc 7 class 0x4097 mthd 
0x1fd8 data 0x0001
[drm] nouveau :60:00.0: PGRAPH - ERROR nsource: DMA_VTX_PROTECTION nstatus: 
PROTECTION_FAULT
[drm] nouveau :60:00.0: PGRAPH - ch 7 (0x001e7010) subc 7 class 0x4097 mthd 
0x1fd8 data 0x0001
[drm] nouveau :60:00.0: PGRAPH - ERROR nsource: DMA_VTX_PROTECTION nstatus: 
PROTECTION_FAULT
[drm] nouveau :60:00.0: PGRAPH - ch 7 (0x001e7010) subc 7 class 0x4097 mthd 
0x0a2c data 0x
[drm] nouveau :60:00.0: PGRAPH - ERROR nsource: DMA_VTX_PROTECTION nstatus: 
PROTECTION_FAULT
[drm] nouveau :60:00.0: PGRAPH - ch 7 (0x001e7010) subc 7 class 0x4097 mthd 
0x1fd8 data 0x0002
[...]
[drm] nouveau :60:00.0: fail pre-validate sync
[drm] nouveau :60:00.0: validate vram_list
[drm] nouveau :60:00.0: validate: -16

Is there something I can collect, do try, supply or generally be helpful
to figure out why I can't seem to get reasonable video here?  I think I
have 3 nvidia cards here (probably all about the same age, but I haven't
the foggiest really) I can get error messages from, I'll try any kernel
or any suggestion people have

thanks.

-Eric

-Eric
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.39-0.rc7.git6.1.fc16.x86_64 (mockbuild at 
x86-13.phx2.fedoraproject.org) (gcc version 4.6.0 20110428 (Red Hat 4.6.0-6) 
(GCC) ) #1 SMP Sat May 14 16:32:45 UTC 2011
[0.00] Command line: ro root=/dev/mapper/VolGroup-lv_root 
rd_LVM_LV=VolGroup/lv_root rd_LVM_LV=VolGroup/lv_swap rd_NO_LUKS rd_NO_MD 
rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 00095400 (usable)
[0.00]  BIOS-e820: 00095400 - 000a (reserved)
[0.00]  BIOS-e820: 000e8000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - cffc2840 (usable)
[0.00]  BIOS-e820: cffc2840 - d000 (reserved)
[0.00]  BIOS-e820: e000 - f000 (reserved)
[0.00]  BIOS-e820: fec0 - 0001 (reserved)
[0.00]  BIOS-e820: 0001 - 00023000 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.5 present.
[0.00] DMI: Hewlett-Packard HP xw8600 Workstation/0A98h, BIOS 786F5 
v01.20 05/21/2008
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x23 max_arch_pfn = 0x4
[0.00] MTRR default type: write-back
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-E7FFF write-protect
[0.00]   E8000-E write-back
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 23000 mask FF000 uncachable
[

i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Takashi Iwai -- Sunday 15 May 2011:
> IIRC, you reported that the backlight gets normal when you revert my
> commit in 2.6.38.x.  So, this was regarded as a regression at first.

Yes. And it *is* a regression, which is the whole point of my
initial complaint, as reported by Maciej in 
https://bugzilla.kernel.org/show_bug.cgi?id=31522



> But, one question remains: whether the backlight level control worked
> with the reverted kernel?

Good point. Turns out it didn't work with 2.6.38-rc8 either. But it
did work at some time before. (I use this notebook mainly as a
terminal ATM, so I didn't care much for backlight level. This came
up later during investigation.)

So the only thing that 2.6.38 broke was that the backlight
was initially off. Adjustment had already been broken before
(and works now again; sigh ... confused? I am! :-).



> If you can still change the level without
> LBPC, the former analysis was incorrect.

I don't even know what an LBPC is, other than a variable named like that.
So I'd need a hint for how to test that.



> Also, with the latest 2.6.38.x, you found that the backlight gets back
> when you adjust the level down.

When I reported this, it was about 2.6.39-* and HEAD, not stable
versions. But I tried now, and openSuSE's 2.6.38.6 behaves the same.



> Another question now is what happens if you again turn it up to the
> max level.  Is the backlight still on?

Yes. If the backlight was on at one point, then increasing the level
to maximum never turned if off.



> If the backlight is kept on even with the max level, it implies that
> the problem is only the initial value; once when set correctly, it'll
> work fine after that.

Yes, that's the case. (Except that after closing the lid it's off again.)

m.

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)

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

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

--- Comment #43 from J?r?my Lal  2011-05-16 13:47:02 PDT 
---
It seems the bios that's found when booting in UEFI mode is wrong.
Following that patch and procedure :
https://bugs.freedesktop.org/show_bug.cgi?id=26891
solves the issue.
When the mode is set, the screen displays weird stuff for a moment.
I'll investigate drm messages to see what happens.

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

[Bug 26891] Radeon KMS on Macs with EFI boot

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

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

--- Comment #3 from J?r?my Lal  2011-05-16 13:27:40 PDT 
---
I'm booting an imac12,2 in UEFI mode (need a "Run EFI in physical mode" patch
before doing so),
here's how :
1) boot from latest ubuntu live CD (hold alt, or c, at boot)
2) dump the bios
   dd if=/dev/mem of=vbios.bin bs=65536 skip=12 count=1
3) move it to your partition's /lib/firmware/radeon/vbios.bin
4) use your patch, but move the radeon_read_bios_from_firmware
   call before all other calls to get the bios (force using vbios.bin)

That's it and thank you :)

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

[Bug 35998] RS600: Texture alignment issues under Gnome Shell

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

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

--- Comment #15 from Milan Plzik  2011-05-16 13:04:44 PDT 
---
(In reply to comment #14)
> Created an attachment (id=46752)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46752
 Review: https://bugs.freedesktop.org/review?bug=35998=46752

> little experiment
> 
> (In reply to comment #13)
> > After more thorough testing, it seems that r300 driver is not able to 
> > correctly
> > create surfaces of certain dimensions; random vram content is shown instead.
> 
> Not true. The r300 driver gets it right for all the other GPUs, it's just 
> rs6xx
> that is broken.

  Sorry, I was generalizing too much; for me it's always in rs600 context.

> 
> Please try the attached patch.

I tried this patch; unfortunately it just reverted the old behavior -- problem
with certain surface sizes was gone, but problem with texture alignment
returned for both 8bpp and 32bpp textures. I did not notice any other
differences.

  If you will have any other ideas/patches, I'll gladly test them; but I can't
do much here by myself.

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

[Bug 36523] water reflections misrendered in sauerbraten with "shaders=high" setting

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

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

Sven Arvidsson  changed:

   What|Removed |Added

 CC||sa at whiz.se

--- Comment #3 from Sven Arvidsson  2011-05-16 12:57:55 PDT ---
The map "river_c" seems to be a good testcase for this. 

Water is rendering correctly with shaders on "high quality" with llvmpipe.

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

[Bug 36421] RV710: GPU lockup running portal2 in wine.

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

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

Sven Arvidsson  changed:

   What|Removed |Added

 CC||sa at whiz.se

--- Comment #5 from Sven Arvidsson  2011-05-16 12:50:53 PDT ---
This might be the same as bug 36812. Can you try reverting the commit mentioned
there and see if it still hangs?

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

[Bug 36812] GPU lockup in Team Fortress 2

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

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

--- Comment #3 from Sven Arvidsson  2011-05-16 12:47:38 PDT ---
I'm having the same problem with Left 4 Dead on:

System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.1
-- xserver: 1.10.1
-- mesa: git-51095f7
-- drm: 2.4.25
-- kernel: 2.6.39-rc7

Reverting the commit mentioned above works.

The apitrace uploaded here might be useful to reproduce the hang:
http://dl.dropbox.com/u/28577999/l4d.trace.7z

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

[Bug 36812] GPU lockup in Team Fortress 2

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

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

Sven Arvidsson  changed:

   What|Removed |Added

 CC||sa at whiz.se

--- Comment #2 from Sven Arvidsson  2011-05-16 12:45:11 PDT ---
*** Bug 37263 has been marked as a duplicate of this bug. ***

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

[Bug 37263] [wine] GPU hang in Left 4 Dead

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

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

Sven Arvidsson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Sven Arvidsson  2011-05-16 12:45:11 PDT ---


*** This bug has been marked as a duplicate of bug 36812 ***

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

[PATCH] drivers/gpu/drm/i915/i915_gem.c: Add missing error handling code

[Julia Lawall]

From: Julia Lawall 

The cleanup code at the end of the function should also be carried out when
the function only partly completes its work.

A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)

// 
@r exists@
local idexpression struct page ** x;
expression ra,rr;
position p1,p2;
@@

x = drm_malloc_ab at p1(...)
...  when != x = rr
 when != drm_free_large(x,...)
 when != if (...) { ... drm_free_large(x,...) ...}
if(...) { ... when != x = ra
 when forall
 when != drm_free_large(x,...)
 \(return <+...x...+>; \| return at p2...; \) }

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

cocci.print_main("drm_malloc_ab",p1)
cocci.print_secs("return",p2)

// 

Signed-off-by: Julia Lawall 

---
This is only compile-tested.  It may be that processing all of the pages is
not correct when they have been partially treated.

 drivers/gpu/drm/i915/i915_gem.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7ce3f35..ef000e6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -467,8 +467,10 @@ i915_gem_shmem_pread_slow(struct drm_device *dev,

page = read_cache_page_gfp(mapping, offset >> PAGE_SHIFT,
   GFP_HIGHUSER | __GFP_RECLAIMABLE);
-   if (IS_ERR(page))
-   return PTR_ERR(page);
+   if (IS_ERR(page)) {
+   ret = PTR_ERR(page);
+   goto out;
+   }

if (do_bit17_swizzling) {
slow_shmem_bit17_copy(page,

[Bug 34097] Screen clearing issues in Minecraft and Blender

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

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

--- Comment #5 from Sven Arvidsson  2011-05-16 09:19:27 PDT ---
I'm having exactly the same problem on r600g, so maybe this bug belongs to
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 37263] New: [wine] GPU hang in Left 4 Dead

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

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

   Summary: [wine] GPU hang in Left 4 Dead
   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: sa at whiz.se


Created an attachment (id=46776)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=46776)
dmesg output

The game Left 4 Dead (running in Wine) is causing a GPU hang every time I try
to start a new game. This is probably related to bug 35051 and bug 36421 but
I'm filing it just to be sure.

dmesg output including the kernel call trace is attached.

I also used apitrace, the resulting trace seems to randomly either recreate the
hang or segfaulting so I'm not sure how useful it is:
http://dl.dropbox.com/u/28577999/l4d.trace.7z

System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.1
-- xserver: 1.10.1
-- mesa: git-51095f7
-- drm: 2.4.25
-- kernel: 2.6.39-rc7

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

[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup

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

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

--- Comment #11 from Brian Paterni  2011-05-16 09:15:04 
PDT ---
Thanks for the confirmation there.

I did end up running Steam/CS: Source through zach rusin's apitrace tool,
getting the following trace:

http://uploading.com/files/1213aed2/css.glapi.trace/

the erroneous call seems to be

235567 glDrawBuffer(mode = GL_BACK)
235567: warning: glGetError(glDrawBuffer) = GL_INVALID_OPERATION
Mesa: User error: GL_INVALID_OPERATION in glDrawBuffer(buffer=0x405)

Hopefully this helps greatly in the debugging process. :)

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

[Bug 37262] New: Extreme IO using libre/openoffice

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

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

   Summary: Extreme IO using libre/openoffice
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/DRI/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: de.techno at gmail.com


Since the last few days and in many places, I've been wandering around posting
this - 

"I've been using KDE (QT) build of Openoffice on Gentoo and suddenly came
across
this strange problem which also persist with GTK openoffice and even
Libreoffice.

It appears Openoffice takes too much disk I/O when drawing toolbars, it takes 2
minutes to cold start OOo, and in the mean time the whole system is unusable (I
can hardly move the mouse) + the kernel hangs when I doing some other I/O
intensive tasks while OOo is loading, and sometimes it hangs even if I'm
nothing doing anything.

Since Base doesn't have many toolbars by default, it opens OK, but other things
are just horrible. 

Most important fact is that all this happens when composting is enabled with
Kwin.

Also I've seen, this problem persists only if Kwin render method is OpenGL, if
it's XRender, the problem's solved."

As bug reports or in forms.

The problem appears to come from the latest mesa (May 16th 2011), downgrading
to 7.10.2 solves the problem.

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

[Bug 37261] New: Norsetto shadow mapping doesn't render correctly

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

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

   Summary: Norsetto shadow mapping doesn't render correctly
   Product: Mesa
   Version: git
  Platform: Other
   URL: http://norsetto.site11.com/?db_select=shadow_id=9
7
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: sa at whiz.se


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

The shadow mapping demo from norsetto doesn't render correctly with r600g, none
of the objects are textured and the shadows are missing. Rendering on llvmpipe
seems to be correct.

The demo requires a simple change for the shaders to compile:

--- data/shaders/bumpTBN_SH_FP.glsl.orig2011-05-16 17:41:49.098224141 +0200
+++ data/shaders/bumpTBN_SH_FP.glsl2011-05-16 17:41:57.978477020 +0200
@@ -46,7 +46,7 @@ void main()

 offset.y += offset.x;
 if ( offset.y > 1.1)
-offset.y = 0;
+offset.y = 0.0;

 vec4 shadow = (offset_lookup( shadowMap, gl_TexCoord[1],
offset+vec2(-1.5,  0.5) ) +
 offset_lookup( shadowMap, gl_TexCoord[1], offset+vec2( 0.5,  0.5)
) +


System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.1
-- xserver: 1.10.1
-- mesa: git-c9aa3bb
-- drm: 2.4.25
-- kernel: 2.6.39-rc7

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

[Bug 34313] RV770 lock-up with OpenGL

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

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

--- Comment #17 from Bob Ham  2011-05-16 08:18:28 PDT ---
The previous comment is while using the latest drm-fixes kernel tree and latest
git for X, ddx, mesa (r600g), etc.

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

[Bug 34313] RV770 lock-up with OpenGL

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

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

--- Comment #16 from Bob Ham  2011-05-16 08:07:58 PDT ---
After testing I've discovered that there is no obvious culprit.  Reducing the
number of GL features (texture compression, VBOs, GLSL, etc) used by nexuiz
simply extends the amount of time it takes for the GPU to lock up.  A lockup
will occur even with all optional GL features turned off, it just takes a long
time.  Increasing the number of GL features in use just reduces the time it
takes for the GPU to lock up.

Repeatedly running the simple mesa demos in a cycle will eventually cause the
GPU to lock up.  Unfortunately, not always at the same point.

Disabling writeback using 'radeon.no_wb=1' on the kernel command line does not
stop GPU lockups.  Temperature is not a factor; the GPU has locked up at 48
degrees while at other times running fine at over 58 degrees for long periods. 
There are no such problems while using the proprietary fglrx driver.

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

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

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

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

--- Comment #15 from dri tester  2011-05-16 
06:56:39 PDT ---
(In reply to comment #14)
> Created an attachment (id=46763)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46763
 Review: https://bugs.freedesktop.org/review?bug=36952=46763

> fix for crackberg performance and segfaulting on rs482

H, the lateset patch with a value of 32 * 1024 fixes crackberg but now
antmaze gives me:
radeon: The kernel rejected CS, see dmesg for more information.

and dmesg says:
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
antmaze[13259]: segfault at 4 ip b5b57000 sp bfd14fcc error 6

I will play with the values some more.

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

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

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

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

dri tester  changed:

   What|Removed |Added

  Attachment #46696|0   |1
is obsolete||

--- Comment #14 from dri tester  2011-05-16 
06:52:09 PDT ---
Created an attachment (id=46763)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46763
 Review: https://bugs.freedesktop.org/review?bug=36952=46763

fix for crackberg performance and segfaulting on rs482

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

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

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

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

--- Comment #13 from dri tester  2011-05-16 
06:49:15 PDT ---
(In reply to comment #12)
> (In reply to comment #11)
> > It would be better to experiment with the patch and try smaller buffer 
> > sizes.
> > Please let me know when you find a size which works.
> 
> The current mesa-git value for the R300_MAX_DRAW_VBO_SIZE is 1024 * 1024 and
> your patch dropped it down to 512 * 1024.  I tried with 64 * 1024 (which is 
> the
> value that worked before the commit that I bisected above) and crackberg 
> works,
> the animation is smooth and the cpu usage is 50% on one cpu, but it segfaults
> after 13-18 seconds.  I really think there is another bug being uncovered 
> here.
>  I do not know which buffer size to recommend for R300_MAX_DRAW_VBO_SIZE, 512 
> *
> 1024 as per your attached patch worked as well as 64 * 1024.  I assume that 
> the
> value must be a power of 2, or are there some other values to test?  Should I
> test the values between 64 and 512 for completeness?

Disregard my last comment above, I was totally incorrect.  A value for
R300_MAX_DRAW_VBO_SIZE of 32 * 1024 fixed crackberg completely for me.  I will
attach the working patch as 0003-r300g-allocate-smaller-upload-buffers.patch. 
Thanks Marek.

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

[Bug 37253] New: SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent

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

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

   Summary: SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
   Product: Mesa
   Version: unspecified
  Platform: Other
   URL: https://bugzilla.mozilla.org/show_bug.cgi?id=624935
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: bjacob at mozilla.com


This is the bug forcing us to blacklist Gallium in Firefox 6+.

Steps to reproduce:

0. This has been confirmed with Mesa 7.10.2, Gallium 0.4, and both R300 and
R600 but seems device-independent. I didn't find the proper category for
general Gallium bugs.
1. Grab a Nightly of Firefox:
   http://nightly.mozilla.org/
2. Run it; If you're already using Firefox, you may want to do:
   ./path/to/firefox -no-remote -P
3. Make sure that WebGL is enabled (a bug in parsing version strings makes it
unintentionally blacklist some systems). Go to about:config, set
webgl.force-enabled=true if needed. You can go to about:support to check WebGL
status.
4. Go to http://people.mozilla.com/~sicking/webgl/ray.html

Actual results: segfault

A stack trace is given there:
  https://bugzilla.mozilla.org/show_bug.cgi?id=624935#c0

I discussed this with Corbin Simpson
(https://bugzilla.mozilla.org/show_bug.cgi?id=624935#c6) who told me it was a
known Gallium bug, been discussed on the mailing list already:
http://marc.info/?l=mesa3d-dev=126525088903956=2
http://marc.info/?l=mesa3d-dev=127680073328903=2

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

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

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

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

--- Comment #12 from dri tester  2011-05-16 
06:14:40 PDT ---
(In reply to comment #11)
> It would be better to experiment with the patch and try smaller buffer sizes.
> Please let me know when you find a size which works.

The current mesa-git value for the R300_MAX_DRAW_VBO_SIZE is 1024 * 1024 and
your patch dropped it down to 512 * 1024.  I tried with 64 * 1024 (which is the
value that worked before the commit that I bisected above) and crackberg works,
the animation is smooth and the cpu usage is 50% on one cpu, but it segfaults
after 13-18 seconds.  I really think there is another bug being uncovered here.
 I do not know which buffer size to recommend for R300_MAX_DRAW_VBO_SIZE, 512 *
1024 as per your attached patch worked as well as 64 * 1024.  I assume that the
value must be a power of 2, or are there some other values to test?  Should I
test the values between 64 and 512 for completeness?

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

[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup

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

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

--- Comment #10 from Tobias Jakobi  2011-05-16 05:54:40 
PDT ---
I'm pretty sure you're seeing the common GPU reset problems when using the HL2
engine DX9 renderpath. So yes, that's the bug #36421 you already mentioned.

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

[git pull] final drm fixes

[Dave Airlie]

Hi Linus,

two regression fixes, one on Intel Q67 with semaphores, and one in the 
switcheroo code. One black screen on radeon problem, oops on undock fix,
and a couple of minor updates to some changed regs on newer radeon hw.

Dave.

The following changes since commit ca1376d10810bc2c20c8d0821a9ee04ca2507c01:

  Merge branch 'fix/asoc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 (2011-05-12 
12:41:30 -0700)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes

Alex Deucher (3):
  drm/radeon/kms: fix tiling reg on fusion
  drm/radeon/kms: fix extended lvds info parsing
  drm/radeon/kms: add some evergreen/ni safe regs

Andy Lutomirski (1):
  drm/i915: Revert i915.semaphore=1 default from 47ae63e0

Chris Wilson (1):
  drm: Take lock around probes for drm_fb_helper_hotplug_event

Florian Mickler (1):
  vga_switcheroo: don't toggle-switch devices

 drivers/gpu/drm/drm_fb_helper.c   |   26 ++
 drivers/gpu/drm/i915/i915_drv.c   |2 +-
 drivers/gpu/drm/radeon/evergreen.c|5 -
 drivers/gpu/drm/radeon/evergreend.h   |1 +
 drivers/gpu/drm/radeon/radeon_atombios.c  |   14 +++---
 drivers/gpu/drm/radeon/reg_srcs/cayman|1 +
 drivers/gpu/drm/radeon/reg_srcs/evergreen |1 +
 drivers/gpu/vga/vga_switcheroo.c  |6 +++---
 include/drm/drm_fb_helper.h   |2 +-
 9 files changed, 45 insertions(+), 13 deletions(-)

[Bug 35192] New: BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]

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

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

   URL: http://bugs.gentoo.org/show_bug.cgi?id=359281
   Summary: BUG() in radeon driver with ATI Technologies Inc RV515
[Radeon X1300]
   Product: Drivers
   Version: 2.5
Kernel Version: 2.6.37 and 2.6.38
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: blueness at gentoo.org
Regression: Yes


A regression in kernels 2.6.37 up to 2.6.38.6 hits a BUG() in the radeon driver
with the following hardware (as reported by lspci -kv)

02:00.0 VGA compatible controller: ATI Technologies Inc RV515 [Radeon X1300]
(prog-if 00 [VGA controller])
Subsystem: ATI Technologies Inc All-in-Wonder 2006 PCI-E Edition
Flags: bus master, fast devsel, latency 0, IRQ 40
Memory at e000 (64-bit, prefetchable) [size=256M]
Memory at fd9f (64-bit, non-prefetchable) [size=64K]
I/O ports at ce00 [size=256]
Expansion ROM at fd9c [disabled] [size=128K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Express Endpoint, MSI 00
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: radeon


The BUG() is

kernel tried to execute NX-protected page - exploit attempt? (uid: 0)
BUG: unable to handle kernel paging request at 81c0e711
IP: [] platform_device_register_resndata+0x0/0x8c
PGD 1ae5067 PUD 1ae9063 PMD 3c473063 PTE 81c0e163
Oops: 0011 [#1] SMP 
last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
CPU 0 
Pid: 1627, comm: X Tainted: GW   2.6.38.6 #1 HP Pavilion 061
ER900AA-ABA a1430n/NAGAMI
RIP: 0010:[]  []
platform_device_register_resndata+0x0/0x8c
RSP: 0018:88003a2b3d30  EFLAGS: 00010246
RAX:  RBX: 88003cb81000 RCX: 
RDX:  RSI: 81a41cbb RDI: 
RBP: 88003a2b3d88 R08:  R09: 
R10: 88003a34 R11: e000 R12: 
R13: 88003cb80800 R14: 88003abeaa80 R15: 0001
FS:  7f40b4c72880() GS:88003fc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 81c0e711 CR3: 3a2a8000 CR4: 06f0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process X (pid: 1627, threadinfo 88003a2b2000, task 88003d3ef1a0)
Stack:
 8133aa29  0001 88003a2b3de8
 811681fc 88003a2b3df8 88003abeaa80 88003cb80800
 0040 40786440 0078 88003a2b3ea8
Call Trace:
 [] ? radeon_cp_init+0xd79/0x1180
 [] ? ext4_file_write+0x6c/0x2a0
 [] drm_ioctl+0x389/0x4d0
 [] ? radeon_cp_init+0x0/0x1180
 [] do_vfs_ioctl+0x9b/0x510
 [] sys_ioctl+0x4f/0x80
 [] system_call_fastpath+0x16/0x1b
Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 
RIP  [] platform_device_register_resndata+0x0/0x8c
 RSP 
CR2: 81c0e711
---[ end trace f569524e57c84b79 ]---


More detail is avaiable in the following gentoo bug:

   http://bugs.gentoo.org/show_bug.cgi?id=359281


We're looking into doing the git-bisect now.

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

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list

[Hans Verkuil]

On Saturday, May 14, 2011 13:46:03 Mauro Carvalho Chehab wrote:
> Em 14-05-2011 13:02, Hans Verkuil escreveu:
> > On Saturday, May 14, 2011 12:19:18 Mauro Carvalho Chehab wrote:
> 
> >> So, based at all I've seen, I'm pretty much convinced that the normal MMAP
> >> way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
> >> are not the best way to share data with framebuffers.
> > 
> > I agree with that, but it is a different story between two V4L2 devices. 
> > There
> > you obviously want to use the streaming ioctls and still share buffers.
> 
> I don't think so. the requirement for syncing the framebuffer between the two
> V4L2 devices is pretty much the same as we have with one V4L2 device and one 
> GPU.
> 
> On both cases, the requirement is to pass a framebuffer between two entities, 
> and not a video stream.
> 
> For example, imagine something like:
> 
>   V4L2 camera => V4L2 encoder t MPEG2
>||
>LL==> GPU
> 
> Both GPU and the V4L2 encoder should use the same logic to be sure that they 
> will
> use a buffer that were filled already by the camera. Also, the V4L2 camera
> driver can't re-use such framebuffer before being sure that both consumers 
> has already stopped using it.

No. A camera whose output is sent to a resizer and then to a SW/FW/HW encoder
is a typical example where you want to queue/dequeue buffers. Especially since
the various parts of the pipeline may stall for a bit so you don't want to lose
frames. That's not what the overlay API is for, that's what our streaming API
gives us.

The use case above isn't even possible without copying. At least, I don't see a
way, unless the GPU buffer is non-destructive. In that case you can give the
frame to the GPU, and when the GPU is finished you can give it to the encoder.
I suspect that might become quite complex though.

Note that many video receivers cannot stall. You can't tell them to wait until
the last buffer finished processing. This is different from some/most? sensors.

So if you try to send the input of a video receiver to some device that requires
syncing which can cause stalls, then that will not work without losing frames.
Which especially for video encoding is not desirable.

Of course, it might be that we mean the same, but just use different words :-(

Regards,

Hans

> 
> So, it is the same requirement as having four displays receiving such 
> framebuffer.
> 
> Of course, a GPU endpoint may require some extra information for the blending,
> but also a V4L node may require some other type of extra information.
> 
> >> We probably need
> >> something that it will be an enhanced version of the 
> >> VIDIOC_FBUF/VIDIOC_OVERLAY
> >> ioctls. Unfortunately, we can't just add more stuff there, as there's no
> >> reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's.
> > 
> > That will be useful as well to add better support for blending and 
> > Z-ordering
> > between overlays. The old API for that is very limited in that respect.
> 
> Agreed.
> 
> Mauro.
> 

[PATCH] drivers/gpu/drm/i915/i915_gem.c: Add missing error handling code

[Julia Lawall]

From: Julia Lawall ju...@diku.dk

The cleanup code at the end of the function should also be carried out when
the function only partly completes its work.

A simplified version of the semantic match that finds this problem is:
(http://coccinelle.lip6.fr/)

// smpl
@r exists@
local idexpression struct page ** x;
expression ra,rr;
position p1,p2;
@@

x = drm_malloc_ab@p1(...)
...  when != x = rr
 when != drm_free_large(x,...)
 when != if (...) { ... drm_free_large(x,...) ...}
if(...) { ... when != x = ra
 when forall
 when != drm_free_large(x,...)
 \(return +...x...+; \| return@p2...; \) }

@script:python@
p1  r.p1;
p2  r.p2;
@@

cocci.print_main(drm_malloc_ab,p1)
cocci.print_secs(return,p2)

// /smpl

Signed-off-by: Julia Lawall ju...@diku.dk

---
This is only compile-tested.  It may be that processing all of the pages is
not correct when they have been partially treated.

 drivers/gpu/drm/i915/i915_gem.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 7ce3f35..ef000e6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -467,8 +467,10 @@ i915_gem_shmem_pread_slow(struct drm_device *dev,
 
page = read_cache_page_gfp(mapping, offset  PAGE_SHIFT,
   GFP_HIGHUSER | __GFP_RECLAIMABLE);
-   if (IS_ERR(page))
-   return PTR_ERR(page);
+   if (IS_ERR(page)) {
+   ret = PTR_ERR(page);
+   goto out;
+   }
 
if (do_bit17_swizzling) {
slow_shmem_bit17_copy(page,

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

Re: i915/kms/backlight-combo mode problem

[Melchior FRANZ]

* Takashi Iwai -- Sunday 15 May 2011:
 IIRC, you reported that the backlight gets normal when you revert my
 commit in 2.6.38.x.  So, this was regarded as a regression at first.

Yes. And it *is* a regression, which is the whole point of my
initial complaint, as reported by Maciej in 
https://bugzilla.kernel.org/show_bug.cgi?id=31522



 But, one question remains: whether the backlight level control worked
 with the reverted kernel?

Good point. Turns out it didn't work with 2.6.38-rc8 either. But it
did work at some time before. (I use this notebook mainly as a
terminal ATM, so I didn't care much for backlight level. This came
up later during investigation.)

So the only thing that 2.6.38 broke was that the backlight
was initially off. Adjustment had already been broken before
(and works now again; sigh ... confused? I am! :-).



 If you can still change the level without
 LBPC, the former analysis was incorrect.

I don't even know what an LBPC is, other than a variable named like that.
So I'd need a hint for how to test that.



 Also, with the latest 2.6.38.x, you found that the backlight gets back
 when you adjust the level down.

When I reported this, it was about 2.6.39-* and HEAD, not stable
versions. But I tried now, and openSuSE's 2.6.38.6 behaves the same.



 Another question now is what happens if you again turn it up to the
 max level.  Is the backlight still on?

Yes. If the backlight was on at one point, then increasing the level
to maximum never turned if off.



 If the backlight is kept on even with the max level, it implies that
 the problem is only the initial value; once when set correctly, it'll
 work fine after that.

Yes, that's the case. (Except that after closing the lid it's off again.)

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

[Bug 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup

[bugzilla-daemon]

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

--- Comment #10 from Tobias Jakobi liquid.a...@gmx.net 2011-05-16 05:54:40 
PDT ---
I'm pretty sure you're seeing the common GPU reset problems when using the HL2
engine DX9 renderpath. So yes, that's the bug #36421 you already mentioned.

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

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

[bugzilla-daemon]

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

--- Comment #12 from dri tester writemeand...@hotmail.com 2011-05-16 06:14:40 
PDT ---
(In reply to comment #11)
 It would be better to experiment with the patch and try smaller buffer sizes.
 Please let me know when you find a size which works.

The current mesa-git value for the R300_MAX_DRAW_VBO_SIZE is 1024 * 1024 and
your patch dropped it down to 512 * 1024.  I tried with 64 * 1024 (which is the
value that worked before the commit that I bisected above) and crackberg works,
the animation is smooth and the cpu usage is 50% on one cpu, but it segfaults
after 13-18 seconds.  I really think there is another bug being uncovered here.
 I do not know which buffer size to recommend for R300_MAX_DRAW_VBO_SIZE, 512 *
1024 as per your attached patch worked as well as 64 * 1024.  I assume that the
value must be a power of 2, or are there some other values to test?  Should I
test the values between 64 and 512 for completeness?

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

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

[bugzilla-daemon]

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

--- Comment #13 from dri tester writemeand...@hotmail.com 2011-05-16 06:49:15 
PDT ---
(In reply to comment #12)
 (In reply to comment #11)
  It would be better to experiment with the patch and try smaller buffer 
  sizes.
  Please let me know when you find a size which works.
 
 The current mesa-git value for the R300_MAX_DRAW_VBO_SIZE is 1024 * 1024 and
 your patch dropped it down to 512 * 1024.  I tried with 64 * 1024 (which is 
 the
 value that worked before the commit that I bisected above) and crackberg 
 works,
 the animation is smooth and the cpu usage is 50% on one cpu, but it segfaults
 after 13-18 seconds.  I really think there is another bug being uncovered 
 here.
  I do not know which buffer size to recommend for R300_MAX_DRAW_VBO_SIZE, 512 
 *
 1024 as per your attached patch worked as well as 64 * 1024.  I assume that 
 the
 value must be a power of 2, or are there some other values to test?  Should I
 test the values between 64 and 512 for completeness?

Disregard my last comment above, I was totally incorrect.  A value for
R300_MAX_DRAW_VBO_SIZE of 32 * 1024 fixed crackberg completely for me.  I will
attach the working patch as 0003-r300g-allocate-smaller-upload-buffers.patch. 
Thanks Marek.

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

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

[bugzilla-daemon]

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

dri tester writemeand...@hotmail.com changed:

   What|Removed |Added

  Attachment #46696|0   |1
is obsolete||

--- Comment #14 from dri tester writemeand...@hotmail.com 2011-05-16 06:52:09 
PDT ---
Created an attachment (id=46763)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46763
 Review: https://bugs.freedesktop.org/review?bug=36952attachment=46763

fix for crackberg performance and segfaulting on rs482

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

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

[bugzilla-daemon]

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

--- Comment #15 from dri tester writemeand...@hotmail.com 2011-05-16 06:56:39 
PDT ---
(In reply to comment #14)
 Created an attachment (id=46763)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46763
 Review: https://bugs.freedesktop.org/review?bug=36952attachment=46763

 fix for crackberg performance and segfaulting on rs482

H, the lateset patch with a value of 32 * 1024 fixes crackberg but now
antmaze gives me:
radeon: The kernel rejected CS, see dmesg for more information.

and dmesg says:
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
radeon :01:05.0: (PW 2) Vertex array 0 need 8436 dwords have 8192 dwords
[drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
antmaze[13259]: segfault at 4 ip b5b57000 sp bfd14fcc error 6

I will play with the values some more.

-- 
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 34313] RV770 lock-up with OpenGL

[bugzilla-daemon]

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

--- Comment #16 from Bob Ham r...@bash.sh 2011-05-16 08:07:58 PDT ---
After testing I've discovered that there is no obvious culprit.  Reducing the
number of GL features (texture compression, VBOs, GLSL, etc) used by nexuiz
simply extends the amount of time it takes for the GPU to lock up.  A lockup
will occur even with all optional GL features turned off, it just takes a long
time.  Increasing the number of GL features in use just reduces the time it
takes for the GPU to lock up.

Repeatedly running the simple mesa demos in a cycle will eventually cause the
GPU to lock up.  Unfortunately, not always at the same point.

Disabling writeback using 'radeon.no_wb=1' on the kernel command line does not
stop GPU lockups.  Temperature is not a factor; the GPU has locked up at 48
degrees while at other times running fine at over 58 degrees for long periods. 
There are no such problems while using the proprietary fglrx driver.

-- 
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 34313] RV770 lock-up with OpenGL

[bugzilla-daemon]

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

--- Comment #17 from Bob Ham r...@bash.sh 2011-05-16 08:18:28 PDT ---
The previous comment is while using the latest drm-fixes kernel tree and latest
git for X, ddx, mesa (r600g), etc.

-- 
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 37261] New: Norsetto shadow mapping doesn't render correctly

[bugzilla-daemon]

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

   Summary: Norsetto shadow mapping doesn't render correctly
   Product: Mesa
   Version: git
  Platform: Other
   URL: http://norsetto.site11.com/?db_select=shadowpage_id=9
7
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: s...@whiz.se


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

The shadow mapping demo from norsetto doesn't render correctly with r600g, none
of the objects are textured and the shadows are missing. Rendering on llvmpipe
seems to be correct.

The demo requires a simple change for the shaders to compile:

--- data/shaders/bumpTBN_SH_FP.glsl.orig2011-05-16 17:41:49.098224141 +0200
+++ data/shaders/bumpTBN_SH_FP.glsl2011-05-16 17:41:57.978477020 +0200
@@ -46,7 +46,7 @@ void main()

 offset.y += offset.x;
 if ( offset.y  1.1)
-offset.y = 0;
+offset.y = 0.0;

 vec4 shadow = (offset_lookup( shadowMap, gl_TexCoord[1],
offset+vec2(-1.5,  0.5) ) +
 offset_lookup( shadowMap, gl_TexCoord[1], offset+vec2( 0.5,  0.5)
) +


System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.1
-- xserver: 1.10.1
-- mesa: git-c9aa3bb
-- drm: 2.4.25
-- kernel: 2.6.39-rc7

-- 
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 37262] New: Extreme IO using libre/openoffice

[bugzilla-daemon]

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

   Summary: Extreme IO using libre/openoffice
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/DRI/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: de.tec...@gmail.com


Since the last few days and in many places, I've been wandering around posting
this - 

I've been using KDE (QT) build of Openoffice on Gentoo and suddenly came
across
this strange problem which also persist with GTK openoffice and even
Libreoffice.

It appears Openoffice takes too much disk I/O when drawing toolbars, it takes 2
minutes to cold start OOo, and in the mean time the whole system is unusable (I
can hardly move the mouse) + the kernel hangs when I doing some other I/O
intensive tasks while OOo is loading, and sometimes it hangs even if I'm
nothing doing anything.

Since Base doesn't have many toolbars by default, it opens OK, but other things
are just horrible. 

Most important fact is that all this happens when composting is enabled with
Kwin.

Also I've seen, this problem persists only if Kwin render method is OpenGL, if
it's XRender, the problem's solved.

As bug reports or in forms.

The problem appears to come from the latest mesa (May 16th 2011), downgrading
to 7.10.2 solves the problem.

-- 
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 35051] [RADEON:KMS:R600G] wine Counter Strike Source Crashes at Startup

[bugzilla-daemon]

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

--- Comment #11 from Brian Paterni bpate...@gmail.com 2011-05-16 09:15:04 PDT 
---
Thanks for the confirmation there.

I did end up running Steam/CS: Source through zach rusin's apitrace tool,
getting the following trace:

http://uploading.com/files/1213aed2/css.glapi.trace/

the erroneous call seems to be

235567 glDrawBuffer(mode = GL_BACK)
235567: warning: glGetError(glDrawBuffer) = GL_INVALID_OPERATION
Mesa: User error: GL_INVALID_OPERATION in glDrawBuffer(buffer=0x405)

Hopefully this helps greatly in the debugging process. :)

-- 
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 37263] New: [wine] GPU hang in Left 4 Dead

[bugzilla-daemon]

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

   Summary: [wine] GPU hang in Left 4 Dead
   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: s...@whiz.se


Created an attachment (id=46776)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46776)
dmesg output

The game Left 4 Dead (running in Wine) is causing a GPU hang every time I try
to start a new game. This is probably related to bug 35051 and bug 36421 but
I'm filing it just to be sure.

dmesg output including the kernel call trace is attached.

I also used apitrace, the resulting trace seems to randomly either recreate the
hang or segfaulting so I'm not sure how useful it is:
http://dl.dropbox.com/u/28577999/l4d.trace.7z

System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.1
-- xserver: 1.10.1
-- mesa: git-51095f7
-- drm: 2.4.25
-- kernel: 2.6.39-rc7

-- 
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 34097] Screen clearing issues in Minecraft and Blender

[bugzilla-daemon]

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

--- Comment #5 from Sven Arvidsson s...@whiz.se 2011-05-16 09:19:27 PDT ---
I'm having exactly the same problem on r600g, so maybe this bug belongs to
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 37263] [wine] GPU hang in Left 4 Dead

[bugzilla-daemon]

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

Sven Arvidsson s...@whiz.se changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Sven Arvidsson s...@whiz.se 2011-05-16 12:45:11 PDT ---


*** This bug has been marked as a duplicate of bug 36812 ***

-- 
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 36812] GPU lockup in Team Fortress 2

[bugzilla-daemon]

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

Sven Arvidsson s...@whiz.se changed:

   What|Removed |Added

 CC||s...@whiz.se

--- Comment #2 from Sven Arvidsson s...@whiz.se 2011-05-16 12:45:11 PDT ---
*** Bug 37263 has been marked as a duplicate of this bug. ***

-- 
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 36812] GPU lockup in Team Fortress 2

[bugzilla-daemon]

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

--- Comment #3 from Sven Arvidsson s...@whiz.se 2011-05-16 12:47:38 PDT ---
I'm having the same problem with Left 4 Dead on:

System environment:
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- GPU: REDWOOD
-- Model: XFX Radeon HD 5670 1GB
-- Display connector: DVI
-- xf86-video-ati: 6.14.1
-- xserver: 1.10.1
-- mesa: git-51095f7
-- drm: 2.4.25
-- kernel: 2.6.39-rc7

Reverting the commit mentioned above works.

The apitrace uploaded here might be useful to reproduce the hang:
http://dl.dropbox.com/u/28577999/l4d.trace.7z

-- 
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 36421] RV710: GPU lockup running portal2 in wine.

[bugzilla-daemon]

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

Sven Arvidsson s...@whiz.se changed:

   What|Removed |Added

 CC||s...@whiz.se

--- Comment #5 from Sven Arvidsson s...@whiz.se 2011-05-16 12:50:53 PDT ---
This might be the same as bug 36812. Can you try reverting the commit mentioned
there and see if it still hangs?

-- 
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 36523] water reflections misrendered in sauerbraten with shaders=high setting

[bugzilla-daemon]

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

Sven Arvidsson s...@whiz.se changed:

   What|Removed |Added

 CC||s...@whiz.se

--- Comment #3 from Sven Arvidsson s...@whiz.se 2011-05-16 12:57:55 PDT ---
The map river_c seems to be a good testcase for this. 

Water is rendering correctly with shaders on high quality with llvmpipe.

-- 
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 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-daemon]

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

--- Comment #15 from Milan Plzik eme...@gmail.com 2011-05-16 13:04:44 PDT ---
(In reply to comment #14)
 Created an attachment (id=46752)
 View: https://bugs.freedesktop.org/attachment.cgi?id=46752
 Review: https://bugs.freedesktop.org/review?bug=35998attachment=46752

 little experiment
 
 (In reply to comment #13)
  After more thorough testing, it seems that r300 driver is not able to 
  correctly
  create surfaces of certain dimensions; random vram content is shown instead.
 
 Not true. The r300 driver gets it right for all the other GPUs, it's just 
 rs6xx
 that is broken.

  Sorry, I was generalizing too much; for me it's always in rs600 context.

 
 Please try the attached patch.

I tried this patch; unfortunately it just reverted the old behavior -- problem
with certain surface sizes was gone, but problem with texture alignment
returned for both 8bpp and 32bpp textures. I did not notice any other
differences.

  If you will have any other ideas/patches, I'll gladly test them; but I can't
do much here by myself.

-- 
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 26891] Radeon KMS on Macs with EFI boot

[bugzilla-daemon]

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

--- Comment #3 from Jérémy Lal kapo...@melix.org 2011-05-16 13:27:40 PDT ---
I'm booting an imac12,2 in UEFI mode (need a Run EFI in physical mode patch
before doing so),
here's how :
1) boot from latest ubuntu live CD (hold alt, or c, at boot)
2) dump the bios
   dd if=/dev/mem of=vbios.bin bs=65536 skip=12 count=1
3) move it to your partition's /lib/firmware/radeon/vbios.bin
4) use your patch, but move the radeon_read_bios_from_firmware
   call before all other calls to get the bios (force using vbios.bin)

That's it and thank you :)

-- 
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: Summary of the V4L2 discussions during LDS - was: Re: Embedded Linux memory management interest group list

[Guennadi Liakhovetski]

On Sat, 14 May 2011, Mauro Carvalho Chehab wrote:

 Em 18-04-2011 17:15, Jesse Barker escreveu:
  One of the big issues we've been faced with at Linaro is around GPU
  and multimedia device integration, in particular the memory management
  requirements for supporting them on ARM.  This next cycle, we'll be
  focusing on driving consensus around a unified memory management
  solution for embedded systems that support multiple architectures and
  SoCs.  This is listed as part of our working set of requirements for
  the next six-month cycle (in spite of the URL, this is not being
  treated as a graphics-specific topic - we also have participation from
  multimedia and kernel working group folks):
  
https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics
 
 As part of the memory management needs, Linaro organized several discussions
 during Linaro Development Summit (LDS), at Budapest, and invited me and other
 members of the V4L and DRI community to discuss about the requirements.
 I wish to thank Linaro for its initiative.

[snip]

 Btw, the need of managing buffers is currently being covered by the proposal
 for new ioctl()s to support multi-sized video-buffers [1].
 
 [1] http://www.spinics.net/lists/linux-media/msg30869.html
 
 It makes sense to me to discuss such proposal together with the above 
 discussions, 
 in order to keep the API consistent.

The author of that RFC would have been thankful, if he had been put on 
Cc: ;) But anyway, yes, consistency is good, but is my understanding 
correct, that functionally these two extensions - multi-size and 
buffer-forwarding/reuse are independent? We have to think about making the 
APIs consistent, e.g., by reusing data structures. But it's also good to 
make incremental smaller changes where possible, isn't it? So, yes, we 
should think about consistency, but develop and apply those two extensions 
separately?

Thanks
Guennadi

 On my understanding, the SoC people that are driving those changes will
 be working on providing the API proposals for it. They should also be
 providing the needed patches, open source drivers and userspace 
 application(s) 
 that allows testing and validating the GPU == V4L transfers using the newly 
 API.
 
 Thanks,
 Mauro
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)

[bugzilla-daemon]

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

--- Comment #43 from Jérémy Lal kapo...@melix.org 2011-05-16 13:47:02 PDT ---
It seems the bios that's found when booting in UEFI mode is wrong.
Following that patch and procedure :
https://bugs.freedesktop.org/show_bug.cgi?id=26891
solves the issue.
When the mode is set, the screen displays weird stuff for a moment.
I'll investigate drm messages to see what happens.

-- 
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 35998] RS600: Texture alignment issues under Gnome Shell

[bugzilla-daemon]

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

--- Comment #16 from Marek Olšák mar...@gmail.com 2011-05-16 16:23:27 PDT ---
Nope, I've run out of ideas and I don't have the GPU.

(Milan, are you near Brno by any chance?)

-- 
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 36753] Some textures now rendered as completely black after register allocator rewrite.

[bugzilla-daemon]

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

--- Comment #6 from Chris Rankin ranki...@googlemail.com 2011-05-16 16:33:46 
PDT ---
Created an attachment (id=46786)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=46786)
Output of RADEON_DEBUG=nohiz,fp

(In reply to comment #5)
 The patch will give me some extra debug info.  Can you apply it and post the
 output of RADEON_DEBUG=fp.

As requested.

-- 
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 35192] BUG() in radeon driver with ATI Technologies Inc RV515 [Radeon X1300]

[bugzilla-daemon]

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





--- Comment #1 from Anthony Basile bluen...@gentoo.org  2011-05-16 23:38:38 
---
Bisecting shows that reverting 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 fixed
the problem.  The patch is in comment 28 of the Gentoo bug report.

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

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

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

--- Comment #16 from Marek Olšák mar...@gmail.com 2011-05-16 17:19:46 PDT ---
It's possible the bisection went wrong and the upload buffer size has nothing
to do with this issue.

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

[Bug 37274] New: r300g: rs690, crash in warzone2100

[bugzilla-daemon]

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

   Summary: r300g: rs690, crash in warzone2100
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: d.ok...@gmail.com


I played this game about 1-2 hours and then it crashed. Not sure if it's easily
reproducible.

I can test patches if is needed.

Here is console output:

~ $ cat /tmp/warzone2100.gdmp-ZfjND9 
Program: /usr/games/bin/warzone2100(warzone2100)
Command line: warzone2100 
Version: Version 2.3.7
Distributor: Gentoo warzone2100-2.3.7
Compiled on: May 17 2011 00:04:04
Compiled by: GCC 4.5.2
Compiled mode: Release build
Executed on: Tue May 17 02:08:08 2011
Operating system: Linux
Node name: darussia-amd
Release: 2.6.39-rc7-dirty
Version: #1 SMP Tue May 10 14:39:07 CEST 2011
Machine: x86_64

Pointers: 64bit

Compiled against PhysicsFS version: 2.0.2
Running with PhysicsFS version: 2.0.2

Misc Data:
[02:08:09]OpenGL Vendor : X.Org R300 Project
[02:08:09]OpenGL Renderer : Gallium 0.4 on ATI RS690
[02:08:09]OpenGL Version : 2.1 Mesa 7.11-devel (git-a3ac28a)
[02:08:09]OpenGL GLSL Version : 1.20
[02:08:09]Video Mode 1280 x 800 (32 bpp) (fullscreen)
[02:08:10]OpenAL Vendor: OpenAL Community
[02:08:10]OpenAL Version: 1.1 ALSOFT 1.13
[02:08:10]OpenAL Renderer: OpenAL Soft
[02:08:10]OpenAL Extensions: AL_EXT_DOUBLE AL_EXT_EXPONENT_DISTANCE
AL_EXT_FLOAT32 AL_EXT_IMA4 AL_EXT_LINEAR_DISTANCE AL_EXT_MCFORMATS AL_EXT_MULAW
AL_EXT_MULAW_MCFORMATS AL_EXT_OFFSET AL_EXT_source_distance_model
AL_LOKI_quadriphonic AL_SOFT_buffer_sub_data AL_SOF
[02:08:10]Using language: System locale
[02:08:19]Current Level/map is SUB_1_1S
[02:19:39]Current Level/map is SUB_1_1
[02:30:19]Current Level/map is SUB_1_2S
[02:31:51]Current Level/map is SUB_1_2
[02:34:46]Current Level/map is SUB_1_2S
[02:36:03]Current Level/map is SUB_1_2
[02:37:13]Current Level/map is SUB_1_2S
[02:37:38]Current Level/map is SUB_1_2
[02:50:26]Current Level/map is SUB_1_3S
[02:59:57]Current Level/map is SUB_1_3
[03:09:42]Current Level/map is SUB_1_3S
[03:22:01]Current Level/map is SUB_1_3

Dump caused by signal: SIGSEGV: Invalid memory reference: Address not mapped to
object

Log message: info|03:03:03: [seq_Play] unable to open
'sequences/cam1/sub13np1.ogg' for playback
Log message: info|03:03:03: [seq_Play] unable to open 'sequences/npend.ogg'
for playback
Log message: info|03:03:17: [seq_Play] unable to open
'sequences/cam1/sub13np1.ogg' for playback
Log message: info|03:03:17: [seq_Play] unable to open 'sequences/npend.ogg'
for playback
Log message: info|03:03:19: [seq_Play] unable to open
'sequences/cam1/sub13np1.ogg' for playback
Log message: info|03:03:19: [seq_Play] unable to open 'sequences/npend.ogg'
for playback
Log message: info|03:09:10: [seq_Play] unable to open
'sequences/cam1/sub13np2.ogg' for playback
Log message: info|03:09:10: [seq_Play] unable to open 'sequences/npend.ogg'
for playback
Log message: info|03:09:42: [seq_Play] unable to open
'sequences/cam1/sub1_3p1.ogg' for playback
Log message: info|03:09:42: [seq_Play] unable to open
'sequences/cam1/sub13bet.ogg' for playback
Log message: info|03:09:42: [seq_Play] unable to open
'sequences/cam1/sub13gam.ogg' for playback
Log message: info|03:09:42: [seq_Play] unable to open
'sequences/cam1/sub1_3.ogg' for playback
Log message: info|03:16:02: [seq_Play] unable to open
'sequences/res_droid.ogg' for playback
Log message: info|03:16:07: [seq_Play] unable to open
'sequences/res_weapons.ogg' for playback
Log message: info|03:17:52: [seq_Play] unable to open
'sequences/brfcom.ogg' for playback
Log message: info|03:17:52: [seq_Play] unable to open
'sequences/cam1/sub1_3.ogg' for playback
Log message: info|03:22:06: [seq_Play] unable to open
'sequences/cam1/sub13np1.ogg' for playback
Log message: info|03:22:06: [seq_Play] unable to open 'sequences/npend.ogg'
for playback
Log message: info|03:27:55: [seq_Play] unable to open
'sequences/cam1/sub13np2.ogg' for playback
Log message: info|03:27:55: [seq_Play] unable to open 'sequences/npend.ogg'
for playback

GLIBC raw backtrace:
warzone2100[0x616010]
/lib64/libpthread.so.0(+0xf320)[0x7f5f51cc0320]
[0x7f5f522374ba]

GDB extended backtrace:
GNU gdb (Gentoo 7.2 p1) 7.2
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 x86_64-pc-linux-gnu.
For bug reporting instructions, please see:
http://bugs.gentoo.org/...
Reading symbols from /usr/games/bin/warzone2100...(no debugging symbols
found)...done.

[Bug 36745] wine 1.3.19 and 3Dmark2001SE Dragothic demo upset kernel 2.6.38.4

[bugzilla-daemon]

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

--- Comment #16 from Andrew Randrianasulu rand...@mail.ru 2011-05-16 19:28:03 
PDT ---
(In reply to comment #15)
 Andrew,
 
 could you please make an OpenGL trace file using apitrace?
 
 Get it here:
 https://github.com/apitrace/apitrace
 
 Compile it using cmake, then run something like:
 
 TRACE_FILE=/home/..user../3dmark.trace 
 LD_PRELOAD=/path-to-apitrace/glxtrace.so
 ./executable
 
 where executable is 3Dmark2001SE. Then send the 3dmark.trace file to me.
 
 That will capture all the 3D commands and I can replay it here.

file is 37M big (bz2 compressed)

-- 
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 36745] wine 1.3.19 and 3Dmark2001SE Dragothic demo upset kernel 2.6.38.4

[bugzilla-daemon]

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

--- Comment #17 from Andrew Randrianasulu rand...@mail.ru 2011-05-16 20:23:42 
PDT ---
(In reply to comment #16)
 (In reply to comment #15)
  Andrew,
  
  could you please make an OpenGL trace file using apitrace?
  
  Get it here:
  https://github.com/apitrace/apitrace
  
  Compile it using cmake, then run something like:
  
  TRACE_FILE=/home/..user../3dmark.trace 
  LD_PRELOAD=/path-to-apitrace/glxtrace.so
  ./executable
  
  where executable is 3Dmark2001SE. Then send the 3dmark.trace file to me.
  
  That will capture all the 3D commands and I can replay it here.
 
 file is 37M big (bz2 compressed)

https://rapidshare.com/files/1581552170/3dmark.trace.gz

-- 
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