date:20090922

Re: [git pull] drm tree.

2009-09-22 Thread Ed Tomlinson

On Monday 21 September 2009 10:17:59 Alex Deucher wrote:
 On Mon, Sep 21, 2009 at 7:59 AM, Ed Tomlinson e...@aei.ca wrote:
  On Monday 21 September 2009 01:12:54 Dave Airlie wrote:
 
  Hi Linus,
 
  Please pull the 'drm-linus' branch from
  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
  drm-linus
 
  This contains the main chunk of the drm changes for 2.6.32, I think Eric
  has been on holidays for a week so I'd expect some more Intel changes
  incoming in the merge window. It also contains a few merges for things
  that were conflicting with things I sent to you via the drm-fixes tree,
  but they weren't always trivial.
 
  Major highlights core drm/non-kms:
  move mga/r128/radeon to firmware loader - major LOC churn,
  decreases in-memory radeon module footprint quite a bit.
  r600 3D support in non-kms mode.
 
  Dave,
 
  What user space stuff (xorg/mesa) is required to use the R300 3D?
 
 
 r300 3D has been available for years.  If you mean r600 3D, you need
 xf86-video-ati 6.12.4 or newer and mesa from git master.

Alex

Thanks, I did mean R600.

Ed

 
  VGA arbitration support for core drm and kms (was waiting for
  jbarnes tree to land).
 
  core KMS:
  add support for GTF/CVT/DMT modes, gets us a long way towards X
  merge intel and radeon kms framebuffer implementations for sanity.
 
  radeon KMS:
  R600 KMS support + acceleration support.
  move to generating the safe register tables with a script.
  radeon tv-out supported ported from userspace
  rn50/r100/r200 command submission trackers added
 
  intel:
  some IGDNG fixes
  important fix for wrapping at end of ring
  more SDVO tv-out support
  dynamic clocking support
 
 
  --
  Come build with us! The BlackBerryreg; Developer Conference in SF, CA
  is the only developer event you need to attend this year. Jumpstart your
  developing skills, take BlackBerry mobile applications to market and stay
  ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
  http://p.sf.net/sfu/devconf
  --
  ___
  Dri-devel mailing list
  Dri-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/dri-devel
 
 
 

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [origin tree build failure] [PATCH] Re: [git pull] drm tree.

2009-09-22 Thread Ingo Molnar


* Dave Airlie airl...@linux.ie wrote:

  there's a new build failure:
  
  drivers/built-in.o: In function `drm_irq_uninstall':
  (.text+0xb719e): undefined reference to `vga_client_register'
  drivers/built-in.o: In function `drm_irq_install':
  (.text+0xb7309): undefined reference to `vga_client_register'
  drivers/built-in.o: In function `radeon_device_fini':
  (.text+0xe400f): undefined reference to `vga_client_register'
  drivers/built-in.o: In function `radeon_device_init':
  (.text+0xe455b): undefined reference to `vga_client_register'
  
  with the attached config, introduced with upstream merge 44040f1.
  
  At first sight it appears to be due to CONFIG_DRM_RADEON relying on 
  VGA_ARB facilities but this is not expressed in the Kconfig rules. The 
  patch below solves this - but this is just a quick patch, i have not 
  investigated any deeper.
  
  Review of the code suggests that i915 has a similar dependency problem - 
  i fixed that too.
 
 The way it should work is VGA ARB should be enabled on any platforms we
 have PCI unless EMBEDDED turns it off, since arbitration of VGA isn't 
 reliant on a drm device, I'm not sure what Kconfig magic this would 
 require, and where it would need to be. This patch should at least allow
 builds to work until I figure out any Kconfig magic.
 
 From 8a874578cbf8b07b988e666c15fa0ba767f3c1cb Mon Sep 17 00:00:00 2001
 From: Dave Airlie airl...@redhat.com
 Date: Tue, 22 Sep 2009 13:53:00 +1000
 Subject: [PATCH] vgaarb: wrap the client register API so we can disable VGA 
 ARB.
 
 This provides an dummy register function so everything builds
 if VGA arb is turned off.
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  include/linux/vgaarb.h |   11 ++-
  1 files changed, 10 insertions(+), 1 deletions(-)
 
 diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
 index e81c64a..b0feb79 100644
 --- a/include/linux/vgaarb.h
 +++ b/include/linux/vgaarb.h
 @@ -41,7 +41,7 @@
   * interrupts at any time.
   */
  extern void vga_set_legacy_decoding(struct pci_dev *pdev,
 - 
 unsigned int decodes);
 + unsigned int decodes);
  
  /**
   * vga_get - acquire  locks VGA resources
 @@ -193,8 +193,17 @@ static inline int vga_conflicts(struct pci_dev *p1, 
 struct pci_dev *p2)
   * They driver will get a callback when VGA arbitration is first used
   * by userspace since we some older X servers have issues.
   */
 +#if defined(CONFIG_VGA_ARB)
  int vga_client_register(struct pci_dev *pdev, void *cookie,
   void (*irq_set_state)(void *cookie, bool state),
   unsigned int (*set_vga_decode)(void *cookie, bool 
 state));
 +#else
 +static inline int vga_client_register(struct pci_dev *pdev, void *cookie,
 +   void (*irq_set_state)(void *cookie, bool 
 state),
 +   unsigned int (*set_vga_decode)(void 
 *cookie, bool state));
 +{
 + return 0;
 +}
 +#endif

Yeah - making APIs config invariant is a good idea in any case, 
regardless of Kconfig magic.

Thanks,

Ingo

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [origin tree build failure] [PATCH] Re: [git pull] drm tree.

2009-09-22 Thread Ingo Molnar


* Dave Airlie airl...@linux.ie wrote:

 From 8a874578cbf8b07b988e666c15fa0ba767f3c1cb Mon Sep 17 00:00:00 2001
 From: Dave Airlie airl...@redhat.com
 Date: Tue, 22 Sep 2009 13:53:00 +1000
 Subject: [PATCH] vgaarb: wrap the client register API so we can disable VGA 
 ARB.
 
 This provides an dummy register function so everything builds
 if VGA arb is turned off.
 
 Signed-off-by: Dave Airlie airl...@redhat.com
 ---
  include/linux/vgaarb.h |   11 ++-
  1 files changed, 10 insertions(+), 1 deletions(-)

btw., i hope you have not commited this yet, there's a trivial problem 
with this patch:

 diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
 index e81c64a..b0feb79 100644
 --- a/include/linux/vgaarb.h
 +++ b/include/linux/vgaarb.h
 @@ -41,7 +41,7 @@
   * interrupts at any time.
   */
  extern void vga_set_legacy_decoding(struct pci_dev *pdev,
 - 
 unsigned int decodes);
 + unsigned int decodes);
  
  /**
   * vga_get - acquire  locks VGA resources
 @@ -193,8 +193,17 @@ static inline int vga_conflicts(struct pci_dev *p1, 
 struct pci_dev *p2)
   * They driver will get a callback when VGA arbitration is first used
   * by userspace since we some older X servers have issues.
   */
 +#if defined(CONFIG_VGA_ARB)
  int vga_client_register(struct pci_dev *pdev, void *cookie,
   void (*irq_set_state)(void *cookie, bool state),
   unsigned int (*set_vga_decode)(void *cookie, bool 
 state));
 +#else
 +static inline int vga_client_register(struct pci_dev *pdev, void *cookie,
 +   void (*irq_set_state)(void *cookie, bool 
 state),
 +   unsigned int (*set_vga_decode)(void 
 *cookie, bool state));
 +{
 + return 0;
 +}
 +#endif

that ';' in the inline prototype is bogus, this wont build.

Ingo

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [origin tree build failure] [PATCH] Re: [git pull] drm tree.

2009-09-22 Thread Dave Airlie

  Subject: [PATCH] vgaarb: wrap the client register API so we can disable VGA 
  ARB.
  
  This provides an dummy register function so everything builds
  if VGA arb is turned off.
  
  Signed-off-by: Dave Airlie airl...@redhat.com
  ---
   include/linux/vgaarb.h |   11 ++-
   1 files changed, 10 insertions(+), 1 deletions(-)
 
 btw., i hope you have not commited this yet, there's a trivial problem 
 with this patch:

oops, i was going to push it to jbarnes after I had a chance to play with
it.

I'll clean it up and send it to jbarnes tomorrow.

Dave.

 
  diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
  index e81c64a..b0feb79 100644
  --- a/include/linux/vgaarb.h
  +++ b/include/linux/vgaarb.h
  @@ -41,7 +41,7 @@
* interrupts at any time.
*/
   extern void vga_set_legacy_decoding(struct pci_dev *pdev,
  -   
  unsigned int decodes);
  +   unsigned int decodes);
   
   /**
* vga_get - acquire  locks VGA resources
  @@ -193,8 +193,17 @@ static inline int vga_conflicts(struct pci_dev *p1, 
  struct pci_dev *p2)
* They driver will get a callback when VGA arbitration is first used
* by userspace since we some older X servers have issues.
*/
  +#if defined(CONFIG_VGA_ARB)
   int vga_client_register(struct pci_dev *pdev, void *cookie,
  void (*irq_set_state)(void *cookie, bool state),
  unsigned int (*set_vga_decode)(void *cookie, bool 
  state));
  +#else
  +static inline int vga_client_register(struct pci_dev *pdev, void *cookie,
  + void (*irq_set_state)(void *cookie, bool 
  state),
  + unsigned int (*set_vga_decode)(void 
  *cookie, bool state));
  +{
  +   return 0;
  +}
  +#endif
 
 that ';' in the inline prototype is bogus, this wont build.
 
   Ingo
 
 --
 Come build with us! The BlackBerryreg; Developer Conference in SF, CA
 is the only developer event you need to attend this year. Jumpstart your
 developing skills, take BlackBerry mobile applications to market and stay 
 ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
 http://p.sf.net/sfu/devconf
 --
 ___
 Dri-devel mailing list
 Dri-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dri-devel
 
 

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [origin tree build failure] [PATCH] Re: [git pull] drm tree.

2009-09-22 Thread Ingo Molnar


here's a patch that works for me.

Ingo

Signed-off-by: Ingo Molnar mi...@elte.hu
---
 include/linux/vgaarb.h |   11 ++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index e81c64a..923f904 100644
--- a/include/linux/vgaarb.h
+++ b/include/linux/vgaarb.h
@@ -41,7 +41,7 @@
  * interrupts at any time.
  */
 extern void vga_set_legacy_decoding(struct pci_dev *pdev,
-   
unsigned int decodes);
+   unsigned int decodes);
 
 /**
  * vga_get - acquire  locks VGA resources
@@ -193,8 +193,17 @@ static inline int vga_conflicts(struct pci_dev *p1, struct 
pci_dev *p2)
  * They driver will get a callback when VGA arbitration is first used
  * by userspace since we some older X servers have issues.
  */
+#if defined(CONFIG_VGA_ARB)
 int vga_client_register(struct pci_dev *pdev, void *cookie,
void (*irq_set_state)(void *cookie, bool state),
unsigned int (*set_vga_decode)(void *cookie, bool 
state));
+#else
+static inline int vga_client_register(struct pci_dev *pdev, void *cookie,
+ void (*irq_set_state)(void *cookie, bool 
state),
+ unsigned int (*set_vga_decode)(void 
*cookie, bool state))
+{
+   return 0;
+}
+#endif
 
 #endif /* LINUX_VGA_H */

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 24080] New: Darwinia crashes in rv670 when starting a level

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=24080

   Summary: Darwinia crashes in rv670 when starting a level
   Product: Mesa
   Version: git
  Platform: Other
OS/Version: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: fran...@gmail.com


Darwinia starts and the world selection works ok, but when entering a level it
segfaults with the following backtrace:

#0  0xf7c58dc6 in memcpy () from /lib32/libc.so.6
#1  0xf218e008 in ?? ()
#2  0xf7486dfc in _mesa_memcpy (dest=0x0, src=0xf218e008, n=2048) at
/usr/include/bits/string3.h:52
#3  0xf74c0efa in memcpy_texture (ctx=value optimized out, dimensions=value
optimized out,
dstFormat=0xf7677bc0, dstAddr=0x0, dstXoffset=0, dstYoffset=0,
dstZoffset=0, dstRowStride=2048,
dstImageOffsets=0xf38e6310, srcWidth=value optimized out, srcHeight=512,
srcDepth=1, srcFormat=6408,
srcType=5121, srcAddr=0xf218e008, srcPacking=0xa82ba1c) at
main/texstore.c:989
#4  0xf74c7547 in _mesa_texstore_rgba (ctx=0xa81ead8, dims=2,
baseInternalFormat=6408,
dstFormat=0xf7677bc0, dstAddr=0x0, dstXoffset=0, dstYoffset=0,
dstZoffset=0, dstRowStride=2048,
dstImageOffsets=0xf38e6310, srcWidth=512, srcHeight=512, srcDepth=1,
srcFormat=6408, srcType=5121,
srcAddr=0xf218e008, srcPacking=0xa82ba1c) at main/texstore.c:1394
#5  0xf743a9ab in radeon_teximage (ctx=0xa81ead8, dims=value optimized out,
target=3553, level=0,
internalFormat=6408, width=512, height=512, depth=1, imageSize=0,
format=6408, type=5121,
pixels=value optimized out, packing=0xa82ba1c, texObj=0xab0acd0,
texImage=0xf34898c0, compressed=0)
at radeon_texture.c:649
#6  0xf743ad47 in radeonTexImage2D (ctx=0xa81ead8, target=3553, level=0,
internalFormat=6408, width=512,
height=512, border=0, format=6408, type=5121, pixels=0xf218e008,
packing=0xa82ba1c, texObj=0xab0acd0,
texImage=0xf34898c0) at radeon_texture.c:693
#7  0xf75550fd in copy_tex_image (ctx=0xa81ead8, dims=value optimized out,
target=3553, level=0,
internalFormat=6408, x=0, y=0, width=512, height=512, border=0) at
drivers/common/meta.c:2224
#8  0xf74b8779 in _mesa_CopyTexImage2D (target=3553, level=0,
internalFormat=6408, x=0, y=0, width=512,
height=512, border=0) at main/teximage.c:2812


It seems the problem is the call to _mesa_texstore_rgba with dstAddr=0x0.

I had to apply the patch in here: http://pastebin.com/m5e85e97f to avoid the
following assertion:

radeon_mipmap_tree.c:117: compute_tex_image_offset: Assertion `lvl-size  0'
failed

I don't know if the bug is caused by that.

This is with the latest mesa git (commit
6a09c9d2d891a7118bc7c07d03900d69154116ba, 2009-09-22 11:35:56 GMT).


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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: startx broken on today's git tree

2009-09-22 Thread Peter Zijlstra

On Tue, 2009-09-22 at 19:12 +0800, Xiaotian Feng wrote:
 Hi,
 
 I used today's git tree with FC11 configs plus some debug configs,
 then I found my FC11 can not startx anymore...  Each time I run
 startx, I'll get a Fatal error:
 
 (EE) Screen(s) found, but none have a usable configuration.
 
 Then from dmesg, I saw flood messages:
 
  [drm:radeon_cp_getparam_kms] *ERROR* invalid ioctl with kms
 radeon_cp_getparam_kms
 
 Attach is my dmesg log, any ideas on this issue? Thank you.

Disable radeon KMS, or upgrade your xorg radeon driver.

I don't think F11 includes a new enough radeon driver for KMS to work.

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=23965


Phil Armstrong p...@kantaka.co.uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Comment #8 from Phil Armstrong p...@kantaka.co.uk  2009-09-22 07:58:12 
PST ---
Hmm. Just compiled latest mesa (as of today) and it seems fine now.

Will mark as fixed  reopen if it pops up again.


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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 23670] [bisected i915 i965] glean case pixelFormats failed

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=23670


Brian Paul brian.e.p...@gmail.com changed:

   What|Removed |Added

 Depends on||24083




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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=24066





--- Comment #5 from Krzysztof A. Sobiecki sob...@gmail.com  2009-09-22 
11:03:55 PST ---
Created an attachment (id=29764)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=29764)
backtrace from Mesa:bae2d5882781f798001be6f7841c32a1f12046fe with patch for
episode one

It not as useful as I hoped.
Episode One, mesa with patch.


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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=24066





--- Comment #6 from Krzysztof A. Sobiecki sob...@gmail.com  2009-09-22 
11:25:14 PST ---
Created an attachment (id=29766)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=29766)
Output from RADEON_DEBUG=all for same Mesa episode One.

I have also output from bugle:
http://rapidshare.com/files/283570674/bugle_patched.log.lzma
It's to big to post it here, it might not be so useful after all.
But, if asked, I might post part just before crash.
Episode One.


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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=24066





--- Comment #7 from Krzysztof A. Sobiecki sob...@gmail.com  2009-09-22 
11:39:54 PST ---
With mesa:bae2d5882781f798001be6f7841c32a1f12046fe
Episode two:
Mesa: User error: GL_OUT_OF_MEMORY in glBufferDataARB(access)
Mesa: User error: GL_OUT_OF_MEMORY in glMapBufferARB(access)

Program received signal SIGSEGV, Segmentation fault.
memcpy () at ../sysdeps/i386/i686/memcpy.S:75
75  ../sysdeps/i386/i686/memcpy.S: Nie ma takiego pliku ani katalogu.
in ../sysdeps/i386/i686/memcpy.S
Current language:  auto; currently asm
(gdb) bt
#0  memcpy () at ../sysdeps/i386/i686/memcpy.S:75
#1  0x in ?? ()
(gdb) bt full
#0  memcpy () at ../sysdeps/i386/i686/memcpy.S:75
No locals.
#1  0x in ?? ()
It doesn't look useful.
No symbol table info available.
With 2nd episode after creating character I see in previous episode
introduction before crash.


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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=24066


Nicolai Hähnle nhaeh...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Comment #8 from Nicolai Hähnle nhaeh...@gmail.com  2009-09-22 12:05:45 
PST ---
I have committed a slightly different fix to the Mesa 7.6 branch for the
original crash.

The secondary crash looks like a VBO problem: Maybe the app tries to map a
buffer, this fails for some non-obvious reason, and then because the app
doesn't check the GL error code, it crashes trying to access a null pointer?

If this crash does persist, could you please open a new bug report for it,
since it seems to be a clearly distinct bug, which also requires some other
information (e.g. are you running KMS, what's the version of other system
components).


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=24066





--- Comment #9 from Krzysztof A. Sobiecki sob...@gmail.com  2009-09-22 
12:07:53 PST ---
Created an attachment (id=29768)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=29768)
Game screenshot.

Skipping in previous episode
On the Rain-Slick Precipice of Darkness, Episode Two allows me to start game
without crash. It's look strange, so I'm attaching screen shot.
Episode One still crashes.
Everything with patch.


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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

2009-09-22 Thread Robert Noland

Build was broken by commit 9666529b5a5be1fcde82caadc2fe2efa5ea81e49

I'm not certain that this is entirely the correct fix since the demo
from bug #23774 seemed to work before the commit that broke the build.

Signed-off-by: Robert Noland rnol...@2hip.net
---
 src/glx/x11/glxhash.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/src/glx/x11/glxhash.c b/src/glx/x11/glxhash.c
index 7d28ada..dcf8c98 100644
--- a/src/glx/x11/glxhash.c
+++ b/src/glx/x11/glxhash.c
@@ -87,6 +87,12 @@
 
 #define HASH_ALLOC malloc
 #define HASH_FREE  free
+#ifndef __GLIBC__
+#define HASH_RANDOM_DECL   char *ps, rs[256]
+#define HASH_RANDOM_INIT(seed) ps = initstate(seed, rs, sizeof(rs))
+#define HASH_RANDOMrandom()
+#define HASH_RANDOM_DESTROYsetstate(ps)
+#else
 #define HASH_RANDOM_DECL   struct random_data rd; int32_t rv; char rs[256]
 #define HASH_RANDOM_INIT(seed) \
do {\
@@ -95,6 +101,7 @@
} while(0)
 #define HASH_RANDOM ((void) random_r(rd, rv), rv)
 #define HASH_RANDOM_DESTROY
+#endif
 
 typedef struct __glxHashBucket
 {
-- 
1.6.4


--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

preventing GPU reset DoS

2009-09-22 Thread Pauli Nieminen

Hi!

I have been thinking GPU reset as possible DoS attack from
user-space.Problem here is that display doesn't work anymore at all if
attacker chooses to run a application that constantly causes GPU hang. It
would be of course ideal to have CS checker not to let in any problematic
combinations of commands. Butin practice we can't assume that everything is
safe with all hardware so we need to take some actions prevent possible
problems.

So first defense would be terminating application that did send command
stream that caused GPU hang. But attacker could easily by-pass this
protection with forking all the time new processes.

So we need stronger defense if same user account is causing multiple hangs
in short time frame. I would think temporary denying new DRI access would
let user to gain back control of system and take actions to stop the
problematic program from running.

Pauli
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 22271] On 64bit kernel(drm-next-radeon) ioctls from 32bit application doesn't work

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=22271


Krzysztof A. Sobiecki sob...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Comment #15 from Krzysztof A. Sobiecki sob...@gmail.com  2009-09-22 
12:23:34 PST ---
Commit migrated into main tree. I'm closing this bug.


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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

2009-09-22 Thread Brian Paul

Robert Noland wrote:
 Build was broken by commit 9666529b5a5be1fcde82caadc2fe2efa5ea81e49
 
 I'm not certain that this is entirely the correct fix since the demo
 from bug #23774 seemed to work before the commit that broke the build.
 
 Signed-off-by: Robert Noland rnol...@2hip.net
 ---
  src/glx/x11/glxhash.c |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/src/glx/x11/glxhash.c b/src/glx/x11/glxhash.c
 index 7d28ada..dcf8c98 100644
 --- a/src/glx/x11/glxhash.c
 +++ b/src/glx/x11/glxhash.c
 @@ -87,6 +87,12 @@
  
  #define HASH_ALLOC malloc
  #define HASH_FREE  free
 +#ifndef __GLIBC__
 +#define HASH_RANDOM_DECL char *ps, rs[256]
 +#define HASH_RANDOM_INIT(seed)   ps = initstate(seed, rs, sizeof(rs))
 +#define HASH_RANDOM  random()
 +#define HASH_RANDOM_DESTROY  setstate(ps)
 +#else
  #define HASH_RANDOM_DECL struct random_data rd; int32_t rv; char rs[256]
  #define HASH_RANDOM_INIT(seed)   \
 do {  \
 @@ -95,6 +101,7 @@
 } while(0)
  #define HASH_RANDOM ((void) random_r(rd, rv), rv)
  #define HASH_RANDOM_DESTROY
 +#endif
  
  typedef struct __glxHashBucket
  {

I was just looking at this after my coworker found the build failure 
on MacOS.

Would nrand48() be a more portable option?  Ian?

See http://evanjones.ca/random-thread-safe.html

-Brian


--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: preventing GPU reset DoS

2009-09-22 Thread Keith Whitwell

On Tue, 2009-09-22 at 12:13 -0700, Pauli Nieminen wrote:
 Hi!
 
 I have been thinking GPU reset as possible DoS attack from
 user-space.Problem here is that display doesn't work anymore at all if
 attacker chooses to run a application that constantly causes GPU hang.
 It would be of course ideal to have CS checker not to let in any
 problematic combinations of commands. Butin practice we can't assume
 that everything is safe with all hardware so we need to take some
 actions prevent possible problems.
 
 So first defense would be terminating application that did send
 command stream that caused GPU hang. But attacker could easily by-pass
 this protection with forking all the time new processes.
 
 So we need stronger defense if same user account is causing multiple
 hangs in short time frame. I would think temporary denying new DRI
 access would let user to gain back control of system and take actions
 to stop the problematic program from running.

OK, but you'd want to be able to turn it off for developers -- you've
just described my normal workflow...

Keith


--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: preventing GPU reset DoS

2009-09-22 Thread Dave Airlie

On Wed, Sep 23, 2009 at 5:13 AM, Pauli Nieminen suok...@gmail.com wrote:
 Hi!

 I have been thinking GPU reset as possible DoS attack from
 user-space.Problem here is that display doesn't work anymore at all if
 attacker chooses to run a application that constantly causes GPU hang. It
 would be of course ideal to have CS checker not to let in any problematic
 combinations of commands. Butin practice we can't assume that everything is
 safe with all hardware so we need to take some actions prevent possible
 problems.

 So first defense would be terminating application that did send command
 stream that caused GPU hang. But attacker could easily by-pass this
 protection with forking all the time new processes.

 So we need stronger defense if same user account is causing multiple hangs
 in short time frame. I would think temporary denying new DRI access would
 let user to gain back control of system and take actions to stop the
 problematic program from running.


It depends on what sort of system you are talking about, in a normal
desktop/laptop user type systems, the DoS is either going to be
sitting at it in which case the power button, or caused by an app
running on it, possibly X, in which case killing it will solve the issue.

In a multi-user gpgpu environment, if someone starts a DoS, it
should only lock up the GPU not the CPU, unless the start a CPU
DoS as well, so in that case an admin can always ssh in and
kill the DoS user a/c etc.

I'm just wondering what other use-case we'd need anything more
agressive?

Dave.

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=24066





--- Comment #10 from Krzysztof A. Sobiecki sob...@gmail.com  2009-09-22 
13:16:03 PST ---
I have tested your patch and it worked. game still crashes(while squid thing
explode in last time movie) but if I skip last time it gets into the game.
It looks identical like on screenshot I attached before.
I'm filling new bugreport now.


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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: preventing GPU reset DoS

2009-09-22 Thread Nicolai Hähnle

Am Tuesday 22 September 2009 21:13:47 schrieb Pauli Nieminen:
 Hi!

 I have been thinking GPU reset as possible DoS attack from
 user-space.Problem here is that display doesn't work anymore at all if
 attacker chooses to run a application that constantly causes GPU hang. It
 would be of course ideal to have CS checker not to let in any problematic
 combinations of commands. Butin practice we can't assume that everything is
 safe with all hardware so we need to take some actions prevent possible
 problems.

I'm pretty confident that you can write a perfectly legal OpenGL application 
that creates commands that take *minutes* to run on decent graphics cards. 
Just produce a huge number of screen-sized primitives and use a very long 
fragment program that samples from a huge, non-mipmapped texture in an 
entirely non-locally-coherent way - and that doesn't even take GLSL loops into 
account!

So this is really not so much about safe-guarding against illegal hardware 
commands, but about how to deal with the fact that we can't do pre-emptive 
scheduling on the GPU.

In the end, the symptoms are the same, but it might change how you think about 
the problem.

 So first defense would be terminating application that did send command
 stream that caused GPU hang. But attacker could easily by-pass this
 protection with forking all the time new processes.

 So we need stronger defense if same user account is causing multiple hangs
 in short time frame. I would think temporary denying new DRI access would
 let user to gain back control of system and take actions to stop the
 problematic program from running.

I have a feeling that this needs a solution that cooperates across the whole 
stack ...

cu,
Nicolai

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

2009-09-22 Thread Ian Romanick

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Paul wrote:
 Robert Noland wrote:
 Build was broken by commit 9666529b5a5be1fcde82caadc2fe2efa5ea81e49

 I'm not certain that this is entirely the correct fix since the demo
 from bug #23774 seemed to work before the commit that broke the build.

 Signed-off-by: Robert Noland rnol...@2hip.net
 ---
  src/glx/x11/glxhash.c |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)

 diff --git a/src/glx/x11/glxhash.c b/src/glx/x11/glxhash.c
 index 7d28ada..dcf8c98 100644
 --- a/src/glx/x11/glxhash.c
 +++ b/src/glx/x11/glxhash.c
 @@ -87,6 +87,12 @@
  
  #define HASH_ALLOC malloc
  #define HASH_FREE  free
 +#ifndef __GLIBC__

According to the manual page, _SVID_SOURCE || _BSD_SOURCE is required
for initstate_r and friends.  The non-_r versions require _SVID_SOURCE
|| _BSD_SOURCE || _XOPEN_SOURCE = 500.  Specifically, it says:

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

   random_r(), srandom_r(), initstate_r(), setstate_r(): _SVID_SOURCE ||
   _BSD_SOURCE

Does that mean that you have to use (__GLIBC__  (_SVID_SOURCE ||
_BSD_SOURCE)), or does it mean that just using (_SVID_SOURCE ||
_BSD_SOURCE) is sufficient?  I guess the other alternative is to have
some autoconf mechanism to test for those functions.  That's probably
the right answer anyway.

The non-_r versions don't fix the bug.  The bug was that the hash
functions modified the global random number state.

 +#define HASH_RANDOM_DECLchar *ps, rs[256]
 +#define HASH_RANDOM_INIT(seed)ps = initstate(seed, rs, sizeof(rs))
 +#define HASH_RANDOMrandom()
 +#define HASH_RANDOM_DESTROYsetstate(ps)
 +#else
  #define HASH_RANDOM_DECLstruct random_data rd; int32_t rv; char
 rs[256]
  #define HASH_RANDOM_INIT(seed)\
 do {\
 @@ -95,6 +101,7 @@
 } while(0)
  #define HASH_RANDOM ((void) random_r(rd, rv), rv)
  #define HASH_RANDOM_DESTROY
 +#endif
  
  typedef struct __glxHashBucket
  {
 
 I was just looking at this after my coworker found the build failure on
 MacOS.
 
 Would nrand48() be a more portable option?  Ian?
 
 See http://evanjones.ca/random-thread-safe.html

nrand48 may be thread-safe, but it still brings back the bug.

I guess we can use feature test macros to select the _r functions on
platforms that support it, and we can let the bug continue to exist on
platforms that leave no (reasonable) alternative.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq5M54ACgkQX1gOwKyEAw8aEQCgkYH9x9mvStfpx9AFJbEN9lDm
powAoIqN4zG1H1+SfWozGa4X121WjWL7
=FYL2
-END PGP SIGNATURE-

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: preventing GPU reset DoS

2009-09-22 Thread Corbin Simpson

On 09/22/2009 01:19 PM, Nicolai Hähnle wrote:
 I'm pretty confident that you can write a perfectly legal OpenGL application 
 that creates commands that take *minutes* to run on decent graphics cards. 
 Just produce a huge number of screen-sized primitives and use a very long 
 fragment program that samples from a huge, non-mipmapped texture in an 
 entirely non-locally-coherent way - and that doesn't even take GLSL loops 
 into 
 account!

I don't have any examples with me, but you could, as an admittedly
contrived possibility, take several hundred thousand verts, submit them
in immediate mode without VBOs, multitexture from all eight texture
samplers using 256x256x256 3D textures, use 4 4096x4096 render targets,
and 16x FSAA multisample the whole shebang. Should (barely) fit on a
512MB r500, and take at least half a minute to execute, probably more.

And as you said, GLSL can be used to write *very* long-running shaders.

Really, there's no solution to this that won't also lock out legitimate
uses, I fear.

~ C.

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: preventing GPU reset DoS

2009-09-22 Thread Pauli Nieminen

On Tue, Sep 22, 2009 at 11:51 PM, Corbin Simpson
mostawesomed...@gmail.comwrote:

 On 09/22/2009 01:19 PM, Nicolai Hähnle wrote:
  I'm pretty confident that you can write a perfectly legal OpenGL
 application
  that creates commands that take *minutes* to run on decent graphics
 cards.
  Just produce a huge number of screen-sized primitives and use a very long
  fragment program that samples from a huge, non-mipmapped texture in an
  entirely non-locally-coherent way - and that doesn't even take GLSL loops
 into
  account!

 I don't have any examples with me, but you could, as an admittedly
 contrived possibility, take several hundred thousand verts, submit them
 in immediate mode without VBOs, multitexture from all eight texture
 samplers using 256x256x256 3D textures, use 4 4096x4096 render targets,
 and 16x FSAA multisample the whole shebang. Should (barely) fit on a
 512MB r500, and take at least half a minute to execute, probably more.

 And as you said, GLSL can be used to write *very* long-running shaders.

 Really, there's no solution to this that won't also lock out legitimate
 uses, I fear.

 ~ C.

 Too bad GPU reset is already now stopping this use case while it doesn't
protect user from possible attack causing multiple GPU reset in row. So this
long rendering operation blocking GPU is more like scheduler or mesa bug
that it doesn't split rendering to small enough parts that we can scheduler
something else in between for user interface. Is it possible to scheduler
something els to GPU wile only part of GPU runs the slow and long running
shader? If no then it looks like big limitation in hw design.

I can see also possible attacks that use GPU hang as way to disable
computers from local use possible scenario. And if this only requires access
to normal user account it is real problem and should be protected. It is
possible that someone would write virus that targets Linux desktop and tries
to casue harm to users.
This kind of virus in corporate network causing many computers fall to
unusable state would cost quite a lot. Even tough admin could clean the
virus with ssh but it still cost a lot of money when computer is unusable
even for short time.

Do I have to come up with more scenarios why GPU reset would need to protect
local access to computer? I think it is just bad if normal user can cause
local access to be unusable for extended period of time.

Of course this protections has to be configurable in runtime or boot time.

And I posted idea here before even exploring how it would be practically
possible to get more toughs what should be taken in account.
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

2009-09-22 Thread Robert Noland

On Tue, 2009-09-22 at 13:29 -0700, Ian Romanick wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Brian Paul wrote:
  Robert Noland wrote:
  Build was broken by commit 9666529b5a5be1fcde82caadc2fe2efa5ea81e49
 
  I'm not certain that this is entirely the correct fix since the demo
  from bug #23774 seemed to work before the commit that broke the build.
 
  Signed-off-by: Robert Noland rnol...@2hip.net
  ---
   src/glx/x11/glxhash.c |7 +++
   1 files changed, 7 insertions(+), 0 deletions(-)
 
  diff --git a/src/glx/x11/glxhash.c b/src/glx/x11/glxhash.c
  index 7d28ada..dcf8c98 100644
  --- a/src/glx/x11/glxhash.c
  +++ b/src/glx/x11/glxhash.c
  @@ -87,6 +87,12 @@
   
   #define HASH_ALLOC malloc
   #define HASH_FREE  free
  +#ifndef __GLIBC__
 
 According to the manual page, _SVID_SOURCE || _BSD_SOURCE is required
 for initstate_r and friends.  The non-_r versions require _SVID_SOURCE
 || _BSD_SOURCE || _XOPEN_SOURCE = 500.  Specifically, it says:
 
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
 
random_r(), srandom_r(), initstate_r(), setstate_r(): _SVID_SOURCE ||
_BSD_SOURCE
 
 Does that mean that you have to use (__GLIBC__  (_SVID_SOURCE ||
 _BSD_SOURCE)), or does it mean that just using (_SVID_SOURCE ||
 _BSD_SOURCE) is sufficient?  I guess the other alternative is to have
 some autoconf mechanism to test for those functions.  That's probably
 the right answer anyway.
 
 The non-_r versions don't fix the bug.  The bug was that the hash
 functions modified the global random number state.
 
  +#define HASH_RANDOM_DECLchar *ps, rs[256]
  +#define HASH_RANDOM_INIT(seed)ps = initstate(seed, rs, sizeof(rs))
  +#define HASH_RANDOMrandom()
  +#define HASH_RANDOM_DESTROYsetstate(ps)
  +#else
   #define HASH_RANDOM_DECLstruct random_data rd; int32_t rv; char
  rs[256]
   #define HASH_RANDOM_INIT(seed)\
  do {\
  @@ -95,6 +101,7 @@
  } while(0)
   #define HASH_RANDOM ((void) random_r(rd, rv), rv)
   #define HASH_RANDOM_DESTROY
  +#endif
   
   typedef struct __glxHashBucket
   {
  
  I was just looking at this after my coworker found the build failure on
  MacOS.
  
  Would nrand48() be a more portable option?  Ian?
  
  See http://evanjones.ca/random-thread-safe.html
 
 nrand48 may be thread-safe, but it still brings back the bug.

I guess that I am still trying to understand the original bug... The
demo program that was included in the bug report seems to work fine
here, unless I don't know what the output *should* look like.  It seems
to work both before and after this change on FreeBSD.  FWIW, we use mesa
glut, not freeglut.

balrog% ./opengl-demo
These numbers are random
1219944491
1580682328
7689659
391079993
1581482531
571799598
246523261
820492564
1026025761
121279717
IRQ's not enabled, falling back to busy waits: 2 0

These numbers are not
386222616
1547925878
1373331788
433122960
1675509037
327321748
1590998669
1595741086
1844648666
1936201370

robert.

 I guess we can use feature test macros to select the _r functions on
 platforms that support it, and we can let the bug continue to exist on
 platforms that leave no (reasonable) alternative.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAkq5M54ACgkQX1gOwKyEAw8aEQCgkYH9x9mvStfpx9AFJbEN9lDm
 powAoIqN4zG1H1+SfWozGa4X121WjWL7
 =FYL2
 -END PGP SIGNATURE-
-- 
Robert Noland rnol...@2hip.net
2Hip Networks


--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[Bug 23670] [bisected i915 i965] glean case pixelFormats failed

2009-09-22 Thread bugzilla-daemon

http://bugs.freedesktop.org/show_bug.cgi?id=23670





--- Comment #13 from Brian Paul brian.e.p...@gmail.com  2009-09-22 15:08:06 
PST ---
OK, can you retest with the latest code from git?  Commit
926b965ed53efc06a9d7cc6e07eff853b263960a should help with this.


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

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

2009-09-22 Thread Ian Romanick

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Noland wrote:
 I guess that I am still trying to understand the original bug... The
 demo program that was included in the bug report seems to work fine
 here, unless I don't know what the output *should* look like.  It seems
 to work both before and after this change on FreeBSD.  FWIW, we use mesa
 glut, not freeglut.
 
 balrog% ./opengl-demo
 These numbers are random
 1219944491
 1580682328
 7689659
 391079993
 1581482531
 571799598
 246523261
 820492564
 1026025761
 121279717
 IRQ's not enabled, falling back to busy waits: 2 0
 
 These numbers are not
 386222616
 1547925878
 1373331788
 433122960
 1675509037
 327321748
 1590998669
 1595741086
 1844648666
 1936201370

I believe that running the test multiple times will generate the same
output after These numbers are not.  That's the bug.  The code calls
HASH_RANDOM_INIT with a constant value.  If HASH_RANDOM_INIT modifies
the global random number generator state (e.g., by calling srandom),
applications will get a predictable random number sequence after calling
into GLX... whether they want it or not.

The available choices for fixing the bug seemed to be:

 1. Use our own random number generator that doesn't modify the global
state.

 2. Just don't call srandom, but use random anyway.  This also modifies
the global state and could break other applications.  This seems
unlikely, but it is possible.

 3. Use a system random number generator that doesn't modify the global
state.

I picked option 3.  Option 2 was my second choice.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq5SnoACgkQX1gOwKyEAw/H6ACeNo9DP7wTYMLecSA+z0FAUPRr
oewAnRiR4KTaq+izFYGNreYzaY6Et1Ox
=ueET
-END PGP SIGNATURE-

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

2009-09-22 Thread Robert Noland

On Tue, 2009-09-22 at 15:06 -0700, Ian Romanick wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Robert Noland wrote:
  I guess that I am still trying to understand the original bug... The
  demo program that was included in the bug report seems to work fine
  here, unless I don't know what the output *should* look like.  It seems
  to work both before and after this change on FreeBSD.  FWIW, we use mesa
  glut, not freeglut.
  
  balrog% ./opengl-demo
  These numbers are random
  1219944491
  1580682328
  7689659
  391079993
  1581482531
  571799598
  246523261
  820492564
  1026025761
  121279717
  IRQ's not enabled, falling back to busy waits: 2 0
  
  These numbers are not
  386222616
  1547925878
  1373331788
  433122960
  1675509037
  327321748
  1590998669
  1595741086
  1844648666
  1936201370
 
 I believe that running the test multiple times will generate the same
 output after These numbers are not.  That's the bug.  The code calls
 HASH_RANDOM_INIT with a constant value.  If HASH_RANDOM_INIT modifies
 the global random number generator state (e.g., by calling srandom),
 applications will get a predictable random number sequence after calling
 into GLX... whether they want it or not.

Well, I don't have a log of the output without my patch... But, with my
patch this is not the case.  Running the demo multiple times produces
different values.  If it is of interest, I can revert the patch that
broke the build and re-examine the output before any of these changes.
Is it possible that the real issue is with freeglut?

balrog% ./opengl-demo
These numbers are random
1272970576
1584379418
2015139173
479483774
1325146074
177162681
1160844825
430040780
1412917305
26976609
IRQ's not enabled, falling back to busy waits: 2 0

These numbers are not
276817946
1029639020
719781614
594202947
969971679
765644576
466376008
66254906
1149675996
1694092713
balrog% ./opengl-demo
These numbers are random
1273004190
1846269
965472025
301887443
1465880287
1117585225
1362899913
1198258889
35505857
1893968380
IRQ's not enabled, falling back to busy waits: 2 0

These numbers are not
1923946826
1113031703
2141266951
742689031
1199587653
893205935
1201457015
99318364
648950029
1981177937
balrog% ./opengl-demo
These numbers are random
1273020997
284321518
440638451
1286831101
462505570
1587796497
1463927457
508626120
1494283780
1753722442
IRQ's not enabled, falling back to busy waits: 2 0

These numbers are not
600027619
80986221
1778267796
816932073
1314395640
2030728438
495255695
115850093
1472328869
2124720549
balrog% 

robert.

 The available choices for fixing the bug seemed to be:
 
  1. Use our own random number generator that doesn't modify the global
 state.
 
  2. Just don't call srandom, but use random anyway.  This also modifies
 the global state and could break other applications.  This seems
 unlikely, but it is possible.
 
  3. Use a system random number generator that doesn't modify the global
 state.
 
 I picked option 3.  Option 2 was my second choice.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAkq5SnoACgkQX1gOwKyEAw/H6ACeNo9DP7wTYMLecSA+z0FAUPRr
 oewAnRiR4KTaq+izFYGNreYzaY6Et1Ox
 =ueET
 -END PGP SIGNATURE-
-- 
Robert Noland rnol...@2hip.net
2Hip Networks


--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[git pull] two radeon fixes.

2009-09-22 Thread Dave Airlie


Hi Linus,

Please pull the 'drm-next' branch from
ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-next

These fix one regression in kms and a bug on the blit path.

Dave.

 drivers/gpu/drm/radeon/r600_blit.c |2 +-
 drivers/gpu/drm/radeon/r600_blit_kms.c |2 +-
 drivers/gpu/drm/radeon/radeon.h|   59 +---
 drivers/gpu/drm/radeon/radeon_drv.h|   65 +-
 drivers/gpu/drm/radeon/radeon_family.h |   97 
 5 files changed, 102 insertions(+), 123 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_family.h

commit 5b31aee9d72f529ee6b60e8d66967f817a0e39fc
Author: Andre Maasikas amaasi...@gmail.com
Date:   Mon Sep 21 08:59:41 2009 -0400

drm/radeon/r600: set correct pitch for 4 byte copy

[agd5f: also fix the non-kms path]

Signed-off-by: Alex Deucher alexdeuc...@gmail.com

commit c214271563c00f2721c5111e27b53bf06dabc6e4
Author: Dave Airlie airl...@linux.ie
Date:   Tue Sep 22 08:50:10 2009 +1000

drm/radeon: consolidate family flags used in pciids.

having these separate was pointless and introduced a bug when
one got updated without the other.

Signed-off-by: Dave Airlie airl...@redhat.com

--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH] drm/kms: start adding command line interface using fb.

2009-09-22 Thread Dave Airlie

From: Dave Airlie airl...@linux.ie

[note this requires an fb patch posted to linux-fbdev-devel already]

This uses the normal video= command line option to control the kms
output setup at boot time. It is used to override the autodetection
done by kms.

video= normally takes a framebuffer as the first parameter, in kms
it will take a connector name, DVI-I-1, or LVDS-1 etc. If no output
connector is specified the mode string will apply to all connectors.

The mode specification used will match down the probed modes, and if
no mode is found it will add a CVT mode that matches.

video=1024x768 - all connectors match a 1024x768 mode or add a CVT on
video=VGA-1:1024x768, VGA-1 connector gets mode only.

The same strings as used in current fb modedb.c are used, except I've
added three more letters, e, D, d, e = enable, D = enable Digital,
d = disable, which allow a connector to be forced into a certain state.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_crtc.c |1 +
 drivers/gpu/drm/drm_crtc_helper.c  |   79 +-
 drivers/gpu/drm/drm_edid.c |6 +-
 drivers/gpu/drm/drm_fb_helper.c|  224 +++-
 drivers/gpu/drm/drm_modes.c|3 +-
 drivers/gpu/drm/i915/intel_fb.c|5 +-
 drivers/gpu/drm/radeon/radeon_connectors.c |   25 +++-
 drivers/gpu/drm/radeon/radeon_fb.c |   26 +++-
 include/drm/drm_crtc.h |   14 ++-
 include/drm/drm_fb_helper.h|   24 +++
 10 files changed, 386 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ba728ad..8e7b0eb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -482,6 +482,7 @@ void drm_connector_cleanup(struct drm_connector *connector)
list_for_each_entry_safe(mode, t, connector-user_modes, head)
drm_mode_remove(connector, mode);
 
+   kfree(connector-fb_helper_private);
mutex_lock(dev-mode_config.mutex);
drm_mode_object_put(dev, connector-base);
list_del(connector-head);
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index fe86974..82fd6e8 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -32,6 +32,7 @@
 #include drmP.h
 #include drm_crtc.h
 #include drm_crtc_helper.h
+#include drm_fb_helper.h
 
 static void drm_mode_validate_flag(struct drm_connector *connector,
   int flags)
@@ -90,7 +91,15 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
list_for_each_entry_safe(mode, t, connector-modes, head)
mode-status = MODE_UNVERIFIED;
 
-   connector-status = connector-funcs-detect(connector);
+   if (connector-force) {
+   if (connector-force == DRM_FORCE_ON)
+   connector-status = connector_status_connected;
+   else
+   connector-status = connector_status_disconnected;
+   if (connector-funcs-force)
+   connector-funcs-force(connector);
+   } else
+   connector-status = connector-funcs-detect(connector);
 
if (connector-status == connector_status_disconnected) {
DRM_DEBUG_KMS(%s is disconnected\n,
@@ -267,6 +276,56 @@ static struct drm_display_mode 
*drm_has_preferred_mode(struct drm_connector *con
return NULL;
 }
 
+static bool drm_has_cmdline_mode(struct drm_connector *connector)
+{
+   struct drm_fb_helper_connector *fb_help_conn = 
connector-fb_helper_private;
+   struct drm_fb_helper_cmdline_mode *cmdline_mode = 
fb_help_conn-cmdline_mode;
+   return cmdline_mode-specified;
+}
+
+static struct drm_display_mode *drm_pick_cmdline_mode(struct drm_connector 
*connector, int width, int height)
+{
+   struct drm_fb_helper_connector *fb_help_conn = 
connector-fb_helper_private;
+   struct drm_fb_helper_cmdline_mode *cmdline_mode = 
fb_help_conn-cmdline_mode;
+   struct drm_display_mode *mode = NULL;
+
+   if (cmdline_mode-specified == false)
+   return mode;
+
+   /* attempt to find a matching mode in the list of modes
+*  we have gotten so far, if not add a CVT mode that conforms
+*/
+   if (cmdline_mode-rb || cmdline_mode-margins)
+   goto create_mode;
+
+   list_for_each_entry(mode, connector-modes, head) {
+   /* check width/height */
+   if (mode-hdisplay != cmdline_mode-xres ||
+   mode-vdisplay != cmdline_mode-yres)
+   continue;
+
+   if (cmdline_mode-refresh_specified) {
+   if (mode-vrefresh != cmdline_mode-refresh)
+   continue;
+   }
+
+   if (cmdline_mode-interlace) {
+   if (!(mode-flags  DRM_MODE_FLAG_INTERLACE))
+

Re: [git pull] drm tree.

Re: [origin tree build failure] [PATCH] Re: [git pull] drm tree.

Re: [origin tree build failure] [PATCH] Re: [git pull] drm tree.

Re: [origin tree build failure] [PATCH] Re: [git pull] drm tree.

Re: [origin tree build failure] [PATCH] Re: [git pull] drm tree.

[Bug 24080] New: Darwinia crashes in rv670 when starting a level

Re: startx broken on today's git tree

[Bug 23965] radeonBackground objects appear in front of foreground ones in neverball

[Bug 23670] [bisected i915 i965] glean case pixelFormats failed

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

[PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

preventing GPU reset DoS

[Bug 22271] On 64bit kernel(drm-next-radeon) ioctls from 32bit application doesn't work

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

Re: preventing GPU reset DoS

Re: preventing GPU reset DoS

[Bug 24066] On the Rain-Slick Precipice of Darkness, Episode One crashes before first starting screen

Re: preventing GPU reset DoS

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

Re: preventing GPU reset DoS

Re: preventing GPU reset DoS

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

[Bug 23670] [bisected i915 i965] glean case pixelFormats failed

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

Re: [PATCH] Fix build on non GLIBC platforms (FreeBSD at least)

[git pull] two radeon fixes.

[PATCH] drm/kms: start adding command line interface using fb.

31 matches

Site Navigation

Mail list logo

Footer information