From owner-freebsd-current@FreeBSD.ORG Wed Nov 9 16:33:08 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 D546E16A41F for ; Wed, 9 Nov 2005 16:33:08 +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 04E2E43D45 for ; Wed, 9 Nov 2005 16:33:07 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000028833.msg for ; Wed, 09 Nov 2005 22:33:00 +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: <200511091358.jA9DwiC0045661@casselton.net> From: Victor Snezhko Date: Wed, 09 Nov 2005 22:32:56 +0600 In-Reply-To: <200511091358.jA9DwiC0045661@casselton.net> (Mark Tinguely's message of "Wed, 9 Nov 2005 07:58:44 -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 22:33:00 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-VVS-Spam: false Cc: Mark Tinguely 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 16:33:08 -0000 Mark Tinguely writes: > I also was not thinking MBUF when I suggested trace locations. m_sanity() > in kern/uipc_mbuf.c will also set "0xdeadc0de" if the "sanitize" > option is requested. Now I have a current of 2005.10.21.16.25.00, and there is no deadcode there. Only a comment stating that deadc0de'ing would be not bad. > But common sense says that your trash_dtor() > code should catch this before it gets set, but if you wish to test > there also it would put my mind at ease. Sure. I have already submitted a PR(kern/88725) with all the results I have so far, and when I find all the other places I'll make a followup to it. > In the mean time, I will look for callouts that are not stopped before > they are freed. So far, I found the &sp->ifstart_callout in the file > net/if_spppsubr.c started but not stopped before freed, but you are > not using that routine. I will concentrate on the files that you listed > were changed. Yes, it's right. This commit needs a serious checking even if we'll fix my issue with ppp. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru