On 2005-12-14, Paul Davis <[EMAIL PROTECTED]> wrote: > --===============080417869966452615== > Content-type: text/plain > Content-transfer-encoding: 7bit > > On Wed, 2005-12-14 at 07:53 +0000, Tuomo Valkonen wrote: >> Combine this with the increasing BSOD-type behaviour of the kernel after >> 2.2 (much of which may be related to the pursuit of "desktop performance" >> which, of course, includes BSOD emulation), and still after 15 or so years, >> not having display drivers in the kernel, thus allowing X to put the >> system in a state where it only responds to the reset button from the >> console. > > numbers, or are you just hand waving?
Waving hands, of course, but I do remember not having any problems with 2.2 not related to hardware (2.0, infact, didn't have problems with a crappy cd drive that 2.2 did), 2.4 did occasionally crash with oopses in the logs, and 2.6, especially 2.6.14, does that constantly and reproducibly. octave:> inv(rand(6000)); Wait a moment and the system won't respond to anything, not even magic sysrq, IIRC. I suspect that this is due to some hacks in the OOM killer that I read about. Fortunately, while researching that issue I learned of vm/overcommit_memory=2 and could altogether disable that absolutely brain-dead behaviour. (Who came up with that overcommitting idiocy?) I also have (had? lograte may have deleted them already) logs full of stack traces related to futexes and java processes, with an eventual crash not listed there, and recall having some other crashes, but not the details. > display drivers in the kernel? Read my other reply. The kernel should include video mode switching or other resetting functionality for reliable virtual console switching. -- Tuomo
_______________________________________________ Desktop_architects mailing list Desktop_architects@lists.osdl.org https://lists.osdl.org/mailman/listinfo/desktop_architects
