can't boot 2.6.0-test11

can't boot 2.6.0-test11

[Bill Nottingham]

Trying to boot a 2.6test ia64 kernel here, I'm getting:

Loadin vmlinux...Loading Linux... 
alloc.c(line 132):allocator: AllocatePages(2, 2, 3377699721561477, 0x40000000) failed (Not Found)
plain_loader.c(line 291):plain_elf64: AllocatePages(3377699721561477, 0x40000000) for kernel failed

Is the kernel just horribly misbuilt somehow, or is something else
going on?

Bill

Re: can't boot 2.6.0-test11

[Stephane Eranian]

Bill,

On Thu, Dec 04, 2003 at 04:56:20PM -0500, Bill Nottingham wrote:
> Trying to boot a 2.6test ia64 kernel here, I'm getting:
> 
> Loadin vmlinux...Loading Linux... 
> alloc.c(line 132):allocator: AllocatePages(2, 2, 3377699721561477, 0x40000000) failed (Not Found)
> plain_loader.c(line 291):plain_elf64: AllocatePages(3377699721561477, 0x40000000) for kernel failed
> 
> Is the kernel just horribly misbuilt somehow, or is something else
> going on?
> 
I saw your E-mail but I just did a bk pull frmo Linus's tree and I can't
even get my kernel to build using gcc-3.3.2. I get a lot of unwind related
errors:
arch/ia64/kernel/entry.S: Assembler messages:
arch/ia64/kernel/entry.S:118: Error: Operand to .fframe must be a constant
arch/ia64/kernel/entry.S:118: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)
arch/ia64/kernel/entry.S:118: Error:  Second operand not a valid constant
arch/ia64/kernel/entry.S:118: Error:  Second operand not a valid constant
arch/ia64/kernel/entry.S:118: Error: Second operand to .spillsp must be a constant
arch/ia64/kernel/entry.S:118: Error: Second operand to .spillsp must be a constant
arch/ia64/kernel/entry.S:118: Error: Second operand to .spillsp must be a constant


From your trace, it looks like your are trying to boot an uncompressed kernel.
What this intentional?

The AllocatePages() says you are trying to allocate 3377699721561477 4KB pages.
Clearly not something you want. Is the output of readelf -e on vmlinux decent?

-- 

-Stephane

Re: can't boot 2.6.0-test11

[Bill Nottingham]

Stephane Eranian (eranian@hpl.hp.com) said: 
> On Thu, Dec 04, 2003 at 04:56:20PM -0500, Bill Nottingham wrote:
> > Trying to boot a 2.6test ia64 kernel here, I'm getting:
> > 
> > Loadin vmlinux...Loading Linux... 
> > alloc.c(line 132):allocator: AllocatePages(2, 2, 3377699721561477, 0x40000000) failed (Not Found)
> > plain_loader.c(line 291):plain_elf64: AllocatePages(3377699721561477, 0x40000000) for kernel failed
> > 
> > Is the kernel just horribly misbuilt somehow, or is something else
> > going on?
> > 
> I saw your E-mail but I just did a bk pull frmo Linus's tree and I can't
> even get my kernel to build using gcc-3.3.2. I get a lot of unwind related
> errors:

I'm using 3.2.3, not 3.3.2. Dunno if that makes a big difference.

> From your trace, it looks like your are trying to boot an uncompressed kernel.
> What this intentional?

Both uncompressed and compressed fail in the same way, I was just debugging with
uncompressed.

> The AllocatePages() says you are trying to allocate 3377699721561477 4KB pages.
> Clearly not something you want. Is the output of readelf -e on vmlinux decent?

As much as I can tell, it is. Not that that means much from me.
Jakub found the following that probably is a bug, but applying the patch
doesn't help it boot:

--- linux-2.6.0-test11/arch/ia64/kernel/vmlinux.lds.S.foo	2003-12-04 17:16:36.000000000 -0500
+++ linux-2.6.0-test11/arch/ia64/kernel/vmlinux.lds.S	2003-12-04 17:08:55.000000000 -0500
@@ -151,7 +151,7 @@
 	{ *(.con_initcall.init) }
   __con_initcall_end = .;
   __security_initcall_start = .;
-  .security_initcall.init : AT(ADDR(.security_initcall.init) - PAGE_OFFSET)
+  .security_initcall.init : AT(ADDR(.security_initcall.init) - LOAD_OFFSET)
 	{ *(.security_initcall.init) }
   __security_initcall_end = .;
   . = ALIGN(PAGE_SIZE);

Bill

Re: can't boot 2.6.0-test11

[Bill Nottingham]

Bill Nottingham (notting@redhat.com) said: 
> > The AllocatePages() says you are trying to allocate 3377699721561477 4KB pages.
> > Clearly not something you want. Is the output of readelf -e on vmlinux decent?
> 
> As much as I can tell, it is. Not that that means much from me.

Comparing readelf output, one big difference is where it loads the
percpu data segment:

2.6.0-test11:

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000010000 0xa000000100000000 0x0000000004000000
                 0x00000000005a0c00 0x00000000005a0c00  RWE    10000
  LOAD           0x00000000005c0000 0xffffffffffff0000 0x00000000045b0000
                 0x00000000000084a8 0x00000000000084a8  RW     10000
  LOAD           0x00000000005d0000 0xa0000001005c0000 0x00000000045c0000
                 0x00000000000a3004 0x0000000000131e48  RW     10000
  IA_64_UNWIND   0x00000000004c8568 0xa0000001004b8568 0x00000000044b8568
                 0x0000000000029898 0x0000000000029898  R      8

 Section to Segment mapping:
  Segment Sections...
   00     .text __ex_table .data.patch.vtop .data.patch.mckinley_e9 .machvec .IA_64.unwind_info .IA_64.unwind .rodata __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings .opd .init.text .init.data .init.ramfs .init.setup .initcall.init .con_initcall.init .security_initcall.init .data.init_task .data.page_aligned .data.cacheline_aligned
   01     .data.percpu
   02     .data .got .sdata .sbss .bss
   03     .IA_64.unwind

2.5.64:

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000010000 0xe000000004400000 0x0000000004400000
                 0x00000000005dee80 0x00000000005dee80  RWE    10000
  LOAD           0x00000000005f0000 0xa000000000010000 0x00000000049e0000
                 0x0000000000002a60 0x0000000000002a60  RW     10000
  LOAD           0x0000000000600000 0xe0000000049f0000 0x00000000049f0000
                 0x000000000008a808 0x0000000000164790  RW     10000
  IA_64_UNWIND   0x00000000004e4898 0xe0000000048d4898 0x00000000048d4898
                 0x0000000000026fa0 0x0000000000026fa0  R      8

 Section to Segment mapping:
  Segment Sections...
   00     .text .text.lock __ex_table .IA_64.unwind_info .IA_64.unwind .rodata .opd .init.text .init.data .init.ramfs .init.setup .initcall.init .data.init_task .data.page_aligned .data.cacheline_aligned
   01     .data.percpu
   02     .data .got .sdata .sbss .bss
   03     .IA_64.unwind

Re: can't boot 2.6.0-test11

[David Mosberger]

>>>>> On Thu, 4 Dec 2003 14:06:29 -0800, Stephane Eranian <eranian@hpl.hp.com> said:

  Stephane> I saw your E-mail but I just did a bk pull frmo Linus's
  Stephane> tree and I can't even get my kernel to build using
  Stephane> gcc-3.3.2. I get a lot of unwind related errors:

  Stephane> arch/ia64/kernel/entry.S: Assembler messages:
  Stephane> arch/ia64/kernel/entry.S:118: Error: Operand to .fframe must be a constant

That's probably because the offsets.h file wasn't properly updated in your
tree (the kbuild environment is supposed to build it).

When in doubt, this is a good place to check the status of ia64 builds
from Linus' tree:

	http://www.gelato.unsw.edu.au/kerncomp/

  --david

Re: can't boot 2.6.0-test11

[David Mosberger]

>>>>> On Thu, 4 Dec 2003 16:56:20 -0500, Bill Nottingham <notting@redhat.com> said:

  Bill> Trying to boot a 2.6test ia64 kernel here, I'm getting:
  Bill> Loadin vmlinux...Loading Linux... 
  Bill> alloc.c(line 132):allocator: AllocatePages(2, 2, 3377699721561477, 0x40000000) failed (Not Found)
  Bill> plain_loader.c(line 291):plain_elf64: AllocatePages(3377699721561477, 0x40000000) for kernel failed

  Bill> Is the kernel just horribly misbuilt somehow, or is something else
  Bill> going on?

In case it helps, attached is what the program headers of a good
vmlinux-2.6.0-test11 kernel should look like.

	--david

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000010000 0xa000000100000000 0x0000000004000000
                 0x000000000082e9b0 0x000000000082e9b0  R E    10000
  LOAD           0x0000000000840000 0xa000000100830000 0x0000000004830000
                 0x000000000005cb80 0x000000000005cb80  RWE    10000
  LOAD           0x00000000008a0000 0xffffffffffff0000 0x0000000004890000
                 0x0000000000008428 0x0000000000008428  RW     10000
  LOAD           0x00000000008b0000 0xa0000001008a0000 0x00000000048a0000
                 0x0000000000169360 0x00000000001bc8b8  RW     10000
  IA_64_UNWIND   0x0000000000781c58 0xa000000100771c58 0x0000000004771c58
                 0x000000000002e5f0 0x000000000002e5f0  R      8

 Section to Segment mapping:
  Segment Sections...
   00     .text __ex_table .data.patch.vtop .data.patch.mckinley_e9 .IA_64.unwind_info .IA_64.unwind .rodata __ksymtab __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings .opd 
   01     .init.text .init.data .init.ramfs .init.setup __param .initcall.init .con_initcall.init .data.init_task .data.page_aligned .data.cacheline_aligned 
   02     .data.percpu 
   03     .data .got .sdata .sbss .bss 
   04     .IA_64.unwind 

Re: can't boot 2.6.0-test11

[David Mosberger]

>>>>> On Thu, 4 Dec 2003 17:25:28 -0500, Bill Nottingham <notting@redhat.com> said:

  Bill> Comparing readelf output, one big difference is where it loads
  Bill> the percpu data segment:

That should be OK though.  elilo only ever looks at the physical addresses.
Do you have a stale version of elilo by chance?

	--david

RE: can't boot 2.6.0-test11

[Luck, Tony]

What does:
	# objdump -fp vmlinux
say?

What version of elilo are you running? (Run "elilo -v" from the EFI prompt, I think).

-Tony

> -----Original Message-----
> From: linux-ia64-owner@vger.kernel.org
> [mailto:linux-ia64-owner@vger.kernel.org]On Behalf Of Bill Nottingham
> Sent: Thursday, December 04, 2003 1:56 PM
> To: linux-ia64@vger.kernel.org
> Subject: can't boot 2.6.0-test11
> 
> 
> Trying to boot a 2.6test ia64 kernel here, I'm getting:
> 
> Loadin vmlinux...Loading Linux... 
> alloc.c(line 132):allocator: AllocatePages(2, 2, 
> 3377699721561477, 0x40000000) failed (Not Found)
> plain_loader.c(line 291):plain_elf64: 
> AllocatePages(3377699721561477, 0x40000000) for kernel failed
> 
> Is the kernel just horribly misbuilt somehow, or is something else
> going on?
> 
> Bill
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: can't boot 2.6.0-test11

[Stephane Eranian]

On Thu, Dec 04, 2003 at 04:54:19PM -0800, Luck, Tony wrote:
> What does:
> 	# objdump -fp vmlinux
> say?
> 
> What version of elilo are you running? (Run "elilo -v" from the EFI prompt, I think).
> 
elilo -V (uppercase v) otherwise it means verbose.

-- 
-Stephane

RE: can't boot 2.6.0-test11

[Chen, Kenneth W]

2.6.0-test11 boots fine on my tiger4 machine, with or without David's
test11-ia64-031126 patch.  Apparently the prime suspect of "percpu data
segment" doesn't do any damage to me.

My readelf -e looks like:
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000010000 0xa000000100000000
0x0000000004000000
                 0x00000000004eef20 0x00000000004eef20  R E    10000
  LOAD           0x0000000000500000 0xa0000001004f0000
0x00000000044f0000
                 0x0000000000088b00 0x0000000000088b00  RWE    10000
  LOAD           0x0000000000590000 0xffffffffffff0000
0x0000000004580000
                 0x00000000000081d0 0x00000000000081d0  RW     10000
  LOAD           0x00000000005a0000 0xa000000100590000
0x0000000004590000
                 0x00000000000625e4 0x0000000000096dd8  RW     10000
  IA_64_UNWIND   0x00000000004801b0 0xa0000001004701b0
0x00000000044701b0
                 0x0000000000025e18 0x0000000000025e18  R      8


Bill Nottingham (notting@redhat.com) said: 
>> > The AllocatePages() says you are trying to allocate
3377699721561477
>> > 4KB pages. Clearly not something you want. Is the output of readelf
-e
>> > on vmlinux decent?
>> 
>> As much as I can tell, it is. Not that that means much from me.
>
>Comparing readelf output, one big difference is where it loads the
>percpu data segment:
>
>2.6.0-test11:
>
>Program Headers:
> Type           Offset             VirtAddr           PhysAddr
>                FileSiz            MemSiz              Flags  Align
> LOAD           0x0000000000010000 0xa000000100000000
0x0000000004000000
>                0x00000000005a0c00 0x00000000005a0c00  RWE    10000
> LOAD           0x00000000005c0000 0xffffffffffff0000
0x00000000045b0000
>                0x00000000000084a8 0x00000000000084a8  RW     10000
> LOAD           0x00000000005d0000 0xa0000001005c0000
0x00000000045c0000
>                0x00000000000a3004 0x0000000000131e48  RW     10000
> IA_64_UNWIND   0x00000000004c8568 0xa0000001004b8568
0x00000000044b8568
>                0x0000000000029898 0x0000000000029898  R      8

Re: can't boot 2.6.0-test11

[Bill Nottingham]

David Mosberger (davidm@napali.hpl.hp.com) said: 
>   Bill> Comparing readelf output, one big difference is where it loads
>   Bill> the percpu data segment:
> 
> That should be OK though.  elilo only ever looks at the physical addresses.
> Do you have a stale version of elilo by chance?

No, 3.4.

Bill

Re: can't boot 2.6.0-test11

[Bill Nottingham]

Luck, Tony (tony.luck@intel.com) said: 
> What does:
> 	# objdump -fp vmlinux
> say?

foo:     file format elf64-ia64-little
architecture: ia64-elf64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000004007f20
private flags = LE, CONS_GP, ABI64

Program Header:
    LOAD off    0x0000000000010000 vaddr 0xa000000100000000 paddr 0x0000000004000000 align 2**16
         filesz 0x00000000005a0c00 memsz 0x00000000005a0c00 flags rwx
    LOAD off    0x00000000005c0000 vaddr 0xffffffffffff0000 paddr 0x00000000045b0000 align 2**16
         filesz 0x00000000000084a8 memsz 0x00000000000084a8 flags rw-
    LOAD off    0x00000000005d0000 vaddr 0xa0000001005c0000 paddr 0x00000000045c0000 align 2**16
         filesz 0x00000000000a3004 memsz 0x0000000000131e48 flags rw-
0x70000001 off    0x00000000004c8568 vaddr 0xa0000001004b8568 paddr 0x00000000044b8568 align 2**3
         filesz 0x0000000000029898 memsz 0x0000000000029898 flags r--

> What version of elilo are you running? (Run "elilo -v" from the EFI prompt, I think).

3.4.

Bill

Re: can't boot 2.6.0-test11

[David Mosberger]

>>>>> On Thu, 4 Dec 2003 21:37:46 -0500, Bill Nottingham <notting@redhat.com> said:

  Bill> David Mosberger (davidm@napali.hpl.hp.com) said: Comparing
  Bill> readelf output, one big difference is where it loads the
  Bill> percpu data segment:
  >>  That should be OK though.  elilo only ever looks at the physical
  >> addresses.  Do you have a stale version of elilo by chance?

  Bill> No, 3.4.

Very odd.  It's most likely something in the toolchain, elilo, or
something in-between, but I can't think of what it is that might be
biting you.  Stephane probably can give you better suggestions on
turning on debug printing in elilo so you can see what's going on.

	--david

Re: can't boot 2.6.0-test11

[Bill Nottingham]

David Mosberger (davidm@napali.hpl.hp.com) said: 
> Very odd.  It's most likely something in the toolchain, elilo, or
> something in-between, but I can't think of what it is that might be
> biting you.  Stephane probably can give you better suggestions on
> turning on debug printing in elilo so you can see what's going on.

Oddly enough, all the kernels that have not been booting correctly
the past two days have suddenly decided to start booting without
errors.

I don't understand, but I'll take it.

Bill