Latest kernel source

Richard B. Johnson (root@analogic.com)
Wed, 26 Feb 1997 19:35:47 -0500 (EST)


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.

main()
{
if(read(0, NULL, 1) < 0)
perror("");
}
The 'C' runtime library is 5.2.18.

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

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
netstat.

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.

Cheers,
Dick Johnson
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Richard B. Johnson
Project Engineer
Analogic Corporation
Voice : (508) 977-3000 ext. 3754
Fax : (508) 532-6097
Modem : (508) 977-6870
Ftp : ftp@boneserver.analogic.com
Email : rjohnson@analogic.com, johnson@analogic.com
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-