Messages in this thread | ![/](/images/icornerl.gif) | | From | TAMUKI Shoichi <> | Date | Mon, 21 Jun 2010 07:52:09 +0900 | Subject | Re: [PATCH v3] panic: keep blinking in spite of long spin timer mode |
| |
Hello,
On Thu, 17 Jun 2010 15:20:17 -0700 Andrew Morton wrote:
> > To keep panic_timeout accuracy when running under a hypervisor, the > > current implementation only spins on long time (1 second) calls to > > mdelay. That brings a good effect, but the problem is the keyboard > > LEDs don't blink at all on that situation. > > > > This patch changes to call to panic_blink_enter() between every mdelay > > and keeps blinking in spite of long spin timer mode. > > > > The default time to call to mdelay is 1ms. It will be switched to > > longer if the CONFIG_PANIC_LONGSPIN_TIMER kernel configuration option > > is enabled. This feature is helpful when running under a hypervisor. > > > > Signed-off-by: TAMUKI Shoichi <tamuki@linet.gr.jp> > > --- > > Changes since v2.1: > > - get rid of panicblink= kernel parameter > > - introduce new kernel config option CONFIG_PANIC_LONGSPIN_TIMER > > I still don't get it :( > > Why can't we simply do > > for (i = 0; ; i++) { > (*panic_blink)(i & 1); > mdelay(250); > touch_nmi_watchdog(); > } > > on all kernels, regardless of virtualisation, etc?
OK, I will commonize the time to call to mdelay() on the native case and the hypervisor case, and get rid of the kernel config option. I will adjust it to 100ms so as to keep the interval to call to touch_ nmi_watchdog() or touch_softlockup_watchdog() as much as possible. Even this change will keep panic_timeout accuracy enough when running under a hypervisor.
Thank you for the suggestion. See you next PATCH v4.
Regards, TAMUKI Shoichi
| ![\](/images/icornerr.gif) |