mptable and redhat 8 and wotta mess.

[Eric W. Biederman]

"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> If I build linuxbios with gcc 2.96, things get marginally better. But 
> weirder.
> 
> Linux version 2.4.19-lanl.18beoboot (root at 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