From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 08:58:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14DE116A41F for ; Wed, 9 Nov 2005 08:58:38 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC90243D45 for ; Wed, 9 Nov 2005 08:58:34 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000028737.msg for ; Wed, 09 Nov 2005 14:58:26 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 126749, updated: 7.11.2005] To: freebsd-current@freebsd.org References: <200511082313.jA8NDbft005916@casselton.net> From: Victor Snezhko Date: Wed, 09 Nov 2005 14:58:21 +0600 In-Reply-To: <200511082313.jA8NDbft005916@casselton.net> (Mark Tinguely's message of "Tue, 8 Nov 2005 17:13:37 -0600 (CST)") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Wed, 09 Nov 2005 14:58:26 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-VVS-Spam: false Subject: Re: CURRENT + amd64 + user-ppp = panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 09 Nov 2005 08:58:38 -0000 Mark Tinguely writes: > before too much work is done (below), could you print out the callout > that is being freed but active and the memory around it (before it > is overwritten by "deadc0de"). It may tell us which callout that it > is or was. I would be happy to do so but as I have just said, I call not the callout that is freed but the other one already filled with uma_trash... If I'm mistaken, please correct me. > If we cannot glean who the callout is/was, then more tests can be > added to determine if the UMA is allocating memory chained to the callout > or if the MBUF chain is corrupted. Sorry, I'm not familiar enough with UMA/mbufs (at the moment) to make such tests myself. With callouts it was simple - I watched into kern_timeout.c and read timeout(9) manpage. Now I'm reading appropriate manpages but it'l take me a while before I grasp all the dependencies. And reading manpages, I guess, won't be enough. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru