OK...from what I've seen so far, I think people may be artificially limiting
the solution. This has happened on 486, on pentium, on isa, on pci, on ide,
on scsi. In general, there hasn't been a single uniform similarity. At
this point I would go one of two directions. First, there is the hardware
direction. There may be more than one driver causing problems. Between
2.0.29 and 2.0.33 there were updates to large numbers of hardware drivers,
including 3Com drivers, NE2000 driver, scsi drivers, and IDE driver. There
were massive changes to the core networking code. There were massive
changes to the aic7xxx driver. There were changes to the IDE driver. All
in all, it could be one, or some combination of, these changes that is
causing the problem. We've already identified a few things. First, I
suspect that the hard lockups, no ping, no nothing else, are related to the
posting Dan Hollis made concerning his kernel looping, which was taking
place in tcp_input. Without verification, I'm guessing that the other
lockups people see are similar in that they are an infinite loop somewhere
in the net code. Alan has been trying to track the odd error that causes
the tcp_recvmsg() oops, and I personally suspect this might be related. I
also suspect that it might be a driver thing, since certain hardware
combinations never seem to produce this. Some driver may be doing the wrong
thing at the wrong place, and it may be more than just one driver. As you
all recall, during Dave Miller's change over to the new socket hashing algo,
Dave also made lots of changes to individual device drivers to make sure
they returned the right values at the right times from dev_hard_start_xmit()
call (I think that was the call, in any case I recall seeing the patch float
through). Updating a large number of drivers like that could be very
difficult, and possibly something might have gotten missed in the process.
In any case, there also many more possibilities, but I think you all get my
point. Second, the problem could be related to a (or a few) specific config
options. For instance, I never enable multicast routing (although I do
enable IP multicast support), I never use PCI bridge optimizations, nor
Triton IDE support, blah, blah and so on. These could make a difference.
If everyone that has been reporting problems could please send me a copy of
their complete .config file, then I'll try and look for any similarities
(please don't send them to the list, it doesn't need that much traffic :)
When I get them in I'll set down and do a summary of idetical items from
each config.
Now, for those people that experience this problem on a regular basis,
talking about the lockups and oopses in tcp_recvmsg(), not other oopses and
problems, here are a few things I would do to start off with:
Use new IDE driver with RZ1000 and CMD640 bugfix support *only*
Disabled tagged queueing and scb paging on aic7xxx driver
Disable unneeded net options, disable large window net support, enable path
mtu discovery.
If you have access to it, try building the system with nothing but tulip
cards (not everyone can do this, but I would be *very* interested to hear if
this helps someone as that would point a finger at the old net card
driver/hardware). The reason I say tulip is because I have about 8 machines
that work as routers and news servers and other things all running nothing
but tulip hardware and since 2.0.33 was released there has not been a
*single* tcp related oops on these machines (some of which pass 400 to 500
packets per second 24 hours a day and another that has had as many as
300,000+ non-cached web hits in a single say, over 7,000,000 hits that month
on a single virtual host).
I would recommend more, but I need to take a look at the .config options in
use first, these are just generic things that might help.
Now, finally, to Ken Jordan concerning his post. Man, I'm sorry, but that
looks *very* much like random data corruption to me, not a kernel bug. I
could understand the lockups and related oopses being kernel related, and
yours still may be, but my first area to look on your machine would be
hardware. My second area to look on your machine would be for some driver
that is using a wild pointer and writing to it. However, the IDE config I
posted above may help you if what we are seeing here is memory corruption
during an IDE swap transaction or something similar.
--Doug Ledford <dledford@dialnet.net> Opinions expressed are my own, but they should be everybody's.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu