Messages in this thread | | | Date | Wed, 26 Feb 1997 19:35:47 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Latest 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.
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. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| |