mptable and redhat 8 and wotta mess.

[Ronald G. Minnich]

If I build linuxbios with gcc 2.96, things get marginally better. But 
weirder.

Linux version 2.4.19-lanl.18beoboot (root@butthead) (gcc version 2.96 
20000731 (Red Hat Linux 7.3 2.96-112)) #1 Fri Aug 16 15:03:04 MDT 2002 
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
 BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
 BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
 BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
Warning only 896MB will be used.
Use a PAE enabled kernel.
896MB LOWMEM available.
hm, page 00000000 reserved twice.
On node 0 totalpages: 229376

note that it is still not seeing the MP table.

But later on:

PCI: Discovered primary peer bus 10 [IRQ]
PCI: Discovered primary peer bus 11 [IRQ]
PCI: Discovered primary peer bus 12 [IRQ]
PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
PCI: Found IRQ 11 for device 00:1d.0
PCI: Sharing IRQ 11 with 07:01.0
PCI: Found IRQ 5 for device 00:1f.1
PCI: Found IRQ 3 for device 00:1f.3
PCI: Found IRQ 7 for device 02:01.0

So how is it getting this info? I am now getting confused.

nevertheless it does get the new kernel fine over the myrinet. The ram map 
still looks like this:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
 BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
 BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
 BIOS-e820: 0000000100000000 - 0000000120000000 (usable)

Note also that the RAM map shows (for this newer linuxbios) a big hole in 
the ram map. 2.4.19 doesn't seem to be able to handle this, more below:

Warning only 4GB will be used.
Use a PAE enabled kernel.
3200MB HIGHMEM available.

OOPS! There's only 1024 MB but the kernel is doing something odd.

Now the older linuxbios (a version from LNXI that says 1.0.0.6) show this 
for the ram map:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 0000000000000b54 (reserved)
 BIOS-e820: 0000000000000b54 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
 BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
128MB HIGHMEM available.
896MB LOWMEM available.

And this works.

So, that's the state of play: linuxbios is now producing e820 maps that 
2.4.19 doesn't seem to be able to handle; something is somehow trashing 
the MP table (etherboot); and, in general, things on e7500 are not 
currently working.

More later.

ron

"Ronald G. Minnich"  writes:
> If I build linuxbios with gcc 2.96, things get marginally better. But 
> weirder.
>
> Linux version 2.4.19-lanl.18beoboot (root@butthead) (gcc version 2.96 
> 20000731 (Red Hat Linux 7.3 2.96-112)) #1 Fri Aug 16 15:03:04 MDT 2002 
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
>  BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
>  BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
>  BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
>  BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
> Warning only 896MB will be used.
> Use a PAE enabled kernel.
> 896MB LOWMEM available.
> hm, page 00000000 reserved twice.
> On node 0 totalpages: 229376
>
> note that it is still not seeing the MP table.

It looks like either the of pirq or mptable is working.
> But later on:
>
> PCI: Discovered primary peer bus 10 [IRQ]
> PCI: Discovered primary peer bus 11 [IRQ]
> PCI: Discovered primary peer bus 12 [IRQ]
> PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
> PCI: Found IRQ 11 for device 00:1d.0
> PCI: Sharing IRQ 11 with 07:01.0
> PCI: Found IRQ 5 for device 00:1f.1
> PCI: Found IRQ 3 for device 00:1f.3
> PCI: Found IRQ 7 for device 02:01.0
>
> So how is it getting this info? I am now getting confused.

Yep that looks very much like a pirq table.  All of the assigned irqs are below 16.
> nevertheless it does get the new kernel fine over the myrinet. The ram map 
> still looks like this:
>
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
>  BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
>  BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
>  BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
>  BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
>
> Note also that the RAM map shows (for this newer linuxbios) a big hole in 
> the ram map. 2.4.19 doesn't seem to be able to handle this, more below:

Cool, you have enabled the debugging option.
It leaves 512MB low, and it puts the rest of the memory about 4GB so it is possible
to test PAE setups.
> Warning only 4GB will be used.
> Use a PAE enabled kernel.
> 3200MB HIGHMEM available.
>
> OOPS! There's only 1024 MB but the kernel is doing something odd.

LinuxBIOS actually, it is a feature...

That 3200MB HIGHMEM available definitely sounds off.
> Now the older linuxbios (a version from LNXI that says 1.0.0.6) show this 
> for the ram map:
>
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 0000000000000b54 (reserved)
>  BIOS-e820: 0000000000000b54 - 00000000000a0000 (usable)
>  BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
>  BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
> 128MB HIGHMEM available.
> 896MB LOWMEM available.
>
> And this works.
>
> So, that's the state of play: linuxbios is now producing e820 maps that 
> 2.4.19 doesn't seem to be able to handle;

Hmm.  If you get more than 512MB of RAM it is a 2.4.19 bug, earlier
kernels handle that case just fine.
> something is somehow trashing 
> the MP table (etherboot); and, in general, things on e7500 are not 
> currently working.

It looks like it is still an mptable problem.  There are a few oddities
but nothing very big.

Next time I swing by and do a build I will see how well it all works
with binutils-2.13 and gcc-3.2  I have recently upgraded I just have
not swung by that direction yet.

You might try installing egcs-2.91.66 aka kgcc on redhat.  That was
what the port was developed with.  Until I had the compressor going
I was having a hard time fitting etherboot and LinuxBIOS in the last
64KB.

Eric

[steven james]

Greetings,

I'm not on RH8.0 yet. I do use gcc 2.96 20000731 to build LinuxBIOS. I'm
currently tracking an apparent memory issue that may be caused by the same
thing.  The symptom is that when the baremetal based bootloader allocates
the bounce buffer at the top of RAM, it seems to be allocating nonexistant
RAM. It gets the LinuxBIOS table using Eric's code from etherboot.

I will let you know if I find anything interesting.

G'day,
sjames

On Mon, 2 Dec 2002, Ronald G. Minnich wrote:
> If I build linuxbios with gcc 2.96, things get marginally better. But 
> weirder.
>
> Linux version 2.4.19-lanl.18beoboot (root@butthead) (gcc version 2.96 
> 20000731 (Red Hat Linux 7.3 2.96-112)) #1 Fri Aug 16 15:03:04 MDT 2002 
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
>  BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
>  BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
>  BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
>  BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
> Warning only 896MB will be used.
> Use a PAE enabled kernel.
> 896MB LOWMEM available.
> hm, page 00000000 reserved twice.
> On node 0 totalpages: 229376
>
> note that it is still not seeing the MP table.
>
> But later on:
>
> PCI: Discovered primary peer bus 10 [IRQ]
> PCI: Discovered primary peer bus 11 [IRQ]
> PCI: Discovered primary peer bus 12 [IRQ]
> PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
> PCI: Found IRQ 11 for device 00:1d.0
> PCI: Sharing IRQ 11 with 07:01.0
> PCI: Found IRQ 5 for device 00:1f.1
> PCI: Found IRQ 3 for device 00:1f.3
> PCI: Found IRQ 7 for device 02:01.0
>
> So how is it getting this info? I am now getting confused.
>
> nevertheless it does get the new kernel fine over the myrinet. The ram map 
> still looks like this:
>
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 0000000000000bd0 (reserved)
>  BIOS-e820: 0000000000000bd0 - 00000000000a0000 (usable)
>  BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
>  BIOS-e820: 0000000000100000 - 0000000020000000 (usable)
>  BIOS-e820: 0000000100000000 - 0000000120000000 (usable)
>
> Note also that the RAM map shows (for this newer linuxbios) a big hole in 
> the ram map. 2.4.19 doesn't seem to be able to handle this, more below:
>
> Warning only 4GB will be used.
> Use a PAE enabled kernel.
> 3200MB HIGHMEM available.
>
> OOPS! There's only 1024 MB but the kernel is doing something odd.
>
> Now the older linuxbios (a version from LNXI that says 1.0.0.6) show this 
> for the ram map:
>
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 0000000000000b54 (reserved)
>  BIOS-e820: 0000000000000b54 - 00000000000a0000 (usable)
>  BIOS-e820: 00000000000f0000 - 00000000000f0400 (reserved)
>  BIOS-e820: 0000000000100000 - 0000000040000000 (usable)
> 128MB HIGHMEM available.
> 896MB LOWMEM available.
>
> And this works.
>
> So, that's the state of play: linuxbios is now producing e820 maps that 
> 2.4.19 doesn't seem to be able to handle; something is somehow trashing 
> the MP table (etherboot); and, in general, things on e7500 are not 
> currently working.
>
> More later.
>
> ron
>
> Linuxbios mailing list
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios