From owner-freebsd-current@freebsd.org Fri Jan 6 17:48:46 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 778FBCA26AE for ; Fri, 6 Jan 2017 17:48:46 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from vps-mail.nomadlogic.org (unknown [IPv6:2607:f2f8:a098::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6002F1DB4 for ; Fri, 6 Jan 2017 17:48:46 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from LA-DGT-31327.local (nat-192-187-90-113.nat.tribpub.com [192.187.90.113]) by vps-mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id bdefb843 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Fri, 6 Jan 2017 09:48:44 -0800 (PST) Subject: Re: PQ_LAUNDRY: unexpected behaviour To: freebsd-current@freebsd.org References: <1596d0f6d6d.1266583c3319360.3590554896761456790@nextbsd.org> <74A6C6D0-90A4-4DB2-8D89-5D2B1E495F88@FreeBSD.org> <15974c6426d.12945df5e62589.5931208946643250381@nextbsd.org> From: Pete Wright Message-ID: <1779f83b-687d-ac6f-587f-90bdc6d61c20@nomadlogic.org> Date: Fri, 6 Jan 2017 09:48:43 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <15974c6426d.12945df5e62589.5931208946643250381@nextbsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:48:46 -0000 On 1/6/17 9:14 AM, Matthew Macy wrote: > > > > Please try the drm-next branch now. Up until very recently, the > > > shrinkers responsible for culling ttm/gem allocations were never run. > > > I've now implemented the shrinker, but it's driven from vm_lowmem, so > > > you'll probably still see what looks like a leak until you hit low > > > memory conditions. The shrinker should probably be run from > > > uma_timeout, but there isn't an eventhandler for that and I haven't > > > looked any further. > > > > > > -M > > > > Hi, > > > > I am now testing the `drm-next` branch, but I'm finding it crashes much > > more frequently (a la > > https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than > > `drm-next-4.7`. While the 4.7 branch would sometimes only last a few > > minutes, it would sometimes run for a day or more. On `drm-next`, > > however, I think I'm yet to have 20 minutes of uptime. So, I haven't run > > into the memory shrinker yet because I haven't had enough uptime to use > > lots of memory. :) I will continue testing... any specific things I > > ought to be doing? > > > > > > I just did the merge and it's using a relatively untested new KPI so regressions aren't too surprising I'm afraid. #96 is more or less content free in terms of providing useful information. Getting a core + backtrace would be a lot more helpful. See the repo's wiki for details on improving your odds of getting a core. > I have found the following has enabled me to catch kernel panic's pretty reliably on the drm-next branch when i have the i915kms module loaded: dev.drm.skip_ddb=1 -pete -- Pete Wright pete@nomadlogic.org nomadlogicLA