Date: Thu, 15 Nov 2012 23:41:31 +0000 From: Attilio Rao <attilio@freebsd.org> To: Ryan Stone <rysto32@gmail.com> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI Message-ID: <CAJ-FndBQwO0syGpG9mSYF4tAEO8wu6vv7QKbvzQY-9uo_ZJWhA@mail.gmail.com> In-Reply-To: <CAFMmRNwb_rxYXHGtXgtcyVUJnFDx5PSeMmA_crBbeV_rtzL9Cg@mail.gmail.com> References: <CAFMmRNwb_rxYXHGtXgtcyVUJnFDx5PSeMmA_crBbeV_rtzL9Cg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Nov 15, 2012 at 10:58 PM, Ryan Stone <rysto32@gmail.com> wrote: > At work we have some custom watchdog hardware that sends an NMI upon > expiry. We've modified the kernel to panic when it receives the watchdog > NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've > discovered that when my watchdog expires, the system gets completely > wedged. After some digging, I've discovered is that I have multiple CPUs > getting the watchdog NMI and trying to panic concurrently. One of the CPUs > wins, and the rest spin forever in this code: Quick question: can you control the way your watchdog sends the NMI? Like only to BSP rather than broadcast, etc. This is tied to the very unique situation that you cannot really deliver the (second) NMI. Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndBQwO0syGpG9mSYF4tAEO8wu6vv7QKbvzQY-9uo_ZJWhA>