> 4. panic: ip_evictor (this typically won't be seen unless you do
> something like deliberately spray a machine with incomplete packets
> - eg by doing ping -s 32768 -f some.box down a SLIP link).
No, but after doing this to a remote host over a 14.4 packetized modem
link, and then hitting ^C (my INTR key):
.....................................................................................................................................................................................
--- panix.com ping statistics ---
14852 packets transmitted, 0 packets received, 100% packet loss
Socket destroy delayed (r=0 w=1660)
Q:~# May 15 00:29:00 Q facility=kern(0) priority=warn(4) priority=warning(4) kernel: Socket destroy delayed (r=0 w=1660)
> 2. repeated socket destroy messages every 10 seconds
No.
> 3. Stuck sockets (notably on big FTP or WWW servers)
(What's this?)
> 5. TCP send queue out of order reports
No?
I've seen this but forget where (it might have been when looking
at the source one day).
> 6. Not being able to talk to some sites and a trace that looks like
> a MTU discovery problem (continually resending a frame with DF set
> and getting an ICMP error back).
Hmm .... perhaps.
There are certain hosts I cannot talk to after a "TCP Connection
Established" (ftp sites, etc.) that other hosts can talk to no
problem; I haven't diagnosed what's going on but have eliminated most
identd and reverse-forward-lookup matching problems (my reverse lookups
should be fairly sturdy!)
What trace would this be? traceroute -f shellx.best.com. 2000???
> 7. TCP performance problems.
I get this feeling that when I have simultaneous full-bandwidth-using
transfers over my 14400bps modem PPP link, the modem gets near 100%
utilization but the total throughput of all file transfers is less
than 100% of available bandwidth. How would I further do tests with
this? This is a feeling after running pppstats -i 1, (or -i 10), and
then "ls -l file1 file2 file3; sleep 10; ls -l file1 file2 file3" and
then using dc to calculate how many bytes got transfered. Usually
these are gz'd files, and most if not all packets are reported as sent
& received compressed through the modem (which supposedly is just a
few header fields being compressed is my guess). I have so much going
on that it could just be some other process sneaking through its own
transfers (such as NNTP, eggdrop, SMTP, etc.) but when I stare at a
"watch -n 1 netstat |egrep ESTABLISHED" I never see anything coming
out of the other random processes (they look sleepy) suggesting that
they're probably not receiving much (if anything) either.
> 8. bogus packet size/mismatched pointers reports on 8390 based ethernet
> drivers.
>
> I want to see how bad these problems actually are and how many people are
> seeing them - also hopefully a pattern so try and include hardware info.
>
> Alan
I also got those UDP checksum errors on occasion ... I forget the
reasons, but it's always during machine stress times. Whether I got
one lately I forget.
Dell XPS P133c, 24M (8M EDO, 16M non-EDO, 256k cache), two IDE
(1G,1.6G), mostly unused ncr53c825 (just an IOMega Jaz on it now;
waiting to stick more!), #9 GXE 64, Intel Triton mother, unused 3c509,
two serial devices (one temperature reader & one modem), currently
running most of the recent stuff in Documentation/Changes on a 1.99.4,
with a small pallet of low-to-medium-used servers (X, {SM,N,NN,HT}TP, etc.)