Mysterious freezes after 2.6.35, no NMI

Mysterious freezes after 2.6.35, no NMI

[Nicos Gollan]

Hi,

For quite some time now I have serious trouble with any kernel after 2.6.35. I 
am experiencing frequent hard freezes. The system will simply stop responding 
to input and is not reachable via network, which leads to data loss because 
the file system does not get to write back all data (the classical "all my KDE 
config is gone!" symptom).

A quick recap and a bunch of info (dmesg, lspci, other hardware info) can be 
found here:
    https://bugzilla.kernel.org/show_bug.cgi?id=31122

Note that the crashes from static electricity are most likely not related, 
since those lead to a very recognizably different failure mode, the ports are 
not even connected anymore, and the real problem occurs without anything 
touching the case, and I have not experienced the problem with old kernels or 
Windows 7.

At first I suspected the HPET "fixes" in 2.6.36 to be responsible, but the 
instability occurs with HPET disabled by kernel parameter (the BIOS setup does 
not allow to disable it).

To add insult to injury, at least in the 2.6.38 series, the NMI watchdog is 
broken. The counters in /proc/interrupts always show 0, but will count up 
quite happily on 2.6.35.

I'm rather tired of guessing what it might be, the whole thing is very hard to 
diagnose since it can take days until a freeze happens, and I don't really 
want to push my luck so far that I lose important data, but being stuck at 
2.6.35 is not satisfactory in the long run.

I am not subscribed to the list, but I am subscribed to the bug report.

Regards,
Nicos Gollan

Re: Mysterious freezes after 2.6.35, no NMI

[Don Zickus]

On Tue, Apr 12, 2011 at 07:39:59PM +0200, Nicos Gollan wrote:
> To add insult to injury, at least in the 2.6.38 series, the NMI watchdog is 
> broken. The counters in /proc/interrupts always show 0, but will count up 
> quite happily on 2.6.35.

The nmi watchdog changed for 2.6.36, such that it increments every 60
seconds instead of every second.  Using cpuspeed and a lightly loaded
system, will delay it even longer.  This is a good thing as you don't need
nmi interrupts firing all the time.

But if after sticking a load on the system for 10 minutes, the NMI
interrupt doesn't increment, then I would be concerned.

Cheers,
Don

Re: Mysterious freezes after 2.6.35, no NMI

[Nicos Gollan]

Hi,

On Tuesday 19 April 2011 16:30:31 Don Zickus wrote:
> On Tue, Apr 12, 2011 at 07:39:59PM +0200, Nicos Gollan wrote:
> > To add insult to injury, at least in the 2.6.38 series, the NMI watchdog
> > is broken. The counters in /proc/interrupts always show 0, but will
> > count up quite happily on 2.6.35.
> 
> The nmi watchdog changed for 2.6.36, such that it increments every 60
> seconds instead of every second.  Using cpuspeed and a lightly loaded
> system, will delay it even longer.  This is a good thing as you don't need
> nmi interrupts firing all the time.

In how far does that change the time until the watchdog would trigger after a 
freeze? Would it react on the first or second execution after the freeze? That 
would make it "two minutes or even longer", depending on the CPU frequency 
that was set when the control daemon died.

IMO that slow and nondeterministic behaviour is detrimental to the watchdog's 
declared function. With those changes, there's no idea how long one would have 
to wait after a freeze. There should at least be a fixed upper limit on the 
execution period, and according changes to Documentation/nmi_watchdog.txt

Regards,
Nicos