Date: Wed, 15 Dec 2004 12:04:25 -0800 From: Nate Lawson <nate@root.org> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.org> Subject: Re: cvs commit: src/sys/i386/i386 vm_machdep.c Message-ID: <41C098C9.2010802@root.org> In-Reply-To: <20041215115843.E45301@delplex.bde.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> <20041215115843.E45301@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > On Tue, 14 Dec 2004, Nate Lawson wrote: >>John Baldwin wrote: >> >>>On Tuesday 14 December 2004 03:11 pm, Nate Lawson wrote: >>>>John Baldwin wrote: >>>>... >>>> >>>>>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 > > The most common reason is that at least one other CPU is looping with > interrupts disabled. Then it won't see IPIs and stop_cpus() will loop > forever. Yes, the NMI change would fix this. Please repost your ddb sync patch. I'm ok with John putting the cpu proxy reset stuff back in for now. He's right in that it's the best we can do for now. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41C098C9.2010802>