|Summary:||xen kernel panic|
|Product:||[Fedora] Fedora||Reporter:||Need Real Name <lsof>|
|Component:||xen||Assignee:||Rik van Riel <riel>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-01-18 18:09:16 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Need Real Name 2005-10-30 22:17:07 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050923 Epiphany/1.6.5 Description of problem: Booting Xen gives me the following kernel panic: (XEN) ***** (XEN) Panic on CPU0: (XEN) Domain 0 allocation is too small for kernel image. (XEN) ***** (XEN) (XEN) Reboot in five seconds... Versions: kernel-xenU.i686 2.6.13-1.1532_FC4 xen.i386 3.0-0.20050912.fc4 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: x Additional info:
Comment 1 Need Real Name 2005-11-15 22:28:17 UTC
This is still broken, and fc5t1 is frozen now. Please could you tell me what the problem?
Comment 2 Need Real Name 2005-12-01 15:09:10 UTC
Lack of interest. Do you want this closed?
Comment 3 Stephen Tweedie 2006-01-18 18:03:35 UTC
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?