Messages in this thread |  | | Date | Wed, 27 Sep 2000 23:26:09 +1100 | From | Andrew Morton <> | Subject | Re: 3c59x problems solved -- mostly |
| |
Arnaud Installe wrote: > > Hello, > > So I tried your suggestions. Unmasking the hd IRQs sure helps prevent a > lot of buffer overruns. There still are some, but they're down by a > factor of 100 or more...
Nice to have an explanation.
> Any suggestions to reduce those even further > more than welcome, as I suppose this might cause some Multicast UDP > packets to get dropped. :-/
Yes, you'll be dropping packets.
> Would using SCSI instead of IDE help, do you think ?
It depends upon the SCSI driver. I haven't measured kernel interrupt latencies for a while. Back in March, IDE beat the pants off SCSI in this regard.
The IDE system was UDMA-66 (using hdparm -u1 -d1). The SCSI sytem was from Advansys (I don't know how good this driver is). The numbers are at http://www.uow.edu.au/~andrewm/linux/intlat/intlat-disk.html. This was for the 2.3.99 kernel.
IDE: 27 usecs SCSI: 42 usecs
Still, these aren't large enough to explain this behaviour.
Are you sending much output to the console? You'll see from Doug Gilbert's numbers that the console driver can block interrupts for a millisecond. Try running X, or otherwise prevent things from writing to the console.
The sensible alternative, of course, is to use a multicast filter. The 3c905B/C does have a 256 slot hash filter. Unfortunately (and uncharacteristically), 3com forgot to document it. However it _is_ implemented in 3com's own GPL'ed driver. This driver is bundled in RedHat 6.x and is available at http://support.3com.com/infodeli/tools/nic/linux.htm . It's worth visiting that site just for the amusement factor of having to click on "I agree" for the license. It's the GPL!
Even better, port 3com's code to 3c59x.c and send me a patch :)
> The 2.2.17 driver still seems to have a few bugs though: we get messages > like: "Too much work in interrupt, status e401". This seems to happen > more on machines with RX buffer overruns.
hmm.. Yes, something is wrong. I see this could perhaps silently happen if the driver is hopelessly out of memory. And this would explain the failure you saw in the 2.2.16 driver. It had an Rx-stops-working-on-OOM bug.
Could you please, before doing anything else, see if
echo '512 1024 1536' > /proc/sys/vm/freepages
makes a difference? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |