|
Hello Julian,
> Are the drivers from the kernel tree? We have reports from
> such checksum problems with the Intel's E100 driver and we still
> don't know where is the problem. This driver supports hardware
> checksuming, may be in CHECKSUM_HW form for the tested NIC. I still
> don't know whether they (the hw csuming) should work only for IA64,
> I'm reading their man page.
The problem is really hard to track down. I haven't been able to
trigger it yet. It looks like as if there are many components involved.
We need to compile a list of problem cases, something like:
kernel | ipvs | NIC | driver |
hw_chksum
-----------+-------+-------------------+----------------------------+---
2.4.10-ac2 | 0.8.1 | ANA620xx (rev 03) | starfire.c:v1.03 7/26/2000 | no
-----------+-------+-------------------+----------------------------+---
Like this we can eventually find emerging patterns and narrow down the
potential cases. I also need to know if MII chip workaround is being
enabled due to a hardware bug (dmesg should show it). Another problem
we might face is the fast changing kernel series in 2.4.x. Linux must
be on speed right now.
> If these NIC drivers work with 0.9.4 then I really don't
> know where is the bug in IPVS 0.8.*. You better to use 0.9.4.
Yeah, if your workaround works, then we must start a blacklist or
see if we can talk to the drivers maintainer.
> With all these traps in the networking code, LVS should always receive
> CHECKSUM_NONE packets and so LVS is forced to make full packet check
> in LOCAL_IN. For the E100 driver a bad checksum results. So, I'm
> waiting for your feedback. I'm not able to debug the problem without
> such NIC. May be Ratz?
Yeah, I might get my hands dirty on such a test. I should have some
ANA69011A quadboards left and eepro100 can be found on almost any
board nowadays. Time is the only problem, unfortunately :(.
Hope we can find a solution for this nasty problem.
Best regards,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' |
dc
|
