On 9/15/2016 10:32 PM, Jan Beulich wrote:
On 15.09.16 at 16:16, <tianyu....@intel.com> 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.


Xen-devel mailing list

Reply via email to