xorg-dev + intel driver + KMS

[Kostik Belousov]

On Thu, Sep 08, 2011 at 09:29:05PM +0300, Andrey Kosachenko wrote:
> Hi, Konstantin,
> 
> On 04.09.2011 20:43, Kostik Belousov wrote:
> >On Sun, Sep 04, 2011 at 08:33:52PM +0300, Andrey Kosachenko wrote:
> >>On 04.09.2011 18:46, Kostik Belousov wrote:
> >>>Show me the output of procstat -kk<Xorg pid>   and ps axlww.
> >>
> >>I believe you are interested in those listing in the context of the
> >>hanged Xorg, right?. If so, then I've to wait for the next issue
> >>occurrence and will provide outputs then.
> >Right.
> 
> here you go:
> http://pastebin.com/7mH62WBn
> 
> PS:
> - unfortunately this was checked against all.8.3.patch (haven't had time 
> to employ all.9.0.patch);
> - if you need ktrdump, please, let me know I'll send it to you.

If you are not interested in the story, just try 9.1 patch.

If you are, please stay with me. Apparently, your pagedaemon is sleeping
in 915unm state, that made me very much worrying. I did not understand
how this could happen, because I thought that this is caused by
pagedaemon dropping the last reference on the gem object device pager.
And pagedaemon must not see pages belonging to device pagers, the pages
must not appear on any queue.

I added assertions to make sure to get the panic if a fictitious page
is found on queues, which did not fired. But, I was able to reproduce
the situation with pagedaemon hang, by running gem_stress and performing
active swapping in parallel. I forgot that I finally implemented the low
memory handler for gem, which is called from pagedaemon and which also
does purging on the gem buffers.

After that, it was relatively easy to track the issue. See the comment
at the beginning of i915_gem_pager_fault() about interaction with
i915_gem_release_mmap() which describes the cause of the hang:

	/*
	 * Remove the placeholder page inserted by vm_fault() from the
	 * object before dropping the object lock. If
	 * i915_gem_release_mmap() is active in parallel on this gem
	 * object, then it owns the drm device sx and might find the
	 * placeholder already. Then, since the page is busy,
	 * i915_gem_release_mmap() sleeps waiting for the busy state
	 * of the page cleared. We will be not able to acquire drm
	 * device lock until i915_gem_release_mmap() is able to make a
	 * progress.
	 */

For me, the patched driver survived while doing 'sort /dev/zero' and
gem_stress in parallel.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-x11/attachments/20110908/059f7cca/attachment.pgp