Sorry. Greg just found that nobody nowhere was setting a few crucial variables, like k8. He is tracking down the missing settings. You can too if you wish.
It's amazing how a simple problem has uncovered such a den of snakes, but that's the way it goes sometimes.
ron
ron minnich rminnich@lanl.gov writes:
Sorry. Greg just found that nobody nowhere was setting a few crucial variables, like k8. He is tracking down the missing settings. You can too if you wish.
Would you please explain?
Is it this in the cpu part or something else? cpu k8 "cpu0" register "up" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }" end
It is a fact that we must setup the coherent HT domain before we can read the static configuration in LinuxBIOS so setting the register information in the configuration file is way to late to use.
It's amazing how a simple problem has uncovered such a den of snakes, but that's the way it goes sometimes.
Details please?
Eric
This all started while trying to build EPIA and finding it was now failing.
The problem began with the cpufixup.h code. This code did things like this:
#if defined(k8) #define cpufixup() k8_cpufixup() #elif defined(k7)
etc.
First, this is about the only code that doesn't test a value, but instead tests a variable being defined. Second, in the Makefile.settings we found: -Dk8=
OK, so k8 is defined, but has no value. the "#if define(k8)" code succeeds as k8 is defined, and #defines cpufixup to k8_cpufixup. The Epia, which is not a K8, fails to build as it does not have k8_cpufixup symbol defined, which makes sense as it is not a K8.
So we changed the cpufixup.h to this: #if (k8 == 1) etc.
which is much more in the way linuxbios has used defines for the last 3 years or so (Eric, you being the person who pushed us in that direction) :-)
So we were testing for k8 == 1, and the Makefile.settings had set k8 to nothing.
Unfortunately, in gcc, if you define a variable but don't set its value, the preprocessor sets it to 1. So Epia builds still failed as #if (k8 == 1)
still succeeded..
So more looking. Turns out that in src/config/Options.lb, the variable k8 is defined as - default none - export always
which means that even if k8 is never set, it is always exported. In other words, a config variable with value 'none' is exported to Makefile.settings, which is just plain wrong. The value should be defined before it is exported.
Greg knows the full set of changes, but basically it is no longer allowed to export a variable whose value is 'none'. You have to set it if it gets exported.
This will fix the Epia build. It may not break any other builds; Greg explained to me that he has things worked out and I am being too pessimistic.
We'll see tomorow for our builds and we'll let you know.
ron
ron minnich rminnich@lanl.gov writes:
This all started while trying to build EPIA and finding it was now failing.
The problem began with the cpufixup.h code. This code did things like this:
#if defined(k8) #define cpufixup() k8_cpufixup() #elif defined(k7)
etc.
Ok I suspect that code came early on and never got cleaned up.
What this sounded like was a bug in existing code that caused things to work incorrectly. So at least on the Opteron things worked correctly.
We need to go in and add better cpu selection support in the code. What I am thinking it to extract the vendor and model number for the cpu and with that select the code to run similarly to how we handle other devices.
Given the number of small details that need to be verified when a new cpu comes out. Microcode on the Xeons, memory controller enhancements on the Opterons, etc I would rather have the build break on a new cpu than have everything just almost work silently.
So we changed the cpufixup.h to this: #if (k8 == 1) etc.
which is much more in the way linuxbios has used defines for the last 3 years or so (Eric, you being the person who pushed us in that direction) :-)
Yes.
Eric
On 23/03/2004, at 12:50 AM, Eric W. Biederman wrote:
Ok I suspect that code came early on and never got cleaned up.
What this sounded like was a bug in existing code that caused things to work incorrectly. So at least on the Opteron things worked correctly.
We need to go in and add better cpu selection support in the code. What I am thinking it to extract the vendor and model number for the cpu and with that select the code to run similarly to how we handle other devices.
Given the number of small details that need to be verified when a new cpu comes out. Microcode on the Xeons, memory controller enhancements on the Opterons, etc I would rather have the build break on a new cpu than have everything just almost work silently.
This is probably a good idea, but note that the x86 and ppc architectures do things very differently. To start with ppc doesn't have the hierarchical arrangement that is used in x86. This leads to a much simpler setup, though it does duplicate some code, but in any event I don't want this to change. Also, the pre-C configuration is completely different (romcc is not used). However this is done, it will need to take these architectural differences into account.
Greg
Greg Watson gwatson@lanl.gov writes:
On 23/03/2004, at 12:50 AM, Eric W. Biederman wrote:
Ok I suspect that code came early on and never got cleaned up.
What this sounded like was a bug in existing code that caused things to work incorrectly. So at least on the Opteron things worked correctly.
We need to go in and add better cpu selection support in the code. What I am thinking it to extract the vendor and model number for the cpu and with that select the code to run similarly to how we handle other devices.
Given the number of small details that need to be verified when a new cpu comes out. Microcode on the Xeons, memory controller enhancements on the Opterons, etc I would rather have the build break on a new cpu than have everything just almost work silently.
This is probably a good idea, but note that the x86 and ppc architectures do things very differently. To start with ppc doesn't have the hierarchical arrangement that is used in x86. This leads to a much simpler setup, though it does duplicate some code, but in any event I don't want this to change. Also, the pre-C configuration is completely different (romcc is not used). However this is done, it will need to take these architectural differences into account.
Given that ppc and x86 have different name spaces for cpu identification we cannot share the implementation. Like pci and superio devices similar but different.
What I would like to do is rewrite the architecture specific cpu_initialize so that it finds the type of a cpu and the dispatches to code that is totally cpu specific. If we have any code reuse it will be by calling library functions in the cpu specific code.
Once that happens compilation should be reduced to a set of which basic cpu types do you want to compile support in for. When cpus made by multiple vendors can share the same socket that is quite an interesting proposition.
Eric
On 22 Mar 2004, Eric W. Biederman wrote:
Is it this in the cpu part or something else? cpu k8 "cpu0" register "up" = "{ .chip = &amd8131, .ht_width=16, .ht_speed=600 }" end
forgot to add, it has nothing to do with this.
ron
-
ebiederman＠lnxi.com -
Greg Watson -
ron minnich