From owner-cvs-all@FreeBSD.ORG Tue Dec 14 22:55:11 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D908616A4CE; Tue, 14 Dec 2004 22:55:11 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 788F143D5E; Tue, 14 Dec 2004 22:55:11 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id iBEMt1ug008304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Dec 2004 14:55:08 -0800 Message-ID: <41BF6F44.2090407@root.org> Date: Tue, 14 Dec 2004 14:55:00 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200411300618.iAU6IkQX065609@repoman.freebsd.org> <200412141333.06213.jhb@FreeBSD.org> <41BF48D4.8080305@root.org> <200412141719.10701.jhb@FreeBSD.org> In-Reply-To: <200412141719.10701.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 vm_machdep.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 22:55:12 -0000 John Baldwin wrote: > On Tuesday 14 December 2004 03:11 pm, Nate Lawson wrote: > >>John Baldwin wrote: >> >>>On Tuesday 30 November 2004 01:18 am, Nate Lawson wrote: >>> >>>>njl 2004-11-30 06:18:46 UTC >>>> >>>> FreeBSD src repository >>>> >>>> Modified files: >>>> sys/i386/i386 vm_machdep.c >>>> Log: >>>> MFamd64: Remove the cpu_reset_proxy cruft now that we run boot() on >>>> cpu 0. Also, restructure cpu_reset to be cleaner (no functional >>>>change.) >>> >>>FYI, this breaks the 'reset' command from ddb if you panic on a cpu other >>>than the BSP. boot() isn't the only function that calls cpu_reset(), so >>>perhaps this should be reverted (same for amd64) >> >>No, I think we should move forward instead of backward. Entering the >>debugger should happen on the BSP and possibly other cpus need to be >>stopped by panic(). > > Erm, well, that's not always easy since sometimes when you panic you can't > talk to the other CPUs for whatever reason. Putting back the proxy reset > doesn't hurt for now but does restore functionality in at least some cases. > I'd rather have that then certain hard panics not get into ddb because we > couldn't get onto the BSP to run ddb. Perhaps you could give me some pointers on what is counted on to be working when panic() is called? I can't come up with a situation where the proxy code couldn't be used upon entry to ddb. If there were any cases like this, the proxy code wouldn't work for cpu_reset() either. Also, in such a case, it's hard to see how ddb could be usable since it tries to stop other processors, which requires similar code to the proxy. Or in other words, if you have enough capability to call panic() or break to ddb, then you have enough resources to do an IPI and get onto the BSP. -- Nate