doubt that's the answer, because the system response is fine all the time except when there's network traffic *to this system*.
Look following Linux kernel mailing list summary from the kerneltraffic.org:
Mika
----------------------------------------------
1. Progress Toward 2.4.22; Problems With BitKeeper Gateway; Mysterious Kernel Lockups
5 Jul - 2 Aug (63 posts) Archive Link: "Linux 2.4.22-pre3"
Topics: FS: devfs, Version Control
People: Ben Collins, Larry McVoy, Adrian Bunk, Marcelo Tosatti, Jim Gifford, Andrea Arcangeli, Jeff Garzik
Marcelo Tosatti announced 2.4.22-pre3, and Ben Collins complained that the -pre version number was not shown in the sources. Neither -pre2 nor -pre3 had proper version tagging, he said, adding, "It just makes it easier when tracking down regressions to have known points of reference common across BK/CVS/SVN/tar+diff." Marcelo said the sources looked properly tagged to him, and Larry McVoy asked, "Hmm. Ben, look again in the CVS tree and make sure that the tags aren't there. Maybe the converter screwed up?" Ben replied, "Doesn't show up in linux-2.4/ChangeSet,v as a tag." Adrian Bunk also pointed out, "-pre2 and -pre3 are also missing at http://ftp.kernel.org/pub/linux/kernel/v2.4/testing/cset/."; Jeff Garzik confirmed that whatever other problems there were, Marcelo had definitely tagged his own BitKeeper tree properly.
A couple days later, Larry said, "I think I've found the bug - it's in the code that collapses multiple changesets into one CVS checkin. It looks like we are picking up tags only if the tag was on the last changeset in the sequence instead of any changeset in the sequence. We're fixing it." Ben thanked him, and that was it for that subthread.
Elsewhere, Jim Gifford reported on an ongoing problem he'd been having with the 2.4 series: lockups, after about two days. The 2.4.22-pre3 did not fix his problem, he said, although he could avoid the crash by running 'sync' every hour. Marcelo and Alan asked for more information, and together they eliminated compiler versions and bad memory. Jim continued to reproduce the problem over the course of several new pre-releases. At one point Marcelo noticed that Jim's kernel was not based on pristine sources (Jim had added some netfilter and megaraid patches), and asked if Jim could reproduce the lockups with the official kernel. Yes, the lockups still persisted.
Andrea Arcangeli also got into the act, asking Jim to remove devfs and other modules that were not part of the main tree. Jim did this, and was unable to produce the lockup in -pre7. He asked if Marcelo wanted him to run other tests, but Marcelo replied, "I guess most of us is already convinced that the lockups were caused by the non-stock code." But Jim tried running the stock -pre6 kernel, and was able to reproduce the lockup. He said, "something in -pre7 seems to have fixed the problem." So he started adding the non-stock code back into -pre7, and later -pre8, piece by piece, to see if any of them would cause the problem. Eventually he felt he'd narrowed the problem down to some netfilter patches he'd applied; and Marc Heckmann, who also experienced similar lockups on his system, remarked that everyone who'd seen the problem had been using iptables.
The situation was quite complex, and there was no absolutely clear resolution on the list. As Jim put it toward the end of the discussion, "The wierd part is that people are having problems with different modules and it's hard to track down what is in common."
