Re: [Xen-devel] [Xen-users] kernel 3.9.2 - xen 4.2.2/4.3rc1 => BUG unable to handle kernel paging request netif_poll+0x49c/0xe8

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, May 21, 2013 at 10:55:00AM +0100, Jan Beulich wrote:
> >>> On 17.05.13 at 15:00, Eugene Istomin <e.istomin@xxxxxxx> wrote:
> > Bump, here it is:
> 
> Okay, but I think we're still lacking information on what your
> Dom0 kernel is.
> 
> Ian, Wei - looking at the forward ported as well as the upstream
> frontends, I'm wondering if there isn't a fundamental flaw in
> ..._get_responses(): It allows up to MAX_SKB_FRAGS + 1 slots/
> frags, and ..._fill_frags() then fills as many fragments as got
> queued onto the respective list. Only after both of them are done,
> __pskb_pull_tail() gets invoked reducing the fragment count by
> one if the condition is met that made ..._get_responses() bump
> the limit by one.
> 
> Am I overlooking something? I'm asking because working through
> disassembly and register values of the dump Eugene had sent I
> clearly see that ..._fill_frags() is processing the 18th fragment,

> while in that kernel version MAX_SKB_FRAGS is only 17 (but
> possibly, hence the first question above, the Dom0 kernel still is
> one with MAX_SKB_FRAGS being 18, or the packet turns out to

I have the same suspection. However I just did a quick hack to bump
MAX_SKB_FRAGS to 20 in backend, DomU worked just fine. 

> be such that it fills 17 fragments and the header is smaller than
> RX_COPY_THRESHOLD).

It would be better to know more info about Dom0. Will need some time to
figure out what's going on there.


Wei.

> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel