Bug 172406
Summary: | Xen Domain0 Fails To Boot - Not Enough Memory | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | jon westlake <jonathanwestlake> |
Component: | xen | Assignee: | Rik van Riel <riel> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 4 | CC: | aph, bugz, gert, hoffmann, lsof, maxx, ruaidhri, sct, sta040 |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-24 20:12:33 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
jon westlake
2005-11-03 22:45:56 UTC
I have duplicated this on my box, kernel-xen0-2.6.13-1.1532_FC4 & kernel-xenU-2.6.13-1.1532_FC4. 2.6.12-1.1454_FC4.i686.rpm does boot, but networking is nonfunctional. It seems that although the box does transmit correctly and I can verify that by looking at a tcpdump on another box, no packets are received. My dmesg contains this: e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation e100: eth0: e100_probe: addr 0xcfe00000, irq 16, MAC addr 00:90:27:8C:D8:19 ... e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex ... eth0: no IPv6 routers present e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex eth0: no IPv6 routers present e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex eth0: no IPv6 routers present e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex eth0: no IPv6 routers present device eth0 entered promiscuous mode NETDEV WATCHDOG: eth0: transmit timed out e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex FWIW I was able to reproduce Andrew's situation and can confirm that: kernel-xen0.i686 2.6.13-1.1532_FC4 updates-releasedkernel-xenU.i686 2.6.13-1.1532_FC4 updates-releasedxen.i386 2-20050823 ... will fail to boot up with an error message of "Domain 0 allocation is too small for kernel" Following the advice on the Fedora Xen Quickstart (http://www.fedoraproject.org/wiki/FedoraXenQuickstart#head-3a85df2e27189c12a2b8f045bfef3b2a759bb2ef) I also installed: kernel-xen0.i686 2.6.12-1.1454_FC4 kernel-xenU.i686 2.6.12-1.1454_FC4 xen.i386 3.0-0.20050912.fc4 ... and I also have no networking, although in my case it doesn't seem to even try to come up, and none of my prodding so far has gotten anything resembling a network connection to come up. I can also confirm this problem. Is there going to be an update on how to fix it? Just like Tim I tried the kernel from the current yum repository as well as the one suggested in the Fedora Xen Quickstart: "2.6.12-1.1456_FC4xen0 has been known to work with the xen RPM available from [WWW] Riel's homepage" However, the kernel listed here is not 2.6.12-1.1456_FC4xen0 but 2.6.12-1.1454_FC4 Is somebody working on this issue? Same problem here.... I tried the alternative kernels as in the advice of the FC Xen QS. But I had to compile a kernelmodule for a Areca Sata controller. De building works without an error (after fixed the asm linking). Also created a new initrd. But after a reboot the new made kernelmodule fails. BTW no error for the memory problem. *** Bug 172079 has been marked as a duplicate of this bug. *** re comment #2: the networking issue is very different; if you can still reproduce that, please open a separate bug for it. (I suspect it may be the issue described in bug 177794.) There has been a significant rebasing of the kernel and HV images for fc5t2. Can you still reproduce the problem? If so, then this sounds like a mismatch between the memory calculations in the HV/bootloader and the kernel. The full Xen logs would be really useful in tracking this down; is it possible for you to capture that to a serial console? That, in conjunction with the normal non-xen boot logs, should let us examine the memory maps being computed in both cases to see if there's a mismatch somewhere. You _may_ be able to work around this by adding the "dom0_mem=...M" option to the xen hypervisor line ("kernel=xen...") in /etc/grub.conf. If you assign (say) only half your physical memory to dom0 on boot, does that work? *** Bug 170163 has been marked as a duplicate of this bug. *** The FC5test* / rawhide kernels should fix this bug; please reopen if it recurs. |