[Xen-devel] Re: network misbehaviour with gplpv and 2.6.30

[Andrew Lyon <andrew.lyon@xxxxxxxxx>]

On Sat, Jul 18, 2009 at 4:42 AM, James
Harper<james.harper@xxxxxxxxxxxxxxxx> wrote:
> With GPLPV under 2.6.30, GPLPV gets the following from the ring:
>
> ring slot n (first buffer):
>  status (length) = 54 bytes
>  offset = 0
>  flags = NETRXF_extra_info (possibly csum too but not relevant)
> ring slot n + 1 (extra info)
>  gso.size (mss) = 1460
>
> Because NETRXF_extra_info is not set, that's all I get for that packet.
> In the IP header though, the total length is 1544 (which in itself is a
> little strange), but obviously I'm not getting a full packet, just the
> ETH+IP+TCP header.
>
> According to Andrew Lyon it works fine in previous versions, so this
> problem only arises on 2.6.30. I don't know if netfront on Linux suffers
> from a similar problem.
>
> I can't identify any changes that could cause this, but if the problem
> is in netback either the frags count isn't being set correctly, or
> skb->cb (which appears to be used temporarily to hold nr_frags) is
> becoming corrupt (set to 0) somehow, but the window where this could
> occur is very small and I can't see where it could happen.
>
> Any suggestions as to where to start looking?
>
> (one nice thing is that I have identified a crash that would occur when
> the IP header lied about its length!)
>
> Thanks
>
> James
>
>

James,

I tried using the 2.6.29 netback.c with 2.6.30, I had to change a
couple of calls to __mod_timer to use mod_timer instead but after that
it compiles and seems to work normally, but it does not get rid of the
problem.

I will keep trying to find the change that caused this problem.

Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel