[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC] x86/watchdog: Always disable watchdog before console_force_unlock()

On 12/08/13 09:50, Jan Beulich wrote:
>>>> On 09.08.13 at 23:17, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> Depending on the state of the conring and serial_tx_buffer,
>> console_force_unlock() can be a long running operation, usually because of
>> serial_start_sync()
>> XenServer testing has found a reliable case where console_force_unlock() on
>> one PCPU takes long enough for another PCPU to timeout due to the watchdog
>> (such as waiting for a tlb flush callin).
>> The watchdog timeout causes the second PCPU to repeat the
>> console_force_unlock(), at which point the first PCPU typically fails an
>> assertion in spin_unlock_irqrestore(&port->tx_lock) (because the tx_lock has
>> been unlocked behind itself).
>> console_force_unlock() is only on emergency paths, so one way or another the
>> host is going down.  Disable the watchdog before forcing the console lock to
>> help prevent having pcpus completing with each other to bring the host down.
> So perhaps rather than calling watchdog_disable() before calling
> console_force_unlock(), would we not better call the former first
> thing from the latter?
> Jan

That was indeed my first attempt, but console_force_unlock() is common
while watchdog_* is x86.

I could convert the watchdog to arch specific.  I suppose it is
possible/likely that the Arm folk might want to implement and use
watchdogs ?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.