Bug 117689

Thanks for your report! 
 
I think this limitation should be reported to the Xen folks at  
xen-devel@lists.xensource.com and be docuemnted on their Wiki. 
If you don't want to do it yourself, please let me know. 
 
There is a PAE enabled Xen flavour that I have tested to work with > 4G, 
but I have not tested the non-PAE Xen with > 1GB yet. Will do. 
 
 

Does it really hang or is it "only" painful slow?

I've seen a machine become _very_ slow due to mtrr setup problems and some
memory area being used without cache because of that.

boot log for both cases (mem=1024m and without mem parameter), both xen and
linux kernel would be useful too.

Any news?

This bug is fixed on all of the machines I have tried it on.  We seem to be able to access all of the RAM on our 4 and 8 GB test machines.
Submitter: please reopen this bug if the latest bits do not fix this problem for your hardware.

Sorry, I didn't look at this E-Mail for quite a time ..

It works on my system, but I must use the debug-version xen-dbg.gz .

This is enough for me, so this entry could be closed. 
But I think you should know about this. Therefore I re-open.
 
Close this entry, as soon as you have recognized this.
(In my projects I do not take any look at solved cases)

What I did:
did an online update on this system. Xen stuff in /boot is now
from 26.1.2006:
    :
-rw-r--r--   1 root root  225105 Jan 26 20:12 xen-dbg-3.0_8259-0.1.gz
-rw-r--r--   1 root root  213949 Jan 26 20:14 xen-pae-3.0_8259-0.1.gz
-rw-r--r--   1 root root  205551 Jan 26 20:17 xen-3.0_8259-0.1.gz
    :



/boot/grub/menu.lst : (uncommented stuff caused hangs)
title Xen3 SUSE LINUX 10.0 1.5GB
    root (hd0,4)
#    kernel /boot/xen-pae-3.gz dom0_mem=1507328 acpi=off
#    kernel /boot/xen.gz dom0_mem=1507328 acpi=off
    kernel /boot/xen-dbg.gz dom0_mem=1507328 acpi=off
    module /boot/vmlinuz-xen root=/dev/hda5 vga=0x314 selinux=0 resume=/dev/hda6  splash=silent showopts
    module /boot/initrd-xen

many thanks for fixing,
Winfried

Hi Winfried,
Thanks a bunch for retesting that and getting back to us on it.  It looks like in the example you have shown that there may be a simple explanation.  The hypervisor requires a certain percentage of memory for it to use and run and so the total amount of memory available to Dom0 must be reduced by that amount. (not sure why the xen-dbg worked...)

Some simple things to try, if you haven't already, would be to 1) reduce dom0_mem to 1300M.  This would be high enough to prove that >1024 works for you and low enough to make sure you are under the max allowed. The other thing you could try would be to remove the dom0_mem command line option altogether.  When it is not specified xen takes what it needs and all of the rest should be allocated to Dom0.  To check, just run "xm list" when Dom0 boots and make sure Dom0 is >1024. (should be >1400)

Thanks again for verifying this for us,
Lynn

Hello Lynn,
I have come to re-test, here is the results:

The Hangs are usually in  "Setting up network interfaces " or
in message "Loading console font lat..."

In one of my hanging trials I forgot the machine for 15-20 minutes,
there was a xdm login prompt, but I had no keyboard, no touchpad
and even no network .

Here is my latest trials:
     :
# ### See /usr/share/doc/packages/xen/README.SuSE
title Xen3 SUSE LINUX 10.0 1.5GB
    root (hd0,4)
# hangs    kernel /boot/xen-pae-3.gz dom0_mem=1507328 acpi=off
# hangs    kernel /boot/xen.gz mem=1536M dom0_mem=1506304 acpi=off
# hangs    kernel /boot/xen.gz dom0_mem=1507328 acpi=off
# hangs    kernel /boot/xen.gz dom0_mem=1300M acpi=off
# hangs    kernel /boot/xen.gz acpi=off
# works    kernel /boot/xen.gz mem=1024M dom0_mem=983040 acpi=off
# works    kernel /boot/xen-dbg.gz dom0_mem=1507328 acpi=off
# works    kernel /boot/xen-dbg.gz acpi=off
    kernel /boot/xen-dbg.gz acpi=off
# hangs    kernel /boot/xen.gz mem=1500M acpi=off
# hangs    kernel /boot/xen.gz mem=1350M acpi=off

# boots normally, no network, no keyboard:
#          kernel /boot/xen.gz mem=1324M acpi=off

    module /boot/vmlinuz-xen root=/dev/hda5 vga=0x314 selinux=0    resume=/dev/h
da6  splash=silent showopts
    module /boot/initrd-xen

###Don't change this comment - YaST2 identifier: Original name: failsafe###



Another thing seen with /boot/xen-dbg.gz :

amilo:~ # uname -a
Linux amilo 2.6.13-15.8-xen #1 SMP Tue Feb 7 11:07:24 UTC 2006 i686 i686 i386 GNU/Linux
amilo:~ # xm list
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0     1409     1 r-----    47.1
amilo:~ #

xen-dbg.gz only has 1409M out of 1536M !

best regards,
Winfried

Ky, do you have the resources you need to investigate this one?

Lynn,
All the 32 bit machines I have have no more than 1gig of memory. Is this problem reproduceable in the lab. Looks like this particular bug has been around for a while and may infact be not the same problem - based on your comment #4 (2006/01/26, the original problem was not reproduceable. If you have the right HW in the lab, I can verify if the problem exists in the current build and look at fixing the problem.

Lynn,

I could not reproduce this bug on the 32 bit box in the Provo labs. Winfried, could you very if this is still a problem on your box. I am going to change the ststus to need info.

Lynn,

Let me know when you can get the pentium M board into a box with sufficient memory. I will attempt to reproduce the problem.

This appears to be fixed in SLES 10 beta 10 as we are unable to reproduce the bug on a Pentium M with 2G of memory.  Since we will not be fixing any more bugs related to Xen on SUSE 10.0 I am resolving this bug as fixed.

Winfried,
If you find that this same scenario fails for your machine on SuSE 10.0 or SLES 10 please enter a new bug and we will look into it.