[Bug 20178] New: [Wine Application Issue]: The game 'Crazy Birds' performs very slow when '3D High Detail' is enabled in game options

http://bugs.freedesktop.org/show_bug.cgi?id=20178 Summary: [Wine Application Issue]: The game 'Crazy Birds' performs very slow when '3D High Detail' is enabled in game options Product: Mesa Version: 7.2 Platform: x8

[Bug 20178] [Wine Application Issue]: The game 'Crazy Birds' performs very slow when '3D High Detail' is enabled in game options

http://bugs.freedesktop.org/show_bug.cgi?id=20178 --- Comment #1 from Chandra 2009-02-18 00:05:36 PST --- Created an attachment (id=23070) --> (http://bugs.freedesktop.org/attachment.cgi?id=23070) glxinfo output Let me know if you need any more details for further debugging. -- Configu

[Bug 20178] [Wine Application Issue]: The game 'Crazy Birds' performs very slow when '3D High Detail' is enabled in game options

http://bugs.freedesktop.org/show_bug.cgi?id=20178 Sunil Mekathotti changed: What|Removed |Added CC||sbmekatho...@gmail.com Seve

Re: [PATCH] drm: Fix lock order reversal between mmap_sem and struct_mutex.

Eric Anholt said the following on 2009-2-18 8:59: > The basic problem was > mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap(), i915_gem_fault()) > struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user()) > > We have plenty of places where we want to hold device state the same > (s

drm: radeon: Fix unaligned access in r300_scratch().

drm: radeon: Fix unaligned access in r300_scratch(). In compat mode, the cmdbuf->buf 64-bit address cookie can potentially be only 32-bit aligned. Dereferencing this as 64-bit causes expensive unaligned traps on platforms like sparc64. Use get_unaligned() to fix. Signed-off-by: David S. Miller

[PATCH] drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.

Ben, I'm pretty sure you're hitting this too on powerpc. Every time a 32-bit process tries to upload cliprects it's going to fail with -EFAULT or similar. Nothing in userspace checks the return value for errors, etc. :-/ The only reason I caught this is because I have a debugging check on sparc

Re: [PATCH] drm: make drm_wait_vblank return immediately for very old sequence values

On Tue, 2009-02-17 at 16:10 -0800, Ian Romanick wrote: > Are vblanks | Is anyone | > happening? | listening? | What to do? > > YesYes Update MSC based on vblank interrupts > YesNoDisable IRQ, estimate MSC next time >someone li

[Bug 20184] New: [Wine]: Using Alt+Tab while running the wine application ' Fairy Puzzle' hangs the display

http://bugs.freedesktop.org/show_bug.cgi?id=20184 Summary: [Wine]: Using Alt+Tab while running the wine application 'Fairy Puzzle' hangs the display Product: Mesa Version: 7.2 Platform: Other OS/Version: other Statu

[Bug 20184] [Wine]: Using Alt+Tab while running the wine application ' Fairy Puzzle' hangs the display

http://bugs.freedesktop.org/show_bug.cgi?id=20184 --- Comment #1 from Sunil Mekathotti 2009-02-18 02:16:27 PST --- Created an attachment (id=23074) --> (http://bugs.freedesktop.org/attachment.cgi?id=23074) screen-shot -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=e

[Bug 20184] [Wine]: Using Alt+Tab while running the wine application ' Fairy Puzzle' hangs the display

http://bugs.freedesktop.org/show_bug.cgi?id=20184 --- Comment #2 from Michel Dänzer 2009-02-18 02:59:01 PST --- If Ctrl-Alt-Backspace works and the following X server works normally, it's probably stuck in a software loop. While it's hung, can you try logging in remotely, see if any process

r200 lockup in radeon_cp_texture/radeon_freelist_get

Hi! I have Radeon8500LE 128MB AGP successfully running under Fedora Rawhide and DRI is working, but I tried Doom3 and it freezes at loading screen. I understand that priorities may have shifted to get R5xx-R7xx cards into 3D, but until new DRI/DRM bits arrives, this issue probably affects all r

Re: r200 lockup in radeon_cp_texture/radeon_freelist_get

On 18.02.2009 13:19, Arkadi Shishlov wrote: > Hi! > I have Radeon8500LE 128MB AGP successfully running under Fedora Rawhide and > DRI is working, but I > tried Doom3 and it freezes at loading screen. > I understand that priorities may have shifted to get R5xx-R7xx cards into 3D, > but until new

[PATCH] drm: Take mmap_sem up front to avoid lock order violations.

From: Kristian Høgsberg A number of GEM operations (and legacy drm ones) want to copy data to or from userspace while holding the struct_mutex lock. However, the fault handler calls us with the mmap_sem held and thus enforces the opposite locking order. This patch downs the mmap_sem up front fo

Re: [PATCH] drm: Fix lock order reversal between mmap_sem and struct_mutex.

On Tue, 2009-02-17 at 16:59 -0800, Eric Anholt wrote: > The basic problem was > mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap(), i915_gem_fault()) > struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user()) That's not the only problem, there's also: dup_mmap() down_write(mmap_

[PATCH] drm: Take mmap_sem up front to avoid lock order violations.

From: Kristian Høgsberg A number of GEM operations (and legacy drm ones) want to copy data to or from userspace while holding the struct_mutex lock. However, the fault handler calls us with the mmap_sem held and thus enforces the opposite locking order. This patch downs the mmap_sem up front fo

[Bug 19763] ATI X1950Pro (R500). 3D Textures don't work

http://bugs.freedesktop.org/show_bug.cgi?id=19763 --- Comment #1 from Aditya Kadambi 2009-02-18 08:45:16 PST --- Bump! can some developer respond to this?!! -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You

[RFC] maximum object size in memory allocation

Hi, Lately i have been thinking to the memory allocation problem and i believe that we should fix a maximum limit for BO size we allocate. This limit should be decided by the kernel (i am assuming to be in a KMS world). Here is a small list of argument in favor of such idea : - GPU have

Re: [PATCH] drm: Take mmap_sem up front to avoid lock order violations.

On Wed, 2009-02-18 at 11:02 -0500, k...@bitplanet.net wrote: > From: Kristian Høgsberg > > A number of GEM operations (and legacy drm ones) want to copy data to > or from userspace while holding the struct_mutex lock. However, the > fault handler calls us with the mmap_sem held and thus enforces

Re: [PATCH] drm: make drm_wait_vblank return immediately for very old sequence values

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xavier Bestel wrote: > On Tue, 2009-02-17 at 16:10 -0800, Ian Romanick wrote: >> Are vblanks | Is anyone | >> happening? | listening? | What to do? >> >> YesYes Update MSC based on vblank interrupts >> YesNoD

Re: [PATCH] drm: Take mmap_sem up front to avoid lock order violations.

On Wed, Feb 18, 2009 at 12:36 PM, Eric Anholt wrote: > On Wed, 2009-02-18 at 11:02 -0500, k...@bitplanet.net wrote: >> From: Kristian Høgsberg >> >> A number of GEM operations (and legacy drm ones) want to copy data to >> or from userspace while holding the struct_mutex lock. However, the >> fau

[Bug 19876] 3D acceleration not working on i945GM

http://bugs.freedesktop.org/show_bug.cgi?id=19876 --- Comment #2 from Eric Anholt 2009-02-18 12:58:23 PST --- All the usual information is required (dmesg, Xorg.0.log). When did it start happening? Can you bisect? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 Eric Anholt changed: What|Removed |Added Attachment #22775|application/octet-stream|text/plain mime type|

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 Eric Anholt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 Sven changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 --- Comment #7 from Eric Anholt 2009-02-18 13:18:16 PST --- Sorry, I went from the only dmesg posted, which (if you're right) is someone with a different problem: [ 21.679826] [drm] Initialized i915 1.13.0 20080312 on minor 0 [ 21.679845

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 Eric Anholt changed: What|Removed |Added Attachment #22775|0 |1 is obsolete|

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 Eric Anholt changed: What|Removed |Added Attachment #22776|0 |1 is obsolete|

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 --- Comment #8 from Sven 2009-02-18 13:20:12 PST --- Created an attachment (id=23085) --> (http://bugs.freedesktop.org/attachment.cgi?id=23085) sven's dmesg -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ---

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 --- Comment #9 from Sven 2009-02-18 13:20:37 PST --- Created an attachment (id=23086) --> (http://bugs.freedesktop.org/attachment.cgi?id=23086) sven's Xorg.0.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --

Re: [PATCH] drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.

From: Benjamin Herrenschmidt Date: Thu, 19 Feb 2009 08:59:50 +1100 > Could that be related to the kernel spewing a bunch of > > [drm:drm_update_drawable_info] *ERROR* Failed to copy cliprects from userspace Yep, that is exactly caused by this bug. --

Re: [PATCH] drm: Take mmap_sem up front to avoid lock order violations.

On Wed, Feb 18, 2009 at 5:42 PM, Thomas Hellström wrote: > Kristian Høgsberg wrote: >> >> On Wed, Feb 18, 2009 at 12:36 PM, Eric Anholt wrote: >> >>> >>> On Wed, 2009-02-18 at 11:02 -0500, k...@bitplanet.net wrote: >>> From: Kristian Høgsberg A number of GEM operations (and l

Re: [PATCH] drm: Take mmap_sem up front to avoid lock order violations.

Kristian Høgsberg wrote: > On Wed, Feb 18, 2009 at 12:36 PM, Eric Anholt wrote: > >> On Wed, 2009-02-18 at 11:02 -0500, k...@bitplanet.net wrote: >> >>> From: Kristian Høgsberg >>> >>> A number of GEM operations (and legacy drm ones) want to copy data to >>> or from userspace while holdin

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 --- Comment #10 from Eric Anholt 2009-02-18 13:41:58 PST --- Your dmesg is truncated. Are you using PAE maybe? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: ---

Re: [PATCH] drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.

On Wed, 2009-02-18 at 01:35 -0800, David Miller wrote: > Ben, I'm pretty sure you're hitting this too on powerpc. Every time a > 32-bit process tries to upload cliprects it's going to fail with > -EFAULT or similar. Heh, quite possibly Could that be related to the kernel spewing a bunch of [drm

[PATCH] drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings.

Ok, this is the last DRM bug I am aware of with Radeon on sparc64. What kills me is that I fixed this bug 6 or 7 years ago :) drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings. Platforms such as sparc64 have D-cache aliasing issues. We cannot allow virtual mappi

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 Sven changed: What|Removed |Added Attachment #23085|0 |1 is obsolete|

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 --- Comment #11 from Sven 2009-02-18 13:57:44 PST --- (In reply to comment #10) > Your dmesg is truncated. Are you using PAE maybe? I will try to upload a new dmesg taken from /var/log/messages. Yes, I am using PAE. -- Configure bugmail

[Bug 19739] Failed to initialize GEM. Falling back to classic.

http://bugs.freedesktop.org/show_bug.cgi?id=19739 Gordon Jin changed: What|Removed |Added AssignedTo|dri-|e...@anholt.net |de...@li

Re: [PATCH] drm: Take mmap_sem up front to avoid lock order violations.

k...@bitplanet.net said the following on 2009-2-19 0:02: > From: Kristian Høgsberg > > A number of GEM operations (and legacy drm ones) want to copy data to > or from userspace while holding the struct_mutex lock. However, the > fault handler calls us with the mmap_sem held and thus enforces the

Re: [PATCH] drm: Take mmap_sem up front to avoid lock order violations.

Kristian Høgsberg wrote: > > > In this case, I guess the fault handler is always only called with > mmap_sem held in read mode, and then yes, there's no deadlock and the > warning is harmless. That doesn't mean that it's a good idea - > enforcing a consistent lock order is good practice that keeps