[Linux-ia64] Problem with elilo 3.3a

[Linux-ia64] Problem with elilo 3.3a

[Sluder, Charles]

I keep seeing hangs in the SAL that I have traced back to a corrupted EFI
memory map. I was looking at the code for allocating the boot parameter
block in elilo and noticed this piece of code in bootparams.c

	/*
	 * Allocate memory for boot parameters.
	 * This CANNOT be EfiLoaderData or EfiLoaderCode as the kernel
	 * frees this region when initializing.
	 */

	bp = (boot_params_t *)alloc(BOOT_PARAM_MEMSIZE, EfiLoaderData);

The comment seems to be at odds with the code. Is this a problem with the
code or the comment?

-chuck

Charles Sluder
Unisys Corp.
Salt Lake City, UT

Re: [Linux-ia64] Problem with elilo 3.3a

[Stephane Eranian]

Charles,

On Thu, Feb 13, 2003 at 09:15:48PM -0600, Sluder, Charles wrote:
> I keep seeing hangs in the SAL that I have traced back to a corrupted EFI
> memory map. I was looking at the code for allocating the boot parameter
> block in elilo and noticed this piece of code in bootparams.c
> 
> 	/*
> 	 * Allocate memory for boot parameters.
> 	 * This CANNOT be EfiLoaderData or EfiLoaderCode as the kernel
> 	 * frees this region when initializing.
> 	 */
> 
> 	bp = (boot_params_t *)alloc(BOOT_PARAM_MEMSIZE, EfiLoaderData);
> 
> The comment seems to be at odds with the code. Is this a problem with the
> code or the comment?

The latter. The memory type is correct. In fact if you look everywhere
else in the code, you will see that we use EfiLoaderData.

You need to give some more information for us to help you here.

Note that the memory map itself IS NOT allocated inside the boot_param
structure. This structure only contains a pointer to it as well
as the size of the region. The map is dynamically allocated (in util.c).
The kernel (arch/ia64/kernel/setup.c) assumes all "valid" memory regions 
are free except for regions it knows about which are:
	- the boot param struct
	- the memory map (address in size in boot param struct)
	- initrd
	- command line string
	- kernel code and data

-- 
-Stephane

Re: [Linux-ia64] Problem with elilo 3.3a

[David Mosberger]

>>>>> On Thu, 13 Feb 2003 22:58:53 -0800, Stephane Eranian <eranian@frankl.hpl.hp.com> said:

  Stephane> Note that the memory map itself IS NOT allocated inside
  Stephane> the boot_param structure. This structure only contains a
  Stephane> pointer to it as well as the size of the region. The map
  Stephane> is dynamically allocated (in util.c).  The kernel
  Stephane> (arch/ia64/kernel/setup.c) assumes all "valid" memory
  Stephane> regions are free except for regions it knows about which
  Stephane> are: - the boot param struct - the memory map (address in
  Stephane> size in boot param struct) - initrd - command line string
  Stephane> - kernel code and data

That's not good.  The kernel assumes that the efi_memmap was copied
and happily scribbles over it.  I thought the bootloader used to make
a copy of the mem-map.  Am I misremembering?

	--david

Re: [Linux-ia64] Problem with elilo 3.3a

[Stephane Eranian]

David,

On Thu, Feb 13, 2003 at 11:09:03PM -0800, David Mosberger wrote:
> >>>>> On Thu, 13 Feb 2003 22:58:53 -0800, Stephane Eranian <eranian@frankl.hpl.hp.com> said:
> 
>   Stephane> Note that the memory map itself IS NOT allocated inside
>   Stephane> the boot_param structure. This structure only contains a
>   Stephane> pointer to it as well as the size of the region. The map
>   Stephane> is dynamically allocated (in util.c).  The kernel
>   Stephane> (arch/ia64/kernel/setup.c) assumes all "valid" memory
>   Stephane> regions are free except for regions it knows about which
>   Stephane> are: - the boot param struct - the memory map (address in
>   Stephane> size in boot param struct) - initrd - command line string
>   Stephane> - kernel code and data
> 
> That's not good.  The kernel assumes that the efi_memmap was copied
> and happily scribbles over it.  I thought the bootloader used to make
> a copy of the mem-map.  Am I misremembering?
> 
Let me clarify this. 

The bootloader obtains the memory map from EFI. The map is stored into a 
region specifically allocated by elilo. The bootparam structure passes 
the address of the table and its size to the kernel.

Looking at setup.c, when the kernel initializes the bootmem by
walking the EFI map, it makes sure to skip over the 5 or so regions I mentioned
(see free_available_memory). So the memory map region is preserved, i.e., not
included in the pool of free memory.


-- 
-Stephane

Re: [Linux-ia64] Problem with elilo 3.3a

[David Mosberger]

>>>>> On Thu, 13 Feb 2003 23:28:28 -0800, Stephane Eranian <eranian@frankl.hpl.hp.com> said:

  Stephane> The bootloader obtains the memory map from EFI. The map is
  Stephane> stored into a region specifically allocated by elilo. The
  Stephane> bootparam structure passes the address of the table and
  Stephane> its size to the kernel.

Ah, that's how I thought it worked.  I misunderstood your previous
mail (on re-reading it, it's clear though... ;-).

Thanks,

	--david

RE: [Linux-ia64] Problem with elilo 3.3a

[Sluder, Charles]

Thank you. That helps.

The corruption is occurring before the kernel starts executing. Just a guess
but it looks like the code that loaded the kernel may of stepped on the
firmware table.

This is a dump of the EFI memory map made with an ITP before the kernel
started executing.

-chuck


[P3]>ord8 r28 4
0x00000010fef9a008L ia64  00000010fef9df9e 000000007fa082e0
0x00000010fef9a018L ia64  00000010fef8c008 0000000000000630

[P3]>char 0x10fef8c008 256
0x00000010fef8c008L ia64  '................................................'
0x00000010fef8c038L ia64  '................................................'
0x00000010fef8c068L ia64  '..........................................shstrt'
0x00000010fef8c098L ia64  '....text................@...............__ksymta'
0x00000010fef8c0c8L ia64  '....A_64.................C..............ta..kstr'
0x00000010fef8c0f8L ia64  '.....opd..@.............;...............it..init'
0x00000010fef8c128L ia64  '.....ini................................data.cac'
0x00000010fef8c158L ia64  '....ne_a..t.............!...............bss.....'
0x00000010fef8c188L ia64  '................................................'
0x00000010fef8c1b8L ia64  '................................................'
0x00000010fef8c1e8L ia64  '........................:.......................'
0x00000010fef8c218L ia64  '........................f.......................'
0x00000010fef8c248L ia64  '......................'

[P3]>ord8 0x10fef8c008 128
0x00000010fef8c008L ia64  0000000000000004 0000000000000000
0x00000010fef8c018L ia64  0000000000000000 0000000000000001
0x00000010fef8c028L ia64  0000000000000009 0000000000000000
0x00000010fef8c038L ia64  0000000000000007 0000000000001000
0x00000010fef8c048L ia64  0000000000000000 0000000000000089
0x00000010fef8c058L ia64  0000000000000009 0000000000000000
0x00000010fef8c068L ia64  0000000000000004 000000000008a000
0x00000010fef8c078L ia64  0000000000000000 0000000000000016
0x00000010fef8c088L ia64  0000000000000009 7472747368732e00
0x00000010fef8c098L ia64  7478657400000005 00000000000c0000
0x00000010fef8c0a8L ia64  0000000000000000 0000000000000040
0x00000010fef8c0b8L ia64  8000000000000009 61746d79736b5f5f
0x00000010fef8c0c8L ia64  34365f4100000007 0000000000100000
0x00000010fef8c0d8L ia64  0000000000000000 0000000000004300
0x00000010fef8c0e8L ia64  0000000000000009 7274736b2e006174
0x00000010fef8c0f8L ia64  64706f2e00000002 0000000004400000
0x00000010fef8c108L ia64  0000000000000000 000000000000073b
0x00000010fef8c118L ia64  0000000000000009 74696e692e007469
0x00000010fef8c128L ia64  696e692e00000007 0000000004b3b000
0x00000010fef8c138L ia64  0000000000000000 000000000007ac10
0x00000010fef8c148L ia64  0000000000000009 6361632e61746164
0x00000010fef8c158L ia64  615f656e00000006 000000007f74b000
0x00000010fef8c168L ia64  0000000000000000 0000000000000421
0x00000010fef8c178L ia64  8000000000000009 0000000000737362
0x00000010fef8c188L ia64  0000000000000006 000000007fb6c000
0x00000010fef8c198L ia64  0000000000000000 0000000000000004
0x00000010fef8c1a8L ia64  8000000000000009 0000000000000000
0x00000010fef8c1b8L ia64  0000000000000006 000000007fb70000
0x00000010fef8c1c8L ia64  0000000000000000 0000000000000090
0x00000010fef8c1d8L ia64  8000000000000009 0000000000010000
0x00000010fef8c1e8L ia64  000000000000000d 000000007fc00000
0x00000010fef8c1f8L ia64  0000000000000000 000000000000003a
0x00000010fef8c208L ia64  8000000000000009 0000000000000006
0x00000010fef8c218L ia64  e000000000000007 000000007fc3a000
0x00000010fef8c228L ia64  0000000000000000 0000000000000266
0x00000010fef8c238L ia64  0000000000000009 0000000000000000
0x00000010fef8c248L ia64  0000000100000005 000000007fea0000
0x00000010fef8c258L ia64  0000000000000000 0000000000000008
0x00000010fef8c268L ia64  8000000000000009 0000000000000000

-----Original Message-----
From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
Sent: Friday, February 14, 2003 12:35 AM
To: eranian@hpl.hp.com
Cc: linux-ia64@linuxia64.org; David Mosberger
Subject: Re: [Linux-ia64] Problem with elilo 3.3a


>>>>> On Thu, 13 Feb 2003 23:28:28 -0800, Stephane Eranian
<eranian@frankl.hpl.hp.com> said:

  Stephane> The bootloader obtains the memory map from EFI. The map is
  Stephane> stored into a region specifically allocated by elilo. The
  Stephane> bootparam structure passes the address of the table and
  Stephane> its size to the kernel.

Ah, that's how I thought it worked.  I misunderstood your previous
mail (on re-reading it, it's clear though... ;-).

Thanks,

	--david

_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64

RE: [Linux-ia64] Problem with elilo 3.3a

[Sluder, Charles]

Looks like it might be a problem in EFI.  I traced through BS->GetMemMap()
and the corruption in the returned memory map are left over data in fields
that are not being filled in by the function call.

-chuck



-----Original Message-----
From: David Mosberger [mailto:davidm@napali.hpl.hp.com]
Sent: Friday, February 14, 2003 12:35 AM
To: eranian@hpl.hp.com
Cc: linux-ia64@linuxia64.org; David Mosberger
Subject: Re: [Linux-ia64] Problem with elilo 3.3a


>>>>> On Thu, 13 Feb 2003 23:28:28 -0800, Stephane Eranian
<eranian@frankl.hpl.hp.com> said:

  Stephane> The bootloader obtains the memory map from EFI. The map is
  Stephane> stored into a region specifically allocated by elilo. The
  Stephane> bootparam structure passes the address of the table and
  Stephane> its size to the kernel.

Ah, that's how I thought it worked.  I misunderstood your previous
mail (on re-reading it, it's clear though... ;-).

Thanks,

	--david

_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64

Re: [Linux-ia64] Problem with elilo 3.3a

[Stephane Eranian]

Charles,

On Sat, Feb 15, 2003 at 12:28:09AM -0600, Sluder, Charles wrote:
> Looks like it might be a problem in EFI.  I traced through BS->GetMemMap()
> and the corruption in the returned memory map are left over data in fields
> that are not being filled in by the function call.
> 

Can you verify that the address of the buffer used to store the map 
(and passed to GetMemMap()) is a valid area? If so, you may have
problems with your platform firmware.

-- 
-Stephane