I noticed that elilo occassionally loads xen/ia64 at: 0x14000000 instead of the usual 0x4000000 (especially if you interrupt the loading process by pressing a key). This results in TR map setup from: fffc000014000000 (virtual) -> 0x4000000 (physical). Further, __alloc_bootmem() gives out fffc000004000000 as free memory and memsets it to 0. Now xen is going to insert a second TC from fffc000004000000 (virtual) -> 0x4000000 (physical) i.e. we have two virtual addresses mapping to the same physical address. The memset essentially corrupts xen''s text. We have to figure out a way of telling elilo to always load xen at the same physical address. I thought the relocatable flag was off by default? -Arun ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Arun, sorry for the delay I was travelling. On Wed, Feb 16, 2005 at 05:53:23PM -0800, Arun Sharma wrote:> > I noticed that elilo occassionally loads xen/ia64 at: 0x14000000 instead of > the usual > 0x4000000 (especially if you interrupt the loading process by pressing a > key). >elilo loads each block of text/data at the address indicated by the paddr of the corresponding program header. Are you saying that the address is different only when you abort a load? Note that when an EFI program terminates, the memory is not freed. If we do not cleanly free the memory on load abort, then it is possible that the designated memory address is unavailable. I quickly checked the source code and elilo does not try to relocate unless the option "relocatable " is specified either globally in elilo.conf or on the Xen image. I also checked the abort case and elilo does free the memory allocated for the kernel, as such you should be able to retry. You can try forcing elilo-3.4/ia64/config.c:ia64_can_relocate() to return 0 just to make sure this is not the source of the problem.> This results in TR map setup from: fffc000014000000 (virtual) -> 0x4000000 > (physical). > Further, __alloc_bootmem() gives out fffc000004000000 as free memory and > memsets it to 0. Now xen is going to insert a second TC from > fffc000004000000 (virtual) -> 0x4000000 (physical) i.e. we have two virtual > addresses mapping to the same physical address. > > The memset essentially corrupts xen''s text. > > We have to figure out a way of telling elilo to always load xen at the same > physical address. I thought the relocatable flag was off by default? > > -Arun-- -Stephane ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Stephane Eranian wrote: Hi Stephane,> elilo loads each block of text/data at the address indicated by the > paddr of the corresponding program header. > > Are you saying that the address is different only when you abort a load?Yes, that''s right. Other missing piecees of info: - I was using the elilo shipped with a RHEL4 beta - my elilo.conf: image=xen label=xen initrd=xenlinux read-only append="nomca console=ttyS1,57600 root=/dev/sda2" xenlinux is a large uncompressed binary - so it''s easy to hit space to abort it''s loading.> Note that when an EFI program terminates, the memory is not freed. If we do > not cleanly free the memory on load abort, then it is possible that the > designated memory address is unavailable.elilo.efi didn''t exit yet. It dropped me back to the elilo: prompt to let me choose an image. I chose the same image a second time and this time I saw xen getting loaded at a different address.> I quickly checked the source code > and elilo does not try to relocate unless the option "relocatable " is specified > either globally in elilo.conf or on the Xen image. I also checked the abort > case and elilo does free the memory allocated for the kernel, as such you should > be able to retry.Someone suggested that the RHEL4 elilo turns relocation on by default to support SGI boxes. I''m not sure if it does that by adding a relocatable flag to elilo.conf or by changing the code. I checked the SRPM and the fedora cvs and can''t find a patch which touches the code.> > You can try forcing elilo-3.4/ia64/config.c:ia64_can_relocate() to return 0 > just to make sure this is not the source of the problem. >Yes, I''ll check this and let you know. -Arun ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
Arun, On Mon, 2005-02-21 at 22:26 -0800, Arun Sharma wrote:> Stephane Eranian wrote: > > > elilo loads each block of text/data at the address indicated by the > > paddr of the corresponding program header. > > > > Are you saying that the address is different only when you abort a load? > > Yes, that''s right. Other missing pieces of info: > > - I was using the elilo shipped with a RHEL4 beta > - my elilo.conf: > > image=xen > label=xen > initrd=xenlinux > read-only > append="nomca console=ttyS1,57600 root=/dev/sda2" > > xenlinux is a large uncompressed binary - so it''s easy to hit space to > abort it''s loading. >Ok, this means it is using the plain_loader.c. But that should not really matter.> > Note that when an EFI program terminates, the memory is not freed. If we do > > not cleanly free the memory on load abort, then it is possible that the > > designated memory address is unavailable. > > elilo.efi didn''t exit yet. It dropped me back to the elilo: prompt to > let me choose an image. I chose the same image a second time and this > time I saw xen getting loaded at a different address. >If you abort from the plain loader, you do a free_kmem() call. As such the memory should be freed, unless there is something broken in the alloc.c:free() code. You could try enabling debug by adding "debug" to your elilo.conf. Careful, though, as you will get tons of debug printfs.> > I quickly checked the source code > > and elilo does not try to relocate unless the option "relocatable " is specified > > either globally in elilo.conf or on the Xen image. I also checked the abort > > case and elilo does free the memory allocated for the kernel, as such you should > > be able to retry. > > Someone suggested that the RHEL4 elilo turns relocation on by default to > support SGI boxes. I''m not sure if it does that by adding a relocatable > flag to elilo.conf or by changing the code. I checked the SRPM and the > fedora cvs and can''t find a patch which touches the code. >That would be ok if the free logic works. You would be able to get the same region of memory.> > > > You can try forcing elilo-3.4/ia64/config.c:ia64_can_relocate() to return 0 > > just to make sure this is not the source of the problem. > > > > Yes, I''ll check this and let you knowI suggest checking the free() code. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On 2/22/2005 8:50 AM, Stephane Eranian wrote:> Arun, > > On Mon, 2005-02-21 at 22:26 -0800, Arun Sharma wrote: >> Stephane Eranian wrote: >> >> > elilo loads each block of text/data at the address indicated by the >> > paddr of the corresponding program header. >> > >> > Are you saying that the address is different only when you abort a load? >> >> Yes, that''s right. Other missing pieces of info: >> >> - I was using the elilo shipped with a RHEL4 beta >> - my elilo.conf: >> >> image=xen >> label=xen >> initrd=xenlinux >> read-only >> append="nomca console=ttyS1,57600 root=/dev/sda2" >> >> xenlinux is a large uncompressed binary - so it''s easy to hit space to >> abort it''s loading. >> > Ok, this means it is using the plain_loader.c. But that should not > really matter. >Murphy''s law. Now that I''m trying to debug, I can''t reproduce the problem any more. Non debug: startup.nsh> elilo xen ELILO Loading xen.....done Loading initrd xenlinux...initrd.c(line 90):read initrd(xenlinux) failed: 1 ELILO boot: xen Loading xen...ConvertPages: Incompatible memory types plain_loader.c(line 292):relocation is disabled, cannot load kernel Exit status code: Load Error Debug output is also attached. One thing I noticed is that if the loading of initrd (xenlinux) fails, the memory for initrd is freed, but the memory for the main image (xen) is not freed? -Arun
Arun,> One thing I noticed is that if the loading of initrd (xenlinux) fails, the > memory for initrd is freed, but the memory for the main image (xen) is not > freed? >I think that''s probably it. I don''t know what I put that comment that says "free_kmem() responsibility of loader". Well, load_initrd() does not free on abort. You should try the attached patch. Thanks.
On Wed, Feb 23, 2005 at 02:20:17PM -0800, Arun Sharma wrote:> On 2/23/2005 12:54 PM, Stephane Eranian wrote: > > >--- elilo-3.4/elilo.c 2003-08-29 10:41:38.000000000 -0700 > >+++ elilo-3.4-new/elilo.c 2005-02-23 12:51:38.000000000 -0800 > >@@ -123,8 +123,7 @@ > > case ELILO_LOAD_ERROR: > > goto exit_error; > > case ELILO_LOAD_ABORTED: > >- /* the free_kmem() is the responsibility of > >the loader */ > >- > >+ free_kmem(); > > /* we drop initrd in case we aborted the > > load */ > > elilo_opt.initrd[0] = CHAR_NULL; > > elilo_opt.prompt = 1; > > Works for me. Thanks Stephane!Excellent. Brett, could you integrate this patch into your tree? Thanks. -- -Stephane ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On 2/23/2005 12:54 PM, Stephane Eranian wrote:> --- elilo-3.4/elilo.c 2003-08-29 10:41:38.000000000 -0700 > +++ elilo-3.4-new/elilo.c 2005-02-23 12:51:38.000000000 -0800 > @@ -123,8 +123,7 @@ > case ELILO_LOAD_ERROR: > goto exit_error; > case ELILO_LOAD_ABORTED: > - /* the free_kmem() is the responsibility of the loader */ > - > + free_kmem(); > /* we drop initrd in case we aborted the load */ > elilo_opt.initrd[0] = CHAR_NULL; > elilo_opt.prompt = 1;Works for me. Thanks Stephane! -Arun ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel
On Wed, 2005-02-23 at 14:01 -0800, Stephane Eranian wrote:>Brett, could you integrate this patch into your tree?Wow, I''m gone for one week, and there is more elilo-related activity than I''ve seen in the past year! ;) Anyway Stephane, thanks for figuring out & fixing the problem! I''ve applied your patch to top-of-trunk CVS at elilo.sourceforge.net. -- Brett Johnson <brett@hp.com> - t r e v n i - ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel