xen/ia64 and elilo relocation

xen/ia64 and elilo relocation

[Arun Sharma]

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

Re: xen/ia64 and elilo relocation

[Stephane Eranian]

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

Re: xen/ia64 and elilo relocation

[Arun Sharma]

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

Re: xen/ia64 and elilo relocation

[Stephane Eranian]

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 know

I 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

Re: xen/ia64 and elilo relocation

[Arun Sharma]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

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


[-- Attachment #2: debug.txt --]
[-- Type: text/plain, Size: 8736 bytes --]

elilo -D -vvvvv xen
elilo.c(line 536):Optind=3 optarg=0 argc=4
localfs.c(line 241):size=8
alloc.c(line 110):alloc: allocated 8 bytes @[0x3C933588-0x3C933590]

alloc.c(line 110):alloc: allocated 64 bytes @[0x3C933688-0x3C9336C8]

attached vfat to Acpi(PNP0A03,1)/Pci(1F|0)/Pci(2|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig6260F069-281B-4B48-85FD-7E1DC80C5DDB)
netfs.c(line 733):size=8
alloc.c(line 110):alloc: allocated 8 bytes @[0x3C933608-0x3C933610]

alloc.c(line 110):alloc: allocated 1304 bytes @[0x3C8D7608-0x3C8D7B20]

attached netfs to Acpi(PNP0A03,0)/Pci(1E|0)/Pci(0|0)/Mac(0007E9D814DA)
fileops.c(line 505):found 2 filesystems
alloc.c(line 110):alloc: allocated 96 bytes @[0x3C933508-0x3C933568]

alloc.c(line 110):alloc: allocated 8 bytes @[0x3C933408-0x3C933410]

alloc.c(line 110):alloc: allocated 136 bytes @[0x3C931E08-0x3C931E90]

fileops.c(line 454):dev000 :     vfat : Acpi(PNP0A03,1)/Pci(1F|0)/Pci(2|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig6260F069-281B-4B48-85FD-7E1DC80C5DDB)

alloc.c(line 165):free: Pool @0x3C933408 size=8

alloc.c(line 110):alloc: allocated 8 bytes @[0x3C933408-0x3C933410]

alloc.c(line 110):alloc: allocated 136 bytes @[0x3C931D08-0x3C931D90]

fileops.c(line 454):dev001 :    netfs : Acpi(PNP0A03,0)/Pci(1E|0)/Pci(0|0)/Mac(0007E9D814DA)

alloc.c(line 165):free: Pool @0x3C933408 size=8

devname scheme: simple
glue_localfs.c(line 91):localfs_default_path=\EFI\redhat\

Default config: elilo.conf
Default_kernel: vmlinux
trying config file elilo.conf
fileops.c(line 261):fops_open(elilo.conf), dev::
fileops.c(line 279):dev:: fullname:elilo.conf: name:elilo.conf: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\elilo.conf

alloc.c(line 110):alloc: allocated 5672 bytes @[0x3C8D4008-0x3C8D5630]

config.c(line 482):must do image on vmlinuz-2.6.9-5.EL
alloc.c(line 110):alloc: allocated 5672 bytes @[0x3C8D2008-0x3C8D3630]

config.c(line 482):must do image on vmlinuz-mcmt
alloc.c(line 110):alloc: allocated 5672 bytes @[0x3C8D0008-0x3C8D1630]

config.c(line 482):must do image on xen
config.c(line 912):done parsing config file

trying chooser simple
trying chooser textmenu
selected chooser simple
Trying FPSWA driver scsi0:\efi\intel firmware\fpswa.efi....starting..failed (Already started)
config.c(line 1052):label xen: kname=xen options= nomca console=ttyS1,57600 root=/dev/sda2 ro initrd=xenlinux
kernel     is  'xen'
arguments  are ' nomca console=ttyS1,57600 root=/dev/sda2 ro'
initrd      is 'xenlinux'
ELILO
fileops.c(line 261):fops_open(xen), dev::
fileops.c(line 279):dev:: fullname:xen: name:xen: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\xen

fileops.c(line 261):fops_open(xen), dev::
fileops.c(line 279):dev:: fullname:xen: name:xen: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\xen

fileops.c(line 261):fops_open(xen), dev::
fileops.c(line 279):dev:: fullname:xen: name:xen: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\xen

plain_loader.c(line 83):class=2 type=2 data=1 machine=50

Using plain_elf64 loader
fileops.c(line 261):fops_open(xen), dev::
fileops.c(line 279):dev:: fullname:xen: name:xen: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\xen

Loading xen...plain_loader.c(line 83):class=2 type=2 data=1 machine=50

ELF file is little endian
Entry point 0x4008340
4 program headers
30 segment headers
plain_loader.c(line 208):plain_elf64 : phdrs allocate 224 bytes sizeof=56 entsize=56

alloc.c(line 110):alloc: allocated 224 bytes @[0x3C931C08-0x3C931CE8]

plain_loader.c(line 240):Phdr 1 paddr [0x4000000-0x407C000] offset 32768 filesz 507904 memsz=507904 bss_sz=0 p_type=1

plain_loader.c(line 240):Phdr 2 paddr [0x4080000-0x40801E8] offset 540672 filesz 488 memsz=488 bss_sz=0 p_type=1

plain_loader.c(line 240):Phdr 3 paddr [0x4090000-0x4096680] offset 541160 filesz 26240 memsz=78104 bss_sz=51864 p_type=1

plain_loader.c(line 240):Phdr 4 paddr [0x4051228-0x40550C8] offset 365096 filesz 16032 memsz=16032 bss_sz=0 p_type=1879048193

Lowest PhysAddr: 0x4000000
TotalMemSize:667928 bytes (164 pages)
Kernel entry @ 0x4008340
alloc.c(line 142):allocator: allocated 164 pages @0x4000000

Press any key to interrupt

off=288 poffs=32768 size=32480

Header #0
offset 32768
Phys addr 0x4000000
BSS size 0 bytes
skip=32480 offs=32768
|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b
off=540672 poffs=540672 size=0

Header #1
offset 540672
Phys addr 0x4080000
BSS size 0 bytes
skip=0 offs=540672
|\b
off=541160 poffs=541160 size=0

Header #2
offset 541160
Phys addr 0x4090000
BSS size 51864 bytes
skip=0 offs=541160
|\b/\balloc.c(line 165):free: Pool @0x3C931C08 size=224

..done
kernel loaded in [0x4000000-0x40A4000] entry=0x4008340
fileops.c(line 261):fops_open(xenlinux), dev::
fileops.c(line 279):dev:: fullname:xenlinux: name:xenlinux: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\xenlinux

initrd.c(line 60):initrd_open xenlinux worked
alloc.c(line 142):allocator: allocated 2855 pages @0x3BDA9000

initrd: total_size: 11690707 bytes base: 0x3BDA9000 pages 2855
Loading initrd xenlinux...|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\b|\b/\b-\b\\binitrd.c(line 90):read initrd(xenlinux) failed: 1
alloc.c(line 165):free: Page @0x3BDA9000 size=2855

command list (must be first character):
=:print device list, %:print variable list, &:print paths, ?:help
TAB:print label information
default file path: scsi0:\EFI\redhat\
config file      : \EFI\redhat\elilo.conf

ELILO boot: xen
config.c(line 1052):label xen: kname=xen options= nomca console=ttyS1,57600 root=/dev/sda2 ro initrd=xenlinux
kernel     is  'xen'
arguments  are ' nomca console=ttyS1,57600 root=/dev/sda2 ro'
initrd      is 'xenlinux'
fileops.c(line 261):fops_open(xen), dev::
fileops.c(line 279):dev:: fullname:xen: name:xen: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\xen

fileops.c(line 261):fops_open(xen), dev::
fileops.c(line 279):dev:: fullname:xen: name:xen: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\xen

fileops.c(line 261):fops_open(xen), dev::
fileops.c(line 279):dev:: fullname:xen: name:xen: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\xen

plain_loader.c(line 83):class=2 type=2 data=1 machine=50

Using plain_elf64 loader
fileops.c(line 261):fops_open(xen), dev::
fileops.c(line 279):dev:: fullname:xen: name:xen: f=0
localfs.c(line 95):localfs_open on \EFI\redhat\xen

Loading xen...plain_loader.c(line 83):class=2 type=2 data=1 machine=50

ELF file is little endian
Entry point 0x4008340
4 program headers
30 segment headers
plain_loader.c(line 208):plain_elf64 : phdrs allocate 224 bytes sizeof=56 entsize=56

alloc.c(line 110):alloc: allocated 224 bytes @[0x3C931C08-0x3C931CE8]

plain_loader.c(line 240):Phdr 1 paddr [0x4000000-0x407C000] offset 32768 filesz 507904 memsz=507904 bss_sz=0 p_type=1

plain_loader.c(line 240):Phdr 2 paddr [0x4080000-0x40801E8] offset 540672 filesz 488 memsz=488 bss_sz=0 p_type=1

plain_loader.c(line 240):Phdr 3 paddr [0x4090000-0x4096680] offset 541160 filesz 26240 memsz=78104 bss_sz=51864 p_type=1

plain_loader.c(line 240):Phdr 4 paddr [0x4051228-0x40550C8] offset 365096 filesz 16032 memsz=16032 bss_sz=0 p_type=1879048193

Lowest PhysAddr: 0x4000000
TotalMemSize:667928 bytes (164 pages)
Kernel entry @ 0x4008340
ConvertPages: Incompatible memory types
plain_loader.c(line 292):relocation is disabled, cannot load kernel
alloc.c(line 165):free: Pool @0x3C931C08 size=224

alloc.c(line 165):free: Pool @0x3C933508 size=96

uninstalled vfat on Acpi(PNP0A03,1)/Pci(1F|0)/Pci(2|0)/Scsi(Pun0,Lun0)/HD(Part1,Sig6260F069-281B-4B48-85FD-7E1DC80C5DDB)
alloc.c(line 165):free: Pool @0x3C933688 size=64

alloc.c(line 165):free: Pool @0x3C933588 size=8

uninstalled netfs on Acpi(PNP0A03,0)/Pci(1E|0)/Pci(0|0)/Mac(0007E9D814DA)
alloc.c(line 165):free: Pool @0x3C8D7608 size=1304

alloc.c(line 165):free: Pool @0x3C933608 size=8

alloc.c(line 197):free_all pages @ 0x4000000

alloc.c(line 197):free_all pool @ 0x3C8D0008

alloc.c(line 197):free_all pool @ 0x3C8D2008

alloc.c(line 197):free_all pool @ 0x3C8D4008

alloc.c(line 197):free_all pool @ 0x3C931D08

alloc.c(line 197):free_all pool @ 0x3C931E08

alloc.c(line 197):free_all pool @ 0x3C933708

alloc.c(line 197):free_all pool @ 0x3C933788

alloc.c(line 197):free_all pool @ 0x3C933808

alloc.c(line 197):free_all pool @ 0x3C933888

alloc.c(line 197):free_all pool @ 0x3C933908

alloc.c(line 228):free_kmem before (4000000, 164)

alloc.c(line 234):free_kmem after (0, 0)

Exit status code: Load Error

Re: xen/ia64 and elilo relocation

[Stephane Eranian]

[-- Attachment #1: Type: text/plain, Size: 380 bytes --]

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.


[-- Attachment #2: elilo-initrd.diff --]
[-- Type: text/plain, Size: 424 bytes --]

--- 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; 

Re: xen/ia64 and elilo relocation

[Stephane Eranian]

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

Re: xen/ia64 and elilo relocation

[Arun Sharma]

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

Re: xen/ia64 and elilo relocation

[Brett Johnson]

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