From: Charles Duffy <cduffy@spamcop.net>
To: xen-devel@lists.xensource.com
Cc: "Mallick, Asit K" <asit.k.mallick@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: DomU panic in net_rx_action *initiated by another DomU*; 7503:20d1a79ebe31
Date: Wed, 02 Nov 2005 07:54:03 -0600 [thread overview]
Message-ID: <4368C4FB.2020509@spamcop.net> (raw)
In-Reply-To: <A95E2296287EAD4EB592B5DEEFCE0E9D32E6B7@liverpoolst.ad.cl.cam.ac.uk>
Ian Pratt wrote:
> I think this issue is at least approximately understood, and is present
> in all xen x86_64 kernels:
>
> rogue read-only mappings to linux heap pages left over from the 'initial
> mapping' are preventing the netfront driver unmapping pages to hand over
> as rx free buffers. This is compounded by the failure handling path
> being slightly borked.
I'm sorry to be a bother -- but is there any ETA on a fix, or a bugzilla
entry by which I can track this issue? The only netfront-related checkin
I see to bugzilla is a fix for bug#183, and that appears to be distinct
(I'm not getting the "#### netfront can't alloc rx grant refs", and so
would appear not to be hitting that code).
This is happening quite frequently for me, even when I'm *not* using the
kernel with the unstable module which triggers it every time.
If there is no bugzilla entry, I'd be glad to start one -- but since the
issue is described as already understood, it sounds like there's likely
already a bug for it that I'm just not seeing.
next prev parent reply other threads:[~2005-11-02 13:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-31 1:52 DomU panic in net_rx_action *initiated by another DomU*; 7503:20d1a79ebe31 Ian Pratt
2005-11-02 13:54 ` Charles Duffy [this message]
2005-11-02 14:15 ` Keir Fraser
-- strict thread matches above, loose matches on Subject: below --
2005-10-31 0:53 DomU panic in net_rx_action; changeset 7503:20d1a79ebe31 Charles Duffy
2005-10-31 1:25 ` DomU panic in net_rx_action *initiated by another DomU*; 7503:20d1a79ebe31 Charles Duffy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4368C4FB.2020509@spamcop.net \
--to=cduffy@spamcop.net \
--cc=asit.k.mallick@intel.com \
--cc=jun.nakajima@intel.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.