From owner-freebsd-current@FreeBSD.ORG Sun Jul 21 09:31:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C0EF243C for ; Sun, 21 Jul 2013 09:31:44 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 533CCE41 for ; Sun, 21 Jul 2013 09:31:43 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id r6L9Va1D019066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 21 Jul 2013 11:31:36 +0200 Received: from [192.168.1.110] (174.Red-79-153-75.dynamicIP.rima-tde.net [79.153.75.174]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id r6L9VYqZ016639 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 21 Jul 2013 11:31:36 +0200 Message-ID: <51EBAA76.8020100@entel.upc.edu> Date: Sun, 21 Jul 2013 11:31:34 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130322 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD current Subject: Re: Panic when starting X with Intel KMS References: <51E6EB0A.2060407@entel.upc.edu> <51EA5166.4020508@entel.upc.edu> <20130721071842.GZ5991@kib.kiev.ua> In-Reply-To: <20130721071842.GZ5991@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Sun, 21 Jul 2013 11:31:36 +0200 (CEST) Cc: Konstantin Belousov X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 21 Jul 2013 09:31:44 -0000 > The issue happened somewhere before the process exit. Try the patch > below, the idea is that your overflow count is really big, so the > wrong-doer could cause underflow when acting. > > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 19be4e0..fcdc6af 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -465,6 +465,9 @@ pmap_resident_count_dec(pmap_t pmap, int count) > { > > PMAP_LOCK_ASSERT(pmap, MA_OWNED); > + KASSERT(pmap->pm_stats.resident_count >= count, > + ("pmap %p resident count underflow %ld %d", pmap, > + pmap->pm_stats.resident_count, count)); > pmap->pm_stats.resident_count -= count; > } > Hi, the assert doesn't happen (that's resident_count is not bigger than count). You can find the complete core at: https://dl.dropboxusercontent.com/u/2094962/core.txt.5 I'm no expert on that, but would this mean that the process, while freeying mem, causes the kernel to free more maps than the process has? Any other info during the panic, let me know (I have a second machine and I can connect to it via serial port). OTOH, in puzzled because the stack gets corrupted an thus I can't check which is the offending process (I don't know if that would be of any use in this situation). It is my understanding that isn't the process who should be fixed but the kernel side. In this case the stack corruption isn't that very important (at least this is what I think), but sometimes it is very handy. -- Salut i força, Gustau --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Unitat de Gestió dels departaments O O O Matemàtica Aplicada IV i Enginyeria Telemàtica Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona