From owner-freebsd-current@freebsd.org Tue May 3 23:51:51 2016 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 06E04B2CE15; Tue, 3 May 2016 23:51:51 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C91FD1196; Tue, 3 May 2016 23:51:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-pa0-x233.google.com with SMTP id xk12so16626878pac.0; Tue, 03 May 2016 16:51:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=z9iqTq74JjDoS7Mn0Oo/C5o8GndD+qh/Rg05tWKWAtw=; b=txnBi/kzJ3zRReROp97fVX02V01P0kXn9K6Ll6wMB+5P/qrMUpOjzgh8L29QwmotFY Cq7AvO9Y2lyWusm2V1gTe7AANz+VYpwk3D/+PBCh5yHpiFrr/+fIFZqT9vJEJcvy9TLo P4V+iq/3Jzpq7Ye1zSLunCHSMO147M3QkI0RhziD1Vl0yZtVq8USYAcqp14K7v1n7uxB 1EQAUcdDX6L0ELY9Vu/A+JSG6fMBnBDwQG+t2N9vhrd9htP+jlprGpazNuZDuIyiKyJ3 h/aaJ4piixfO4yOIr2jR6iwctbMc+68cShpCfwhsnttOzj8W/8e/Wk3U65iztdmMygjk JNVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=z9iqTq74JjDoS7Mn0Oo/C5o8GndD+qh/Rg05tWKWAtw=; b=kLWrCaCGigbYpVKThM1zfOrWog2rjODbIa5XLL/h5e5TThRGqI4e1ex/oncW1sI2iV zJ37ahNHf+hH1k7IFV6di4Wm3K5kHYrDPPPDUjxp9SAgMrihpAIOpcMjQhM9tQVkdrhI c1gxJSXkHIex7Z5eWyd+rW/sxpuv33D6FkZtUVrAdCUO/qhtbjVGOQM/dYQGD7Yc7Bxn VVtAWMhlL+g+wst4QXBKntFCoLMqFaV8tOXQGM/tJYznKnnXUx5whP8fdFdVFHbI8oc9 tVhmS93SvK1L1wGzViItkP6gWdwxOXimJK7hSBKBcOuw2ipkcL93XBPIlFVNRx4KbzOu Qpvw== X-Gm-Message-State: AOPr4FXL9fvtPzlL306PbU88BvcET2gId5yw6lKvSNu9VLGcyxVmKCH9+6gm3KnbKkjGsA== X-Received: by 10.66.79.197 with SMTP id l5mr7697431pax.61.1462319510207; Tue, 03 May 2016 16:51:50 -0700 (PDT) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id u2sm783463pfi.26.2016.05.03.16.51.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 May 2016 16:51:49 -0700 (PDT) Sender: Mark Johnston Date: Tue, 3 May 2016 16:55:29 -0700 From: Mark Johnston To: Trond =?iso-8859-1?Q?Endrest=F8l?= Cc: Scott Long , Steve Wills , FreeBSD PowerPC ML , freebsd-current@freebsd.org, scottl@FreeBSD.org, Warner Losh Subject: Re: wired memory leak at r298785 Message-ID: <20160503235529.GA44671@wkstn-mjohnston.west.isilon.com> References: <572756DF.1010809@FreeBSD.org> <5727F71E.20101@FreeBSD.org> <20160503062031.GA2209@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 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: Tue, 03 May 2016 23:51:51 -0000 On Tue, May 03, 2016 at 08:20:46PM +0200, Trond Endrestøl wrote: > On Tue, 3 May 2016 08:27-0600, Scott Long wrote: > > > On May 3, 2016, at 12:20 AM, Mark Johnston wrote: > > > This was causing problems on one of my amd64 systems, so it's not > > > specific to powerpc64. It turns out to be due to r298004: the CCB > > > allocated in cam_periph_devctl_notify() never gets freed. The patch > > > below seems to fix it. > > > > Thanks Mark, that looks like the right fix. I’ll put it in today. > > > > Scott > > A few of my stable/10 systems simple froze due to this bug. Would it > be possible for the kernel to detect when it's running low on (kernel) > memory, or when it's completely out of (kernel) memory, and call on > panic() only to limp away for a day or so before rebooting again? I don't know of a mechanism in the kernel that would let you do this. The closest thing I can think of would be a cron job that periodically checks the amount of leaked memory with vmstat -m | awk '/CAM CCB/{print $(NF - 3)}' and triggers a reboot once that value rises above some threshold.