[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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


> Jan

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.