[lkml]   [1997]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectLatest kernel source

    I have now updated my SMP machine (dual Pentiums 166 MHz), using the
    latest patches to the 2.1.26 kernel.

    I have been waiting until the latest kernel before writing about existing
    problems. I have now tested the things I've been experiencing, and the
    problems have not been fixed. Here are the problems.

    o The sendmail daemon dies on select() with error 512. This only
    occurs with the SMP kernel.

    o The in.portmap daemon dies on accept(). This only occurs with
    the SMP kernel.

    o The inetd deamon doesn't die, but reports unknown error 514
    when using telnet. This only occurs with the SMP kernel.

    o The following program works "fine" without producing any errors
    or a core-dump. Core dumps are enabled.

    if(read(0, NULL, 1) < 0)
    The 'C' runtime library is 5.2.18.

    o The following program also works "fine" without producing any
    errors or a core-dump.
    if(write(1, NULL, 10) != 10)

    o When routing between the SMP machine and another which is on a PPP link,
    'ftp' transfers data for a while. Then it stops. It waits for as much
    as 10 minutes before starting to send data again. This continues,
    taking as much as an hour to transfer a 500k file on a hard-wire
    link at 38400 baud.

    Tcpdump on the destination machine shows packets being ACKed okay,
    but the server (SMP) sometimes sends the same packets many times.

    I have been having this problem ever since ipv4 became part of the
    kernel. It is not related to SMP. I have set up a test PPP link
    here at work in an attempt to find the reason for this problem.

    The machine sending ftp data, shows a very large Send-Q using

    The machine routing the ftp data shows a very very very large
    amount of data in /proc/net/rt_cache. '/cat/proc/net/rt_cache >foo'
    makes a file that is several megabytes in length. Most of the
    entries seem to be similar.

    The machine receiving data happily waits for data, and waits, etc.

    o Cosmetic problem with 'top' and SMP. The following program shows
    199.9% CPU usage. This is not a complaint! I like it :^)!

    main{ for(;;) ; }

    o /bin/setserial causes a system hang upon startup. The same
    script can be executed without errors after the serial ports
    have been accessed by /sbin/agetty. This problem occurs
    always with a SMP kernel and sometimes with SMP disabled.

    Starting a minimum system with /bin/bash instead of init, shows
    that /bin/setserial can't be stopped with a ^C or ^\ signal.
    I think's it's in uninterruptable sleep, waiting for a modem
    carrier. If I raise the CD line with a 9-volt battery, the
    program executes okay. This may be a setserial program problem.
    It MUST open the device initially with O_NDELAY. I don't have
    the source so I can't check.

    Dick Johnson
    Richard B. Johnson
    Project Engineer
    Analogic Corporation
    Voice : (508) 977-3000 ext. 3754
    Fax : (508) 532-6097
    Modem : (508) 977-6870
    Ftp :
    Email :,
    Penguin : Linux version 2.1.26 on an i586 machine (66.15 BogoMips).
    Warning : It's hard to remain at the trailing edge of technology.

     \ /
      Last update: 2005-03-22 13:39    [W:0.020 / U:0.160 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site