Description of problem: modprobe blkbk/netbk fails due to memory allocation failures Version-Release number of selected component (if applicable): 2.6.17-1.2566.fc6xen Additional info: FATAL: Error inserting blkbk (/lib/modules/2.6.17-1.2566.fc6xen/kernel/drivers/xen/blkback/blkbk.ko): Cannot allocate memory modprobe: page allocation failure. order:8, mode:0xd0 Call Trace: [<a00000010001c8c0>] show_stack+0x40/0xa0 sp=e00000001f3ffc20 bsp=e00000001f3f9230 [<a00000010001c950>] dump_stack+0x30/0x60 sp=e00000001f3ffdf0 bsp=e00000001f3f9218 [<a0000001000fdce0>] __alloc_pages+0x500/0x540 sp=e00000001f3ffdf0 bsp=e00000001f3f91a0 [<a0000001000fddd0>] __get_free_pages+0xb0/0x140 sp=e00000001f3ffe00 bsp=e00000001f3f9178 [<a0000001003b35c0>] balloon_alloc_empty_page_range+0x80/0x400 sp=e00000001f3ffe00 bsp=e00000001f3f9130 [<a0000002003cc190>] netback_init+0x190/0x440 [netbk] sp=e00000001f3ffe30 bsp=e00000001f3f90f8 [<a0000001000c5140>] sys_init_module+0x180/0x400 sp=e00000001f3ffe30 bsp=e00000001f3f9088 [<a0000001000140e0>] ia64_ret_from_syscall+0x0/0x40 sp=e00000001f3ffe30 bsp=e00000001f3f9088 [<a000000000010620>] __start_ivt_text+0xffffffff00010620/0x400 sp=e00000001f400000 bsp=e00000001f3f9088 Full log attached I believe this is fixed by http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?cs=bef360142b62 I'll follow up with confirmation on that after testing.
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.
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 xend script. This is basically the same problem as https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201796 which I think was closed prematurely.
A patch which should fix this has been committed upstream to xen-unstable and xen-3.0.3-testing: http://xenbits2.xensource.com/xen-3.0.3-testing.hg?cs=7efaaae3 Will review and merge.
Just to be clear, the changeset that you point out (11720) is only the last in the series, which includes: http://xenbits2.xensource.com/xen-3.0.3-testing.hg?cs=11714 http://xenbits2.xensource.com/xen-3.0.3-testing.hg?cs=11715 http://xenbits2.xensource.com/xen-3.0.3-testing.hg?cs=11716 http://xenbits2.xensource.com/xen-3.0.3-testing.hg?cs=11717 http://xenbits2.xensource.com/xen-3.0.3-testing.hg?cs=11719 http://xenbits2.xensource.com/xen-3.0.3-testing.hg?cs=11720
Yes, that's correct. And there's two smaller additional patches which help those six above apply more easily. I've got all eight, and they do fix the issue. Unfortunately for ia64, when a blkfront attaches to a blkback, the machine dies (I don't have console output to see what happens, I'm assuming dom0 kernel panics).
This bug is still in kernel-xen-2.6.18-1.2784.fc6 If set dom0_mem=1024M in elilo.conf can work around this issue.
in kernel-2.6.18-1.2728.el5
also fixed in rawhide on Oct. 13, this bug can be closed