> buhr@cs.wisc.edu (Kevin Buhr) writes:
> >
> > "Jon M. Taylor" <taylorj@ecs.csus.edu> writes:
> > >
> > > Sorry to ruin your theory, but I am also seeing the PPP checksum
> > > problems and I do not use SCSI anything nor VJ compression. In fact,
> > > ifconfig shows these errors on my eth0 (3COM 3C509 NIC) and loopback
> > > devices also. I have pppd 2.3.5 and the latest iptools, which I upgraded
> > > to in an attempt to fix this problem. Didn't help.
> >
> > There's not only one way to lose interrupts. I was losing them on my
> > IDE interface when I upgraded to a fast disk on my slow 486/33
> > machine. I had slews of checksum errors until I finally figured out
> > why it was happening, tried "hdparm -u1" to enable interrupts during
> > IDE transfers, and watched my checksum errors disappear.
>
> Following up to my own note, I see that I misread your response. Let
> me see if we can get this straight.
>
> First, restricting attention to the PPP interface, are you seeing
> "TCPv4 checksum" errors in the kernel logs, or are you seeing framing
> errors in "ifconfig" or "cat /proc/net/dev" output? The latter are
> not, strictly speaking, checksum errors; they are CRC errors at the
> PPP frame level, and one possible cause is lost interrupts resulting
> in dropped characters. They can occur with or without VJ compression.
I am seeing the latter.
> Second, if VJ compression is truly disabled, you should never see a
> TCP checksum error caused by packet corruption on the PPP link. This
> is because the PPP CRC check should fail, so the kernel will never see
> the corrupted packet. In this case, there will be no TCP checksum
> error, but there *will* be a framing error. If you do see TCP
> checksum errors but do *not* see framing errors, this is probably
> because some host or router is sending you corrupt packets.
Could be. But then why am I seeing errors on my eth0 and loopback
devices too?
> If you do see TCP checksum errors and you also see framing errors in
> roughly equal numbers then this is almost certainly because you have
> VJ compression enabled and the PPP link is corrupting packets. This
> is how VJ compression error recovery works: if there is a framing
> error, it will normally be followed by a TCP checksum error on the
> next packet. In this case, the advice I've given previously still
> holds; disabling VJ compression will mask the symptom, but you'll have
> to go interrupt hunting to cure the disease.
>
> Third, you should *certainly* not be seeing framing or other errors on
> the loopback device. Be warned that old versions of "ifconfig"
> misalign the columns while reading device information from newer
> kernels. They can print the number of packets as the number of
> errors. I suspect this is your problem with the loopback and network
> card devices. Check the output of "cat /proc/net/dev" instead.
Like I said, I upgraded my net-tools a couple weeks ago. I had
the same thought. Didn't help. I'll try looking at /proc/net/dev.
Jon
--- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html