Re: [discuss] Re: [PATCH] adjust x86-64 watchdog tick calculation

[Andi Kleen <ak@suse.de>]

On Sun, May 15, 2005 at 12:51:00PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > > Because it kills machine when interrupt latency gets too high?
> > > > > Like reading battery status using i2c...
> > > > 
> > > > That's a bug in the I2C reader then. Don't shot the messenger for bad news.
> > > 
> > > Disagreed.
> > > 
> > > Linux is not real time OS. Perhaps some real-time constraints "may not
> > > spend > 100msec with interrupts disabled" would be healthy, but it
> > > certainly needs more discussion than "lets enable NMI
> > > watchdog.". It needs to be written somewhere in big bold letters, too.
> > 
> > While linux is not a real time OS it has been always known that
> > turning off interrupts for a long time is extremly rude.
> 
> Yes, it is rude, but it should not panic machines.

Disagreed. It is a bug and needs to panic machines.

> 
> > If you really want you can use touch_nmi_watchdog in the delay
> > loop then.  But note you have to compile it in, because touch_nmi_watchdog
> > is not exported (Linus vetoed that for good reasons).
> > 
> > But again do you really need to disable interrupts during this
> > i2c access? Can't you just use a schedule_timeout() and a semaphore?
> > Why would other interrupts cause a problem during such a long delay?
> 
> In this case it is "AML code told you to disable interrupts, and do
> this kind of bitbang". AML interpretter has no idea of what that code
> does... Perhaps we could sprinkle touch_nmi_watchdog all over the
> interpretter, but that's just ugly.

Actually that's wrong. Because I fixed that code long ago if
you mean the access in battery.c
(if you search the ACPI mailing list for my name you should find it)
And there was no AML code involved here.

For some reason the ACPI guys didn't merge my patch though,
but that just needs to be revisited.

-Andi