[lkml]   [1999]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: dual pIII network / lockup problems
    On Thu, 25 Nov 1999, Alan Cox wrote:

    > > exchange my 2 x PPro motherboard with 2 x Xeon one. Now I hit the bug
    > > several times a week... Further investigation did show that _ALL_ of the
    > > a.m. bug reports were from P-II/III machines...
    > That would make sense if its race related. The common theme on almost every
    > report I've looked at that ran out of memory mysteriously is
    > a) no process limits set
    > b) netscape

    There is no netscapes on those machines... Even X Windows are run for
    several minutes only on big holidays :)) They are servers and development
    machines which are not used for running Netscape on And they
    did work perfectly until the processors and motherboards had been exchanged
    for the faster ones...

    BTW, that our long-standing NS with 2.1.125 is running on a 2 x P-II/400
    machine which all the newer kernels don't like to run on.

    > There are a couple of exceptions but not reliable ones. Patches are accepted
    > if/when you find the bug.

    I'd like to. But it's very hard to find such a bug ...

    > > BTW, is the stable kernel > 2.2.0 supposed to appear at all? Which does
    > > build outta the box with full options enabled? And which does not contain
    > > unresolved symbols in modules? And which does really work? The last stable
    > I build 2.2.x with every driver I don't have as a module before I even release
    > it. Arjan van de Ven runs random choice compile sequences and contributes
    > patches to the odd ones that fail. You might want to ask Arjan for his
    > randomiser and load test your PIII boxes with it.

    I do _ALWAYS_ build any kernel with _ALL_ possible options (which do make
    sence) enabled and all possible drivers modularized. You know, I don't build
    specific kernels for my machine, I do it for the distribution :)) That's why
    I do hit almost every mistake in kernel sources... And that's why I don't
    need any randomizers to test _SOME_ set of kernel options - I do test them
    _ALL_ every time. Sure I can miss some errors when module FOO is requested
    and BAR is disabled or vice versa , but it's not my goal to find such an

    Sergey Kubushin aka the Tamer < > The impossible we do immediately.
    e-mail: SK320-RIPE < > Miracles require 24-hour notice.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.026 / U:15.584 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site