I upgraded one of our squid servers to 2.4.0 yesterday (the others are on 2.4.0-test5) and did some load testing this afternoon. The box is a Celeron/366 on an 810A with a 3Com 905B. Around 1000 FDs and 10Mbit, it started coughing up these: Jan 21 14:51:22 squid1 kernel: reset_xmit_timer sk=cf14dcc0 1 when=0x3cc7, caller=c019a4c2 Jan 21 14:51:23 squid1 kernel: reset_xmit_timer sk=cf14dcc0 1 when=0x3c28, caller=c019a4c2 Jan 21 14:51:23 squid1 kernel: reset_xmit_timer sk=cf14dcc0 1 when=0x3bd1, caller=c019a4c2 I tossed a little more on and somewhere around 1500 FDs and 15Mbit, all of the connections froze. I assume that's when it coughed up this: Jan 21 14:51:24 squid1 kernel: reset_xmit_timer sk=cf14dcc0 1 when=0x3b92, caller=c019a4c2 Jan 21 14:51:25 squid1 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000014 Jan 21 14:51:25 squid1 kernel: printing eip: Jan 21 14:51:25 squid1 kernel: c013c169 Jan 21 14:51:25 squid1 kernel: *pde = 00000000 Jan 21 14:51:25 squid1 kernel: Oops: 0000 Jan 21 14:51:25 squid1 kernel: CPU: 0 Curiously, the ssh session I had open froze, but sshd did not -- I could still open a new ssh session. I also wound up with several 'defunct' processes, including kswapd, but I'm not sure if they were defunct when I logged in or when I tried to kill the bash and whatnot from the other session. reboot did nothing -- I had to use 'reboot -f' to restart it. Also, though probably unrelated, I found a few of these in the logs: Jan 21 13:46:46 squid1 kernel: TCP: peer 209.186.242.164:1635/80 shrinks window 3061666898:7504:3061674938. Bad, what else can I say? Jan 21 13:46:47 squid1 kernel: TCP: peer 209.186.242.164:1635/80 shrinks window 3061667434:6968:3061674938. Bad, what else can I say? Jan 21 13:46:47 squid1 kernel: TCP: peer 209.186.242.164:1635/80 shrinks window 3061667970:6432:3061674938. Bad, what else can I say? I'll have to do a little more testing to see if I can reproduce the problem. Any ideas/suggestions? Thanks, -- Brian - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org