From owner-freebsd-x11@FreeBSD.ORG Fri Sep 9 22:10:59 2011 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB4F21065673 for ; Fri, 9 Sep 2011 22:10:58 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 781278FC1B for ; Fri, 9 Sep 2011 22:10:57 +0000 (UTC) Received: by fxe4 with SMTP id 4so3941085fxe.13 for ; Fri, 09 Sep 2011 15:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=thk/wOmckr3untDKxpVLVBoDYPHVb1ia6GfwEECtqKg=; b=PD3TAGfk/6x+1O4SNMslyVnKxq9IPMuhJzwq/oUJ7r07m+C9aExUasdigyjf8CTchb +fEzJA+DqpjgwvnxU20bzzVcXJgYMtw38px9APRYbjG2EPufnOmP0WRr8jSgU6wPF3aT BbMdiCEEj28bCmzJNvxwLgrXE+hRE8HUzwgGQ= Received: by 10.223.33.19 with SMTP id f19mr298682fad.122.1315606257270; Fri, 09 Sep 2011 15:10:57 -0700 (PDT) Received: from beastie.intra ([195.60.174.66]) by mx.google.com with ESMTPS id h22sm3494487fag.15.2011.09.09.15.10.53 (version=SSLv3 cipher=OTHER); Fri, 09 Sep 2011 15:10:54 -0700 (PDT) Message-ID: <4E6A8EC2.8050305@gmail.com> Date: Sat, 10 Sep 2011 01:10:10 +0300 From: Andrey Kosachenko User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110813 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-x11@freebsd.org References: <4E543828.2040703@gmail.com> <20110824081303.GG17489@deviant.kiev.zoral.com.ua> <4E61DF8F.1090206@gmail.com> <20110903082645.GR17489@deviant.kiev.zoral.com.ua> <20110903104701.GY17489@deviant.kiev.zoral.com.ua> <4E63983C.6000702@gmail.com> <20110904154615.GH17489@deviant.kiev.zoral.com.ua> <4E63B680.2060504@gmail.com> <20110904174333.GL17489@deviant.kiev.zoral.com.ua> <4E690971.8080208@gmail.com> <20110908233844.GT17489@deviant.kiev.zoral.com.ua> In-Reply-To: <20110908233844.GT17489@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: xorg-dev + intel driver + KMS X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 22:10:59 -0000 Hi, Konstantin, On 09.09.2011 02:38, Kostik Belousov wrote: > 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. great! I confirm that with all.9.1.patch system remains stable even under high memory pressure. I tried your test (thanks, it is actually exactly what I had been looking for quite a long time: i.e. exact STR of the issue). Running "gem_stress" and "sort /dev/zero" in parallel turned my system into unusable state within less then 10 seconds. Repeated test 3 times in a row. The outcome was the same in all cases: X server hanged (reset was the only way out to get machine operational). After applying all.9.1.patch I ran the same test again and system remained stable and even pretty responsive. Both (gem_stress and sort /dev/zero) were running for a while and after a couple of minutes sort process was killed by system (with "out of swap space" error). Will keep an eye on it so should I notice more issues will let you know. Thanks! I really appreciate it! -- WBR, Andrey Kosachenko