[LinuxBIOS] lnxi-merge complete

[Jason Schildt]

All,

The LNXI mega patch merge is complete.  Note that lnxi-patch-14 and 16
were not committed.  #14 was ommitted because it was no longer relevant
due to the apic_id lifting.  #16 was ommitted because it wasn't all that
important and it needs to be regenerated before we commit.  I will make
necessary comments on Issue Tracker next.
Thanks for being patient.
Regards,

--jason--

[Ronald G Minnich]

Jason Schildt wrote:
> All,
>
> The LNXI mega patch merge is complete.  Note that lnxi-patch-14 and 16
> were not committed.  #14 was ommitted because it was no longer relevant
> due to the apic_id lifting.  #16 was ommitted because it wasn't all that
> important and it needs to be regenerated before we commit.  I will make
> necessary comments on Issue Tracker next.
> Thanks for being patient.
> Regards,
>
> --jason--

Thanks, jason, it's a great job.

ron

[Jason Schildt]

On Tue, Oct 25, 2005 at 04:11:47PM -0600, Ronald G Minnich wrote:
> Jason Schildt wrote:
> > All,
> >
> > The LNXI mega patch merge is complete.  Note that lnxi-patch-14 and 16
> > were not committed.  #14 was ommitted because it was no longer relevant
> > due to the apic_id lifting.  #16 was ommitted because it wasn't all that
> > important and it needs to be regenerated before we commit.  I will make
> > necessary comments on Issue Tracker next.
> > Thanks for being patient.
> > Regards,
> >
> > --jason--
>
> Thanks, jason, it's a great job.

No worries.  But I suspect that there are going to be some build
breaks due to this.  Hopefully we can minimize the damage and move on
with it.

--jason--

[San Mehat]

Nice stuff.. what happened to get_apicid_base()? :)

linuxbios_ram.o(.text+0x7909): In function `smp_write_config_table':
: undefined reference to `get_apicid_base'

On 10/25/05, Ronald G Minnich  wrote:
> Jason Schildt wrote:
> > All,
> >
> > The LNXI mega patch merge is complete.  Note that lnxi-patch-14 and 16
> > were not committed.  #14 was ommitted because it was no longer relevant
> > due to the apic_id lifting.  #16 was ommitted because it wasn't all that
> > important and it needs to be regenerated before we commit.  I will make
> > necessary comments on Issue Tracker next.
> > Thanks for being patient.
> > Regards,
> >
> > --jason--
>
> Thanks, jason, it's a great job.
>
> ron

[LinuxBIOS] APICID lifting

San Mehat  writes:
> Nice stuff.. what happened to get_apicid_base()? :)
>
> linuxbios_ram.o(.text+0x7909): In function `smp_write_config_table':
> : undefined reference to `get_apicid_base'

An evolving understanding of what needs to happen.

We first replaced it in our tree with a function called max_lapicid()
that worked by looking at the device tree to see which apicid's had
already been used by the cpus.

For small cpu counts and small numbers of ioapics that worked well.

Then along came the observation that in all legacy apics and ioapics
only id's 0-15 are valid.  Currently most ioapics still have this
limitation where the cpus can be assigned id's 0-255.

Currently this is a problem for boards like the island/aruma which
have 14 io_apics and 4 cpus, or boards with 8 processor sockets
which can hold dual-core cpus.

So it was realized that for a general purpose solution the cpus apicid
must always be lifted.  So we made the formula for the cpus apicid
0x10 + coreid*0x10 + nodeid.  Which works consistently and should work
for everyone.  Unless someone has a buggy kernel which can't cope.

With all of the apicid's of the cpus above 16 max_lapicid() was
redundant and actually strongly incorrect for using to compute the
apicid_base, which we needed to place below 15.  So we dropped
the patch that fixed up all of the references to get_apicid_base,
to max_lapicid instead.

It just became apparent that we needed to either not kill
get_apicid_base or to have fixed up all of the references to
apicid_base with something else.

The simple correct solution is to just hardcode apicid_base to 1,
for the boards that use it.

The clean solution and probably what we want long term is a function
that places the ioapics in the device tree and assigns them the lowest
free ioapicid.  That code could probably move out of the mother board
files into the chipset specific code.  One more step along the lines
of clean interrupt handling.

Eric

[LinuxBIOS] APICID lifting

[yhlu]

new device could support 8 bit apic id. for example new 8132.

but 8111, 8131 only support 4 bit.

some old kernel assume boot cpu apic id is 0.

So the best way is only lift apic id of AP, and don't touch BSP's

YH

[LinuxBIOS] APICID lifting

yhlu  writes:
> new device could support 8 bit apic id. for example new 8132.
>
> but 8111, 8131 only support 4 bit.

Yes.   But the cpus always support 8 bit apic id.
> some old kernel assume boot cpu apic id is 0.
>
> So the best way is only lift apic id of AP, and don't touch BSP's

The best way is to get buggy software fixed.  So lifting the apic
id on the boot cpu will help find those bugs sooner, so they get
fixed.

I admit there is a pain threshold to supporting older software. 
If it is much to much of a problem to update software we need to
do something.

Eric

[LinuxBIOS] APICID lifting

[Stefan Reinauer]

* Eric W. Biederman  [051026 18:52]:
> The best way is to get buggy software fixed.  So lifting the apic
> id on the boot cpu will help find those bugs sooner, so they get
> fixed.

While this is philosophically true, it sounds like those "well, works
with fuctory bios, so linuxbios is broken" kind of thing.

Especially since having the boot cpu on apic id 0 is not particularly
wrong.

Stefan

[LinuxBIOS] APICID lifting

Stefan Reinauer  writes:
> Eric W. Biederman  [051026 18:52]:
> > The best way is to get buggy software fixed.  So lifting the apic
> > id on the boot cpu will help find those bugs sooner, so they get
> > fixed.
>
> While this is philosophically true, it sounds like those "well, works
> with fuctory bios, so linuxbios is broken" kind of thing.

Could be.  But it works with the latest kernels as well, so it is
easy enough to diagnose.
> Especially since having the boot cpu on apic id 0 is not particularly
> wrong.

Until you hit the board with 15 or 16 ioapics.

Getting a model that covers everything is painful.  If we need
to touch this again we really need a function that takes a node_core_id
and returns an apicid.   Then set it up so we have a reasonable default
version of that function but it can be overridden per motherboard.

OTOH if we don't run into the pain that would trigger this, we can
stay where we are.

Eric

[LinuxBIOS] APICID lifting

[Li-Ta Lo]

On Wed, 2005-10-26 at 11:18 -0600, Eric W. Biederman wrote:
> Stefan Reinauer  writes:
> > Eric W. Biederman  [051026 18:52]:
> > > The best way is to get buggy software fixed.  So lifting the apic
> > > id on the boot cpu will help find those bugs sooner, so they get
> > > fixed.
> >
> > While this is philosophically true, it sounds like those "well, works
> > with fuctory bios, so linuxbios is broken" kind of thing.
>
> Could be.  But it works with the latest kernels as well, so it is
> easy enough to diagnose.
> > Especially since having the boot cpu on apic id 0 is not particularly
> > wrong.
>
> Until you hit the board with 15 or 16 ioapics.
>
> Getting a model that covers everything is painful.  If we need
> to touch this again we really need a function that takes a node_core_id
> and returns an apicid.   Then set it up so we have a reasonable default
> version of that function but it can be overridden per motherboard.
>
> OTOH if we don't run into the pain that would trigger this, we can
> stay where we are.
>
> Eric

Why don't you assign apicid backwards for CPUs? Start from 0 for
BSP then 0 - 1 = 255 for AP etc.

[Stefan Reinauer]

* Jason Schildt  [051026 00:14]:
> All,
>
> The LNXI mega patch merge is complete.  Note that lnxi-patch-14 and 16
> were not committed.  #14 was ommitted because it was no longer relevant
> due to the apic_id lifting.  #16 was ommitted because it wasn't all that
> important and it needs to be regenerated before we commit.  I will make
> necessary comments on Issue Tracker next.
> Thanks for being patient.
> Regards,

I don't think this can be considered complete. All builds are broken at
the moment except the arima hdama.

There needs to be more to it than just code reviews. If nothing else
helps I will block commits that break any compiling target.

Stefan

Stefan Reinauer  writes:
> Jason Schildt  [051026 00:14]:
> > All,
> >
> > The LNXI mega patch merge is complete.  Note that lnxi-patch-14 and 16
> > were not committed.  #14 was ommitted because it was no longer relevant
> > due to the apic_id lifting.  #16 was ommitted because it wasn't all that
> > important and it needs to be regenerated before we commit.  I will make
> > necessary comments on Issue Tracker next.
> > Thanks for being patient.
> > Regards,
>
> I don't think this can be considered complete. All builds are broken at
> the moment except the arima hdama.

Perhaps.  The only issue I know of at the moment does not affect all
boards.
> There needs to be more to it than just code reviews. If nothing else
> helps I will block commits that break any compiling target.

Agreed.

It was changes requested in the code review that broke the build.
As I understand it we have some very minor fixups left to do.

I totally agree that this cannot be considered complete until the
build works.

Eric