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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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 ...

> 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