On 3/27/06, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote: > On 3/27/06, Phil Oester <[EMAIL PROTECTED]> wrote: > > David S. Miller wrote: > > > E1000 has some TSO bug most likely, try reproducing with > > > "ethtool -K eth0 tso off", replacing "eth0" with your actual > > > e1000 interface name(s). > > > > > That does seem to have solved the problem. > > > > Suggested next steps? Should I leave TSO disabled, or pester the e1000 > > maintainers? > > Both, probably 8)
I'm here, and pesterable. I don't understand the connection between the assertions mentioned and TSO. Can someone explain to me the possible relation of e1000 (and maybe TSO) and sk->sk_forward_alloc? I looked through the code and it appears that sk_forward_alloc tracks memory allocations (truesize) for sockets. Its not immediately clear whether its transmit or receive or both. I know I can't ask you to solve our bug, but I'm looking for some clues about a 1) reproducible bug 2) area of the driver I might look at (transmit or receive - TSO implies transmit, but we don't mess with truesize in transmit) The reports of this seem awful intermittent and on the surface it seems like a stack bug. I need some help connecting the dots. Thanks, Jesse - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
