Date: Tue, 14 Dec 2004 16:50:36 -0700 From: Scott Long <scottl@freebsd.org> To: Nate Lawson <nate@root.org> Cc: John Baldwin <jhb@freebsd.org> Subject: Re: cvs commit: src/sys/i386/i386 vm_machdep.c Message-ID: <41BF7C4C.8020500@freebsd.org> In-Reply-To: <41BF6F44.2090407@root.org> References: <200411300618.iAU6IkQX065609@repoman.freebsd.org> <200412141333.06213.jhb@FreeBSD.org> <41BF48D4.8080305@root.org> <200412141719.10701.jhb@FreeBSD.org> <41BF6F44.2090407@root.org>
index | next in thread | previous in thread | raw e-mail
Nate Lawson wrote: > 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. > Doing an IPI is useless if interrupts are disabled on the BSP for whatever reason. Now, if you want to send an NMI, that might be interesting. Scotthome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41BF7C4C.8020500>