On Oct 23, 8:37 pm, "DFS" wrote:
> "...sometimes the system freezes even though I didn't even touch the mouse
> or the keyboard."http://www.murga-linux.com/puppy/viewtopic.php?search_id=1213323145&t...

That is correct; Linux (or a module therein) will freeze if
certain conditions are met. These conditions may be very
hard to identify, but one simplistic one for example is
a wayward interrupt from a card that Linux misidentified
or misconfigured. If the code for that card is written
in a certain fashion one might get a call to panic()
and the entire system basically shuts up and goes south.

(One very ancient example: on PCs prior to about the 386
era I would routinely see, when DOS was running, a quick
"Divide by zero" fault on the screen when I shut the
PC off. Clearly something wasn't programmed to handle
a power fault -- assuming a power fault indication was
available at all -- and the OS misinterpreted it as a
divide by zero error, printing it out just before the
machine ceased operations.)

It is *not* (purely) a hardware error; it is a combination
of hardware and software (hardware by itself doesn't do
much, after all). As someone once said, in QA:

- Test the means.
- Test the extremes.
- Test the exceptions.

In order to properly test these, one should implement
them. Clearly, there's a driver making a bad assumption,
causing a system freeze. Faulty hardware might test that
assumption, or it might not. Identifying which driver
is rather important; regrettably, the OP merely gives us
a list of candidates. (Another poster shows his naivete:
trying to execute the command '!/bin/sh' doesn't work
very well. ;-) )

At least with Linux, one might have a fighting chance at
compiling a debug version of the module and attempting to
figure out why the machine is freezing up. Best idea I
have in that area is to set up another machine with remote
logging capabilities, and send messages to that machine
from the kernel. When the first machine freezes up, one
might have a record on the second machine as to what Linux
was "thinking" at the time.

The rest of the thread speculates that the problem might
be caused by a bad BIOS setting on a fan unit (though
they don't identify such that specifically; the OP merely
states that he "manually set the fans to higher RPMs"
somehow), or more simply because the unit overheats.
Anyone familiar with "thermal runaway" in transistor units
gets very worried at this point, and this could happen with
most systems if the fans get clogged with dust, of course.

Even magical mystical Microsoft Windows Vista can't quite fix
that problem.

On a somewhat related note: my nx9010 has no thermal
problems as such, but it does have some interesting
varispeed fan capability; I do not believe this capability
is directly controlled by Linux, though with acpi I
can monitor the temperature of the CPU readily enough.
Briefly, the fans have 4 speeds (though it's possible they
simply switch on and off instead, with all three being on
for "high speed" or something):

- off, for nice quiet operation -- for a short time
- low, when the unit is relatively cool and generally idle
- medium, when I'm compiling something or playing a game,
which tends to heat up things
- high, when I'm compiling something rather intensively and
the CPU goes over 65 degrees Celsius (it can tolerate
73 from what docs I've been able to find, so there's a
certain margin here, fortunately).

I suspect other laptops have similar capabilities.

Note that even when one isn't touching things, the CPU is
executing occasional cycles; after all, clocks and crontab
need to run, and one might get occasional interrupts from
other devices such as NIC packets from one's upstream
router. Get the wrong combination of packets and
a slightly buggy driver, and things can easily go south.