Red Hat Bugzilla – Bug 210070
blkbk/netbk modules don't load
Last modified: 2007-11-30 17:07:35 EST
+++ This bug was initially created as a clone of Bug #202971 +++
Description of problem:
modprobe blkbk/netbk fails due to memory allocation failures
Version-Release number of selected component (if applicable):
FATAL: Error inserting blkbk
modprobe: page allocation failure. order:8, mode:0xd0
[<a0000002003cc190>] netback_init+0x190/0x440 [netbk]
Full log attached
I believe this is fixed by
I'll follow up with confirmation on that after testing.
-- Additional comment from email@example.com on 2006-09-14 15:31 EST --
Mentioned changeset doesn't fix this problem.
There are three ways to fix this problem:
(1) link blkback and netback into xen kernel statically instead of as modules.
(2) wait for upstream xen-ia64 to finish xencomm implementation (in progress)
(3) debug the balloon driver issues that cause this problem presently
Of these, I've been working on #3 but may not have a fix soon enough. I think
we should go ahead with #1 while we wait for #2 (which hopefully will be ready
for rhel5 release). Statically linking the blkback and netback modules has no
negative effect on domU, but it enables us to put more effort into testing
fedora/rhel5 xen/ia64, which we can't do well right now.
-- Additional comment from firstname.lastname@example.org on 2006-09-29 14:00 EST --
The xencomm implementation is nearly complete, but I misunderstood that it would
fix the problem. It seems that the real issue is that the netbk and blkbk
drivers need to be loaded ASAP in initramfs instead of deferring them to the
This is basically the same problem as
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201796 which I think was
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux release. Product Management has requested further review
of this request by Red Hat Engineering. This request is not yet committed for
inclusion in release.
This should be fixed when we rebase to 3.0.3
We are in a day for day slip for RHEL5 Beta2. I do not think we have a choice
other then to proceed with option 1 mentioned in the original problem report.
We don't need to do #1. This problem is already fixed in xen-3.0.3-testing.hg
upstream, and it's already fixed in Juan's tree because he's pulled the latest
bits. We're just waiting for that to bubble to RHEL5 now.
Additionally there is a workaround. Booting with dom0_mem=1G makes enough
physically contiguous space available to avoid the issue.
Rik is working on the xen 3.0.3-rc4 update for R5 B2.
I'm not entirely sure what changes were applied in 2.6.18-1.2728.el5 . . . QE
ack to taking the upstream xen patch. We need as much testing as possible on
This problem has been fixed for all architectures, ia64 included, since rhel5
rebased to xen-3.0.3 release. This bug can be closed.