From: Michael Neuling <hidden> Date: 2007-06-08 04:00:35
On pSeries the firmware features are not setup until ppc_md.init_early,
so we can't do the firmware feature sections fixups till after this.
Currently firmware feature sections is only used on iSeries which inits
the firmware features much earlier. This is a bug in waiting on
pSeries.
Signed-off-by: Michael Neuling <redacted>
---
paulus: since we aren't hitting this currently, it can wait for 2.6.23.
arch/powerpc/kernel/setup_64.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/setup_64.c
===================================================================
@@ -350,13 +350,11 @@ void __init setup_system(void){DBG(" -> setup_system()\n");-/* Apply the CPUs-specific and firmware specific fixups to kernel-*text(nopoutsectionsnotrelevanttothisCPUorthisfirmware)+/* Apply CPUs-specific fixups to kernel text (nop out sections+*notrelevanttothisCPU)*/do_feature_fixups(cur_cpu_spec->cpu_features,&__start___ftr_fixup,&__stop___ftr_fixup);-do_feature_fixups(powerpc_firmware_features,-&__start___fw_ftr_fixup,&__stop___fw_ftr_fixup);/**Unflattenthedevice-treepassedbyprom_initorkexec
@@ -394,6 +392,12 @@ void __init setup_system(void)if(ppc_md.init_early)ppc_md.init_early();+/* Apply firmware specific fixups to kernel text (nop out+*sectionsnotrelevanttothisfirmware)+*/+do_feature_fixups(powerpc_firmware_features,+&__start___fw_ftr_fixup,&__stop___fw_ftr_fixup);+/**Wecandiscoverserialportsnowsincetheabovedidsetupthe*hashtablemanagementforus,thusioremapworks.Wedothatearly
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-07-11 10:28:23
On Fri, 2007-06-08 at 14:00 +1000, Michael Neuling wrote:
On pSeries the firmware features are not setup until ppc_md.init_early,
so we can't do the firmware feature sections fixups till after this.
Currently firmware feature sections is only used on iSeries which inits
the firmware features much earlier. This is a bug in waiting on
pSeries.
Signed-off-by: Michael Neuling <redacted>
---
paulus: since we aren't hitting this currently, it can wait for 2.6.23.
This patch will cause the kernel to blow up at boot on various machines,
I'm surprised we haven't hit that already.
The problem is that we can't service SLB miss on a !iseries machine if
CONFIG_PPC_ISERIES is set, before the fixup occurs. (Some iseries code
in there will not have been nop'ed out and SRR0 will be loaded with
crap).
Thus we die when unflattening the device-tree on some machines.
There are two possibly solutions I see in the long run:
- We could set the FW features earlier on pseries, though that is a bit
annoying because that means doing it before the device-tree is
unflattened.
- We could constraint lmb_alloc to the first segment until the FW fixup
occurs, either within lmb_alloc itself, or fixup the callers such as
unflatten_device_tree, to pass an explicit limit.
What do you think ?
Ben.
There are two possibly solutions I see in the long run:
- We could set the FW features earlier on pseries, though that is
a bit
annoying because that means doing it before the device-tree is
unflattened.
- We could constraint lmb_alloc to the first segment until the FW
fixup
occurs, either within lmb_alloc itself, or fixup the callers such as
unflatten_device_tree, to pass an explicit limit.
c) use a different SLB handler during early boot;
d) preload some SLB entries at very early boot to cover
the first 4GB or so.
d) sounds nice and simple, but will it work?
Segher
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2007-07-11 11:27:41
On Wed, 2007-07-11 at 13:06 +0200, Segher Boessenkool wrote:
quoted
There are two possibly solutions I see in the long run:
- We could set the FW features earlier on pseries, though that is
a bit
annoying because that means doing it before the device-tree is
unflattened.
- We could constraint lmb_alloc to the first segment until the FW
fixup
occurs, either within lmb_alloc itself, or fixup the callers such as
unflatten_device_tree, to pass an explicit limit.
c) use a different SLB handler during early boot;
d) preload some SLB entries at very early boot to cover
the first 4GB or so.
d) sounds nice and simple, but will it work?
Nah, best to limit everything at boot to SLB 0. Thing is, 4G is not
enough, you may have more RAM and have allocations from the top.
Ben.
On Wednesday 11 July 2007, Benjamin Herrenschmidt wrote:
There are two possibly solutions I see in the long run:
=20
=A0- We could set the FW features earlier on pseries, though that is a bit
annoying because that means doing it before the device-tree is
unflattened.
=20
=A0- We could constraint lmb_alloc to the first segment until the FW fixup
occurs, either within lmb_alloc itself, or fixup the callers such as
unflatten_device_tree, to pass an explicit limit.
=20
What do you think ?
If I'm understanding this right, the first solution should be something
along the lines of the patch below (not tested), which even removes
more lines than it adds. It doesn't seem that annoying to me, and it
makes sense to assume that the fw_features are set up after returning
from the ppc_md probe.
Arnd <><
Index: linux-2.6/arch/powerpc/platforms/pseries/setup.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D-- linux-2.6.orig/arch/powerpc/platforms/pseries/setup.c
From: Michael Neuling <hidden> Date: 2007-07-11 23:23:45
In message [off-list ref] you wrote:
On Wednesday 11 July 2007, Benjamin Herrenschmidt wrote:
quoted
There are two possibly solutions I see in the long run:
=
quoted
=A0- We could set the FW features earlier on pseries, though that is a bit
annoying because that means doing it before the device-tree is
unflattened.
=
quoted
=A0- We could constraint lmb_alloc to the first segment until the FW fixup
occurs, either within lmb_alloc itself, or fixup the callers such as
unflatten_device_tree, to pass an explicit limit.
=
quoted
What do you think ?
If I'm understanding this right, the first solution should be something
along the lines of the patch below (not tested), which even removes
more lines than it adds. It doesn't seem that annoying to me, and it
makes sense to assume that the fw_features are set up after returning
from the ppc_md probe.
I'm not sure this patch is going to work as the do_feature_fixups isn't
called any earlier?
Mikey
If I'm understanding this right, the first solution should be something
along the lines of the patch below (not tested), which even removes
more lines than it adds. It doesn't seem that annoying to me, and it
makes sense to assume that the fw_features are set up after returning
from the ppc_md probe.
I'm not sure this patch is going to work as the do_feature_fixups isn't
called any earlier?
Right, my patch still assumes that yours gets removed.
Arnd <><
From: Michael Neuling <hidden> Date: 2007-07-12 15:15:00
quoted
quoted
If I'm understanding this right, the first solution should be something
along the lines of the patch below (not tested), which even removes
more lines than it adds. It doesn't seem that annoying to me, and it
makes sense to assume that the fw_features are set up after returning
from the ppc_md probe.
I'm not sure this patch is going to work as the do_feature_fixups isn't
called any earlier?
Right, my patch still assumes that yours gets removed.
From: Michael Neuling <hidden> Date: 2007-07-18 21:56:32
Move firmware feature initialisation from pSeries_init_early to the
earlier pSeries_probe_hypertas so they are initialised before firmware
feature fixups are applied.
Currently firmware feature sections are only used for iSeries which
initialises the these features much earlier. This is a bug in waiting
on pSeries.
Also adds some whitespace fixups.
Signed-off-by: Michael Neuling <redacted>
---
quoted
There are two possibly solutions I see in the long run:
=20
=A0- We could set the FW features earlier on pseries, though that is a bit
annoying because that means doing it before the device-tree is
unflattened.
=20
=A0- We could constraint lmb_alloc to the first segment until the FW fixup
occurs, either within lmb_alloc itself, or fixup the callers such as
unflatten_device_tree, to pass an explicit limit.
=20
What do you think ?
If I'm understanding this right, the first solution should be something
along the lines of the patch below (not tested), which even removes
more lines than it adds. It doesn't seem that annoying to me, and it
makes sense to assume that the fw_features are set up after returning
from the ppc_md probe.
I've cleaned this up and got it booting. Seems to be doing the right
things as I can see fw feature sections being correctly NOPed out now
after boot.
I've booted with pseries_defconfig and ppc64_defconfig.
Arnd, I've added a signed off by me, but it but this probably needs an
explicit one from you also before it heads up.
Mikey
arch/powerpc/platforms/pseries/firmware.c | 19 +++----------------
arch/powerpc/platforms/pseries/pseries.h | 2 +-
arch/powerpc/platforms/pseries/setup.c | 17 +++++++++++------
3 files changed, 15 insertions(+), 23 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/firmware.c
===================================================================
@@ -66,24 +66,13 @@ firmware_features_table[FIRMWARE_MAX_FEA*device-tree/ibm,hypertas-functions.Ultimatelythisfunctionalitymay*bemovedintoprom.cprom_init().*/-void__initfw_feature_init(void)+void__initfw_feature_init(constchar*hypertas,unsignedlonglen){-structdevice_node*dn;-constchar*hypertas,*s;-intlen,i;+constchar*s;+inti;DBG(" -> fw_feature_init()\n");-dn=of_find_node_by_path("/rtas");-if(dn==NULL){-printk(KERN_ERR"WARNING! Cannot find RTAS in device-tree!\n");-gotoout;-}--hypertas=of_get_property(dn,"ibm,hypertas-functions",&len);-if(hypertas==NULL)-gotoout;-for(s=hypertas;s<hypertas+len;s+=strlen(s)+1){for(i=0;i<FIRMWARE_MAX_FEATURES;i++){/* check value against table of strings */
Move firmware feature initialisation from pSeries_init_early to the
earlier pSeries_probe_hypertas so they are initialised before firmware
feature fixups are applied.
=20
Currently firmware feature sections are only used for iSeries which
initialises the these features much earlier. =A0This is a bug in waiting
on pSeries.
=20
Also adds some whitespace fixups.
=20
Signed-off-by: Michael Neuling <redacted>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Haven't tested it myself, but it certainly looks good to me. It does
require reverting your previous patch though, are you submitting the
reversal patch as well?
Arnd <><
From: Michael Neuling <hidden> Date: 2007-07-19 02:55:03
On Wednesday 18 July 2007, Michael Neuling wrote:
quoted
Move firmware feature initialisation from pSeries_init_early to the
earlier pSeries_probe_hypertas so they are initialised before firmware
feature fixups are applied.
=20
Currently firmware feature sections are only used for iSeries which
initialises the these features much earlier. =A0This is a bug in waiting
on pSeries.
=20
Also adds some whitespace fixups.
=20
Signed-off-by: Michael Neuling <redacted>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Haven't tested it myself, but it certainly looks good to me. It does
require reverting your previous patch though, are you submitting the
reversal patch as well?
Yep, this got reverted yesterday in
826ea8f22cf612d534f33c492c98f7895043bfd1
Mikey