Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

["Lan, Tianyu" <tianyu.lan@xxxxxxxxx>]

On 9/15/2016 10:32 PM, Jan Beulich wrote:
> > > > On 15.09.16 at 16:16, <tianyu.lan@xxxxxxxxx> wrote:
> > On 9/13/2016 11:25 PM, Jan Beulich wrote:
> > > Wait - what is do_invalid_op() doing on the stack? I don't think it
> > > belongs there, and hence I wonder whether the keypress
> > > happened after some already fatal event (in which case all bets
> > > are off anyway).
> > Not clear why do_invalid_op() on the stack. There is no other fatal
> > event. The issue disappears when set watchdog_timeout to 10s.
> >
> > > > > Another solution is to schedule a tasklet to run keyhandler in timer
> > > > > handler and invoke process_pending_softirqs() in the dump_timerq().
> > > > > This also works but it requires to rework keyhandler mechanism.
> > > > >
> > > > > Disable watchdog seems to be simpler and I found dump_registers() also
> > > > > used the same way to deal with the issue.
> > > That's true. Just that on large machines it defaults to the
> > > alternative model, for which I'm not sure it actually needs the
> > > watchdog disabled (as data for a single CPU shouldn't exceed
> > > the threshold).
> > It seems not to be necessary to disable watchdog in alternative model
> > since dumping a single cpu's status will not last a long time.
> >
> >
> > For the issue in the dump timer info handler, disabling watchdog is ok
> > for you or you have other suggestions to resolve the issue?
> Well, without a clear understanding of why the issue occurs (for
> which I need to refer you back to the questionable stack dump)
> I'm hesitant to agree to this step, yet ...
After some researches, I found do_invalid_op() on the stack dump is
caused by run_in_exception_handler(__ns16550_poll) in the ns16550_poll()
rather than fatal event. The timeout issue still exists when run
__ns16550_poll() directly in the ns16550_poll().


> > I also found other places where dump a lot of logs disable watchdog.
> > (E,G run_all_keyhandlers(), debugtrace_dump() debugtrace_toggle() and so
> > on). This seems a common solution.
> ... I'm also not entirely against it considering the various other
> examples. I.e. as almost always: As long as the need for the
> change can be properly explained, I won't stand in the way of
> getting it in.
>
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel