Re: coherent_ht.c,1.29,1.30

[Stefan Reinauer]

* Eric Biederman  [041115 11:46]:
> Modified Files:
>    coherent_ht.c 
> Log Message:
> optimize_link_read_pointers compiles now on the solo so don't disable it.

The problem was actually not htat it did not compile, but that it made
linuxbios hang on the hardware. Did you verify that it does not do this
anymore with optimize_link_read_pointers()?

I cannot verify this since I don't have access to test hardware anymore.
> --- coherent_ht.c	15 Nov 2004 10:46:43 -0000	1.30
> *** 643,651 ****
>    coherent_ht_finalize(result.nodes);
>    result.needs_reset = apply_cpu_errata_fixes(result.nodes, result.needs_reset);
> #if CONFIG_MAX_CPUS > 1 /* Why doesn't this work on the solo? */
>  result.needs_reset = optimize_link_read_pointers(result.nodes, result.needs_reset);
> #endif
> return result.needs_reset;

coherent_ht.c,1.29,1.30

Stefan Reinauer  writes:
> Eric Biederman  [041115 11:46]:
> > Modified Files:
> >    coherent_ht.c 
> > Log Message:
> > optimize_link_read_pointers compiles now on the solo so don't disable it.
>
> The problem was actually not htat it did not compile, but that it made
> linuxbios hang on the hardware. Did you verify that it does not do this
> anymore with optimize_link_read_pointers()?
>
> I cannot verify this since I don't have access to test hardware anymore.

The comment about why it was disabled was significantly ambiguous that
it could be either a compile problem or a hang problem.  And potentially
it could have been both.

According to cvs I committed that code initially and it shows up in my
tree several weeks before it shows up in the public freebios2 tree so
I am inclined to trust my memory.

However there are 2 significant checks we can perform.
- Did the original version compile?
- Does this work on the tyan/s2850

I just checked out the original version and it does not compile it
runs out of registers.

So unless YhLu has problems on the s2850 or we can dig something up in
the mailing list archives I am fairly certain that this change is ok.

Eric

coherent_ht.c,1.29,1.30

[Stefan Reinauer]

* Eric W. Biederman  [041115 17:42]:
> However there are 2 significant checks we can perform.
> Did the original version compile?
> Does this work on the tyan/s2850

does the s2850 use an athlon64? Iirc the problem was that the athlon64
has less ht links..
> So unless YhLu has problems on the s2850 or we can dig something up in
> the mailing list archives I am fairly certain that this change is ok.

The best way to test this is testing on a solo system.. If somebody has
one... Which I dont. Otherwise I suggest we mark the solo build broken
until someone can verify this..

Stefan

coherent_ht.c,1.29,1.30

Stefan Reinauer  writes:
> Eric W. Biederman  [041115 17:42]:
> > However there are 2 significant checks we can perform.
> > Did the original version compile?
> > Does this work on the tyan/s2850
>
> does the s2850 use an athlon64? Iirc the problem was that the athlon64
> has less ht links..

I am pretty certain that case was limited to the code that was
living in misc_control.c.  For which this problem has been resolved.
> > So unless YhLu has problems on the s2850 or we can dig something up in
> > the mailing list archives I am fairly certain that this change is ok.
>
> The best way to test this is testing on a solo system.. If somebody has
> one... Which I dont. Otherwise I suggest we mark the solo build broken
> until someone can verify this..

Actually looking at this the code is exactly what we have in misc_control.c
Which has been tested on an Athlon64 so I'm not concerned.

Eric

coherent_ht.c,1.29,1.30

Stefan Reinauer  writes:
> Eric W. Biederman  [041115 17:42]:
> > However there are 2 significant checks we can perform.
> > Did the original version compile?
> > Does this work on the tyan/s2850
>
> does the s2850 use an athlon64? Iirc the problem was that the athlon64
> has less ht links..
> > So unless YhLu has problems on the s2850 or we can dig something up in
> > the mailing list archives I am fairly certain that this change is ok.
>
> The best way to test this is testing on a solo system.. If somebody has
> one... Which I dont. Otherwise I suggest we mark the solo build broken
> until someone can verify this..

On that same note we are getting close to the point where making a stable 2.0
and freezing the API (or at least making no changes that are not backwards compatible)
is getting close.  We still have irqs and the ppc to sort out before then.

With that in mind we probably want to introduce a category of TESTED motherboards.

The solo is certainly is not worth dropping out of regression tests because it still
cleanly.   But since no one has tested it in a long time marking not marking it TESTED
is likely a good thing.

Anyway something to think about.

Eric