On Fri, 2008-11-21 at 14:58 +0100, martin f krafft wrote: > Thanks Aioanei and Ben for your replies. Feels like we are getting > somewhere. > > > > also sprach Aioanei Rares <debian.dev.list@gmail.com> [2008.11.21.1353 +0100]: > > Can you reproduce on another version of the kernel or a vanilla? > > also sprach Ben Hutchings <ben@decadent.org.uk> [2008.11.21.1432 +0100]: > > This is a warning from the GSO (like TSO) code which only applies to > > outgoing traffic. > > I build vanilla 2.6.26.7 and 2.6.27.7 and tried them (using deb-pkg > target to create the .debs, and mkinitramfs to make the initrd). > > With 2.6.26.7, ethtool reports generic segmentation offload (GSO) to > be off, but it's on again with 2.6.27.7! As expected, the problem > does not appear with 2.6.26.7, but it does appear with 2.6.27.7. GSO is enabled by default in 2.6.27. It implements something like TSO (really delayed segmentation) for IPv4 and IPv6 for any device that supports TX checksum offload but not TSO. You later wrote: > Bastian Blank helpfully diagnosed the problem to be with the > forcedeth driver. He pointed me at commit edcfe5f[0], which should > be in 2.6.26.4, but apparently it's either not present in Debian's > 2.6.26-10 package, or it does not fix the bug entirely. I believe that bug would result in IPv6 packets being sent with incorrect checksums, and is entirely separate from this. GSO depends on TX checksum offload so it is automatically disabled when you disable TX checksum offload. It is only being used for IPv6 because the hardware implements TSO for IPv4. This could be a bug in the interaction of bridging or netfilter with GSO. Could you try to rule out either of those? Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo.
Attachment:
signature.asc
Description: This is a digitally signed message part