In message <Pine.LNX.3.95.970819095015.5061B-100000@pc7537.hil.siemens.at>,
Ingo Molnar writes:
>
>On Sun, 17 Aug 1997, Westley Weimer wrote:
>
>> > I'm still getting solid freezes with Linus-pre-2.0.31-6 &
>> > SW raid145-0.36.3-2.0.30+raid145-970721-2.0.30.
>> >
>> > Since they are solid freezes, I cannot determine the cause.
>>
>> Sadly, ignorance of technical details prevents me from contributing
>> anything of actual merit to this discussion, but I can add a data point:
Yes, I'm sorry that I cannot unfreeze the freeze to figure it out.
I can't even switch VTs to a screen to see if something-SCROLL_LOCK works.
>> linus-pre-2.0.31-6 + raid145-0.36.3-2.0.30 + raidtools 0.40 + libc5.4.23
>> normal-buglogic-w/o-flashpoint + no-other-patches on i586
>>
>> ** I get no hard lockups.
>>
>> > I have a large feeling that it is a non-RAID related bug (as well?)
>
>neither do we experience anything that can be called a 'solid freeze'.
>Actually, maybe this helps, but i _never_ got a solid freeze even while
>developing certain parts of the RAID driver, and it's understandable: the
>code is 'fallthrough' in most of it's parts, and never loops with
>interrupts disabled. We've tested various out-of-mem and out-of-diskspace
>situations to see the driver's behaviour in 'unusual' situations also.
>[and we used emulated disk-errors also]
>
>so i'd first suspect either some hardware bug, or a main kernel bug. If
>it's an earlier 2.1 SMP kernel, i'd suggest an upgrade to 2.1.51, or if
>2.0 SMP, an upgrade to pre-7 2.0.31 (which includes Leonards many lockup
>fixes!).
The pre-7 patches may have indeed fixed it; my uptime is 23:17. Let
me do something intensive just to make sure ... okay, nothing
happened, and my uptime is now 1 day 1h:19m. My machine is definately
not SMP, although SMP fixes may fix some non-SMP things as far as I'm
concerned (I haven't looked at the patches to see if the changes were
dependent (e.g. #ifdef) on SMP). It may be the new memory I just
added, but I was getting freezes before that since 2.0.30; I think
this was before I integrated SW RAID into it too. Now that Ingo says
it's mostly "fallthrough" I believe it wasn't the RAID, except they
did send out one patch that stopped freezes. The freezes *might* also
be related to SCSI (ncr53c8xx).
I hope that whatever got fixed was a real bug, and not just a timing
shift, but we all always wish, don't we?
Thank you, Linus, for providing us the manual CVS structure that Linux
needs to live off of; and someone, please take Linus' hint of a few
years ago that if someone came up to organize (and, possibly, host and
administer) a version control system for Linux that he'd appreciate
it!
>Nevertheless, 2.1 freezes can be cleanly debugged via the 'ktrace' patch,
>which includes a soft-freeze detection and a hard-freeze detection option
>too. It needs a kernel recompilation and some knowledge about how to
>read/post Oops messages. If someone experiences unexplained freezes,
>please contact me to get the newest ktrace patch + debugging help.
Does this work with cold freezes? I mean, 0-degree-kelvin cold (no
log messages, no drive syncs, no LED light response, no packet
response, nothing)? If so, it must have its own heat source (perhaps
some nifty NMI keepalive feature of the Pentium chips?) Anyway, if
so, please do email me it.
If you do, I'll even recompile bad kernels to confirm exactly what the
bugs are, if you really think that thing will catch the crashes.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQEVAwUBM/n++pxWhFYc6x9VAQEpdQf/TmzuqradLMjTo0c5DlXhQLepk6c4HZFx
E54a7+LWxuSLGLZlUtMfY0oM6POrnxPS/fp5oilUcfWXOsIYFlkh1vLoirdj/Dta
g+ujWOjq5mbbfVuzxCG8a+MO9htlTok1FplT18ZydAXtmYbujcvbfYiZt5JUzQ5c
kw1tip6Fouh28pqM5I4u7P0Tjr5NdVFKUhEZwv0lZA/+9HOEPNkRjL1lUl1qlu5E
gALFQxT3mhgjzUDe3urUic5xQ30qL7/vZpkuqjn4ljoZ8eA6G5X7UbL0m2Dy/8KK
Orn0P3K8J3fl9H3rmVquuUocx/9zEhpSrwgnyUaBA36+wE35YxHuvQ==
=NG5l
-----END PGP SIGNATURE-----