Re: [Mesa-dev] KWin and Mesa
On 04/20/2011 01:00 PM, Kenneth Graunke wrote: > Please do let us know about any issues you come across. (If you can work > around them, you can report them...) Even just a ping saying "Someone > told me KWin was broken on " is helpful. We have the > hardware and can always try to reproduce the problem, even if you aren't > able to. https://bugs.freedesktop.org/show_bug.cgi?id=32534 https://bugs.kde.org/show_bug.cgi?id=252817 https://bugzilla.redhat.com/show_bug.cgi?id=691084 -- ============ Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] KWin and Mesa
On 04/22/2011 11:11 PM, Mario Kleiner wrote: > At least the visual corruption with compositing that is described in > these reports matches this bug very well: > > <https://bugs.freedesktop.org/show_bug.cgi?id=35452> > > The bug is in the DRI2 implementation of the x-server and should affect > any compositor when kms page flipping is enabled. x-servers 1.8, 1.9, > (afaik) 1.10 x-server's would be affected. If you follow this thread > <http://lists.x.org/archives/xorg-devel/2011-March/020716.html> it > points to a proposed patch by Michel Daenzer, and a refined version by > Keith Packard. I don't know if a version has landed in master already, > but testing it would help to get it there and maybe to get it merged to > 1.9 and 1.10. Results of initial testing are positive. Thank you! Rather disappointing to read the discussion on xorg-devel. (Talk about "making the perfect the enemy of the good!") I have posted my results there; perhaps that will get things moving. Thanks! -- ============ Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] KWin and Mesa
On 04/25/2011 08:38 AM, Solerman Kaplon wrote: > Em 23-04-2011 01:11, Mario Kleiner escreveu: >> At least the visual corruption with compositing that is described in >> these reports matches this bug very well: >> >> <https://bugs.freedesktop.org/show_bug.cgi?id=35452> > > This affects other driver's too, right? Shouldn't the component gets > changed in the bug report? (still re-reading the whole thread) It definitely affects at least intel and radeon, and the fix is in the X server, so that makes sense. -- ======== Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] NULL in dri_drawable.textures borking glDrawArrays
I spent some time today looking into a KWin crash I've been experiencing when I unlock an OpenGL screensaver. I was able to track it down to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=33036 Sure enough, applying the patch in that bug got rid of the crash. Unfortunately, I'm now seeing really problematic behavior when I test an OpenGL screen saver in the KDE "Display and Monitor" applet. Based on the stack trace from the crash, I've tried to figure out what's going on, but I'm unable to connect all the dots. Here's the relevant subset of the stack from the (now fixed) crash: #6 radeon_r300_winsys_buffer_from_handle (rws=, whandle=0x7fff73559780, stride=0x7fff73559698, size=0x7fff7355969c) at radeon_r300.c:122 #7 0x7fb1e84f93d6 in r300_texture_from_handle (screen=0x10336a0, base=0x7fff73559740, whandle=) at r300_texture.c:828 #8 0x7fb1e84e94f3 in dri2_drawable_process_buffers (count=1, buffers=0x104f748, drawable=0x104d820) at dri2.c:252 #9 dri2_allocate_textures (drawable=0x104d820, statts=, count=1934989244) at dri2.c:276 #10 0x7fb1e84ea187 in dri_st_framebuffer_validate (stfbi=, statts=0x12e8650, count=1, out=0x7fff73559860) at dri_drawable.c:73 #11 0x7fb1e8528617 in st_framebuffer_validate (stfb=0x12e8200, st=0x1112c70) at state_tracker/st_manager.c:156 #12 0x7fb1e8529afe in st_manager_validate_framebuffers (st=0x1112c70) at state_tracker/st_manager.c:859 #13 0x7fb1e865a848 in st_validate_state (st=0x1112c70) at state_tracker/st_atom.c:143 #14 0x7fb1e85bde98 in st_draw_vbo (ctx=0x10e47c0, arrays=0x11164a0, prims=0x7fff73559f90, nr_prims=1, ib=0x0, index_bounds_valid=, min_index=0, max_index=11) at state_tracker/st_draw.c:649 #15 0x7fb1e85babf3 in vbo_draw_arrays (ctx=0x10e47c0, mode=7, start=0, count=, numInstances=1) at vbo/vbo_exec_array.c:588 #16 0x00397581cffe in KWin::renderGLGeometry (region=..., count=12, vertices=0x130ffa0, texture=0x1318f40, color=0x0, dim=2, stride=0) at /usr/src/debug/kdebase-workspace-4.6.0/kwin/lib/kwinglutils.cpp:185 What I've been able to figure out is that KWin is calling glDrawArrays, which is really vbo_draw_arrays. (I assume that glDrawArrays is really a macro or inline function.) This makes it all the way "down" to radeon_r300_winsys_buffer_from_handle, which calls radeon_drm_bufmgr_create_buffer_from_handle. radeon_drm_bufmgr_create_buffer_from_handle returns NULL. This used to cause a crash, but the NULL is now returned by radeon_r300_winsys_buffer_from_handle. In turn, r300_texture_from_handle returns NULL to dri2_drawable_process_buffers, which puts that NULL into the textures array of its drawable parameter. As I said above, I'm unable to trace the impact of this NULL value back up the call stack to vbo_draw_arrays. Maybe it's OK for the NULL to be there and maybe it's not. (The fact that glDrawArrays doesn't appear to have a way to report this sort of situation tends to make me believe that it should be handled somehow.) Any pointers are appreciated. Thanks! -- ======== Ian Pilcher arequip...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Sandy Bridge heisenbug
With latest batch of Fedora 15 test updates, I get GPU hangs very shortly after logging in (with KDE desktop effects enabled). Unfortunately, the hangs do not occur if I boot with drm.debug=14. Any ideas on how I can gather more information? Thanks! -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Sandy Bridge heisenbug
On 03/31/2011 02:53 PM, Chris Wilson wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=35820 perhaps? I don't think so. My system doesn't hang, and I don't get any X crash, just messages in the syslog (see below). I'm not expecting a quick fix. Just hoping for some ideas on gathering the necessary information to debug the problem. Thanks! Mar 30 20:47:16 ian kernel: [ 233.620717] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 30 20:47:16 ian kernel: [ 233.620730] [drm:kick_ring] *ERROR* Kicking stuck semaphore on blt ring Mar 30 20:47:18 ian kernel: [ 235.121821] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 30 20:47:18 ian kernel: [ 235.121834] [drm:kick_ring] *ERROR* Kicking stuck semaphore on blt ring Mar 30 20:47:19 ian kernel: [ 236.622925] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 30 20:47:19 ian kernel: [ 236.622937] [drm:kick_ring] *ERROR* Kicking stuck semaphore on blt ring Mar 30 20:47:21 ian kernel: [ 238.124022] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 30 20:47:21 ian kernel: [ 238.124034] [drm:kick_ring] *ERROR* Kicking stuck semaphore on blt ring Mar 30 20:47:22 ian kernel: [ 239.625122] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 30 20:47:22 ian kernel: [ 239.625133] [drm:kick_ring] *ERROR* Kicking stuck semaphore on blt ring Mar 30 20:47:24 ian kernel: [ 241.126214] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 30 20:47:24 ian kernel: [ 241.126226] [drm:kick_ring] *ERROR* Kicking stuck semaphore on blt ring Mar 30 20:47:25 ian kernel: [ 242.627316] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 30 20:47:25 ian kernel: [ 242.627328] [drm:kick_ring] *ERROR* Kicking stuck semaphore on blt ring Mar 30 20:47:27 ian kernel: [ 244.128421] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Mar 30 20:47:27 ian kernel: [ 244.128433] [drm:kick_ring] *ERROR* Kicking stuck semaphore on blt ring (Bugzilla'ed at https://bugzilla.redhat.com/show_bug.cgi?id=692334.) -- ======== Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Sandy Bridge heisenbug
On 03/31/2011 04:05 PM, Chris Wilson wrote: > On Thu, 31 Mar 2011 15:01:53 -0500, Ian Pilcher wrote: >> >> Mar 30 20:47:16 ian kernel: [ 233.620717] [drm:i915_hangcheck_elapsed] >> *ERROR* >> Hangcheck timer elapsed... GPU hung > > Ah. You will want > > kernel commit 91355834646328e7edc6bd25176ae44bcd7386c7 Unfortunately, that patch appears to already be in the latest Fedora kernel, kernel-2.6.38.2-9.fc15.x86_64, and I still get the hangs with the latest Mesa packages. (No hangs with 7.10, though.) -- ============ Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Sandy Bridge heisenbug
On 03/31/2011 05:20 PM, Chris Wilson wrote: > However, if you are reasonably confident that a change in mesa provokes > the issue, you can bisect the commit in question. That may give another > clue as to where to look next. I'm willing to take a shot. Got a link to a good HOWTO? (My experience with git is very limited.) Also, with the latest Fedora kernel I now see the problem even with drm.debug=14. dmesg is at https://bugzilla.redhat.com/show_bug.cgi?id=692334. Thanks! -- ============ Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Sandy Bridge heisenbug
On 04/01/2011 02:09 AM, Dave Airlie wrote: > > try the latest mesa in koji, > > I' ve pushed some reverts in, > > https://bugs.freedesktop.org/show_bug.cgi?id=35853 > > is upstream bug. > That appears to have made things worse. With mesa-dri-drivers-7.11-0.3.20110330.0.fc15.x86_64 I get: Apr 1 11:38:18 ian kernel: [ 77.890422] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Apr 1 11:38:18 ian kernel: [ 77.892175] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 4284 at 4281, next 4285) Apr 1 11:38:25 ian kernel: [ 84.254124] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Apr 1 11:38:25 ian kernel: [ 84.254161] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 4529 at 4525, next 4530) Apr 1 11:38:31 ian kernel: [ 90.585892] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Apr 1 11:38:31 ian kernel: [ 90.585925] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 4664 at 4661, next 4666) And then KWin disables desktop effects. With mesa-dri-drivers-7.11-0.5.20110401.0.fc15.x86_64 I get fewer error messages: Apr 1 11:33:52 ian kernel: [ 272.178080] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Apr 1 11:33:52 ian kernel: [ 272.179796] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 10986 at 10979, next 11027) Apr 1 11:33:59 ian kernel: [ 278.725439] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung Apr 1 11:33:59 ian kernel: [ 278.725481] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -11 (awaiting 11895 at 11862, next 11896) But KWin never recovers. I can see gkrellm chugging along, but I'm unable do actually do anything in X. (Note, however, that the system is still OK. I can ssh in, downgrade the mesa packages, restart X, and be up and running.) Looks like I will be bisecting ... -- ======== Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Sandy Bridge heisenbug
Well, I've had to give up on bisecting. It turns out that I really don't have a clear definition of working/broken that can be reliably tested. With some snapshots, I get problems as soon as I log in. With others, a few clicks does it. In other cases, the GPU only hangs after I've done a bunch of "desktop cube" switches. Etc., etc. Even with 7.10, which I had believed to be solid, I can easily produce a GPU hang by moving a glxgears window. :-( -- ======== Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] GEM object creation ioctl?
I am continuing to dig into my GLMatrix-induced X crash. It appears to
be a GEM object lifecycle problem (DRM_IOCTL_GEM_OPEN returning
ENOENT). I've added a bunch of logging to drmIoctl to try figure out
what is going on, but I haven't been able to figure out how objects are
created.
http://lwn.net/Articles/283798/ mentions a DRM_IOCTL_GEM_CREATE ioctl,
but it doesn't appear to actually exist on my system. Because of this,
I'm currently logging DRM_IOCTL_GEM_{CLOSE,FLINK,OPEN}, but I'm unable
to actually see objects being created.
What should I be looking for?
Thanks!
--
========
Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] GEM object creation ioctl?
On 04/18/2011 02:09 PM, Ian Pilcher wrote:
> http://lwn.net/Articles/283798/ mentions a DRM_IOCTL_GEM_CREATE ioctl,
> but it doesn't appear to actually exist on my system. Because of this,
> I'm currently logging DRM_IOCTL_GEM_{CLOSE,FLINK,OPEN}, but I'm unable
> to actually see objects being created.
Amazing how writing a question concentrates the mind. It looks like
DRM_IOCTL_I915_GEM_CREATE is what I'm looking for. Are there any other
ioctls that I should be logging?
Thanks!
--
========
Ian Pilcher arequip...@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] How report error to application?
Following up on my earlier GEM object lifecycle question, it looks my problem is probably a combination of a race condition in KDE and the fact that Mesa is currently swallowing memory allocation and GEM ioctl errors (creating region-less intel_renderbuffers which ultimately cause segfaults). The obvious next step is to patch Mesa to report the error back to the application. How is this done? Thanks! -- Ian Pilcher arequip...@gmail.com "If you're going to shift my paradigm ... at least buy me dinner first." ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
