powerpc/cell: disable ptcal in case of kdump reboot
Subsystems (2)
PATCH 1/1 powerpc/cell: disable ptcal in case of kdump reboot
The ibm,cbe-start-ptcal rtas call transfers ownership of a memory range to the hardware in order to do periodic memory interface recalibration.
When we do a kexec, we need to get this page back, so we don't step on the new kernel's toes.
We used to do this correctly in case of a user triggered kexec, but not for kdump.
This patch disables ptcal from the cell specific machine_crash_shutdown() callback. I also needed to fix the pseries code that tries to install its default_machine_crash_shutdown() code independent of what machine we're running on.
The fix has been verified by Akira Tsukamoto, the original reporter of the problem.
--- arch/powerpc/platforms/cell/ras.c | 6 ++++++ arch/powerpc/platforms/cell/ras.h | 1 + arch/powerpc/platforms/cell/setup.c | 2 +- arch/powerpc/platforms/pseries/kexec.c | 2 +- 4 files changed, 9 insertions(+), 2 deletions(-)
arch/powerpc/platforms/cell/ras.c +6 -0
@@ -226,6 +226,12 @@ static int cbe_ptcal_notify_reboot(struct notifier_block *nb,return cbe_ptcal_disable (); } +void cbe_machine_crash_shutdown (struct pt_regs *regs) +{ +cbe_ptcal_disable (); +return default_machine_crash_shutdown (regs); +} +static struct notifier_block cbe_ptcal_reboot_notifier = { .notifier_call = cbe_ptcal_notify_reboot };
arch/powerpc/platforms/cell/ras.h +1 -0
@@ -5,5 +5,6 @@ extern void cbe_system_error_exception(struct pt_regs *regs);extern void cbe_maintenance_exception (struct pt_regs *regs);extern void cbe_thermal_exception (struct pt_regs *regs);extern void cbe_ras_init (void ); +extern void cbe_machine_crash_shutdown (struct pt_regs *regs);#endif /* RAS_H */
arch/powerpc/platforms/cell/setup.c +1 -1
@@ -292,6 +292,6 @@ define_machine(cell) {#ifdef CONFIG_KEXEC .machine_kexec = default_machine_kexec, .machine_kexec_prepare = default_machine_kexec_prepare, - .machine_crash_shutdown = default_machine_crash_shutdown, + .machine_crash_shutdown = cbe_machine_crash_shutdown,#endif };
arch/powerpc/platforms/pseries/kexec.c +1 -1
@@ -70,4 +70,4 @@ static int __init pseries_kexec_setup(void)return 0 ; } -__initcall (pseries_kexec_setup); +machine_device_initcall (pseries, pseries_kexec_setup);
Signature · 1 line
1.5.4.3
please pull merge branch of cell-2.6.git
Hi Paul,
Please pull the fix I just sent from
master.kernel.org/pub/scm/linux/kernel/git/arnd/cell-2.6.git merge
Jeremy might want to look at it as well, since he wrote the code originally.
Thanks,
Arnd <><
---
Arnd Bergmann <[email protected]>:
powerpc/cell: disable ptcal in case of kdump reboot
arch/powerpc/platforms/cell/ras.c | 6 ++++++ arch/powerpc/platforms/cell/ras.h | 1 + arch/powerpc/platforms/cell/setup.c | 2 +- arch/powerpc/platforms/pseries/kexec.c | 2 +- 4 files changed, 9 insertions(+), 2 deletions(-)
Quoted 7 lines · Arnd Bergmann
The ibm,cbe-start-ptcal rtas call transfers ownership of a memory range to the hardware in order to do periodic memory interface recalibration.
When we do a kexec, we need to get this page back, so we don't step on the new kernel's toes.
We used to do this correctly in case of a user triggered kexec, but not for kdump.
Used to?
Quoted 2 lines
This patch disables ptcal from the cell specific
machine_crash_shutdown()callback.
I'd rather you used the crash_shutdown_register() infrastructure Mikey added for EHEA - it's designed for just this sort of thing.
Quoted 3 lines
I also needed to fix the pseries code that tries to install its
default_machine_crash_shutdown()code independent
of what machine we're running on.
That's a buglet.
cheers
Signature · 8 lines
Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person
Quoted 5 lines · Michael Ellerman
Quoted 2 lines · Arnd Bergmann
We used to do this correctly in case of a user triggered kexec, but not for kdump.
Used to?
Sorry, wrong wording. I meant without this patch, it's correct for kexec.
Quoted 5 lines
Quoted 2 lines
This patch disables ptcal from the cell specific
machine_crash_shutdown()callback.I'd rather you used the
crash_shutdown_register()infrastructure Mikey added for EHEA - it's designed for just this sort of thing.
Thanks for pointing this out, I wasn't aware of that call. New patch coming up.
Arnd <><
Quoted 10 lines · In message <[email protected]> you wrote:
Quoted 5 lines · Michael Ellerman
Quoted 2 lines · Arnd Bergmann
We used to do this correctly in case of a user triggered kexec, but not for kdump.
Used to?
Sorry, wrong wording. I meant without this patch, it's correct for kexec.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
This patch disables ptcal from the cell specific
machine_crash_shutdown()callback.I'd rather you used the
crash_shutdown_register()infrastructure Mikey added for EHEA - it's designed for just this sort of thing.Thanks for pointing this out, I wasn't aware of that call. New patch coming up.
In theory we can register lots of call backs but currently the maximum is set to 1 through CRASH_HANDLER_MAX. This is to discourage people from using this infrastructure at all.
Unless there's some crazy arse company that's going to mix a CBE with an eHEA, we are probably ok leaving this at 1. Right?
Mikey
Quoted 17 lines · Michael Neuling
Quoted 16 lines · In message <[email protected]> you wrote:
Quoted 5 lines · Michael Ellerman
Quoted 2 lines · Arnd Bergmann
We used to do this correctly in case of a user triggered kexec, but not for kdump.
Used to?
Sorry, wrong wording. I meant without this patch, it's correct for kexec.
Quoted 5 lines
Quoted 2 lines
This patch disables ptcal from the cell specific
machine_crash_shutdown()callback.I'd rather you used the
crash_shutdown_register()infrastructure Mikey added for EHEA - it's designed for just this sort of thing.
Quoted 6 lines
Quoted 2 lines
Thanks for pointing this out, I wasn't aware of that call. New patch coming up.
In theory we can register lots of call backs but currently the maximum is set to 1 through
CRASH_HANDLER_MAX. This is to discourage people from using this infrastructure at all.
Yeah true. In this case I think it's the less horrible solution to something that's fundamentally kdump-unfriendly.
Quoted 2 lines
Unless there's some crazy arse company that's going to mix a CBE with an eHEA, we are probably ok leaving this at 1. Right?
No comment *cough*. I guess I'd say just increase it to 2 on the off chance, can't hurt much.
cheers
Signature · 8 lines
Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person
Quoted 27 lines · In message <1213261480.8652.5.camel@localhost> you wrote:
Quoted 7 lines · Michael Neuling
Quoted 6 lines · In message <[email protected]> you wrote:
Quoted 5 lines · Michael Ellerman
Quoted 2 lines · Arnd Bergmann
We used to do this correctly in case of a user triggered kexec, but not for kdump.
=20
Used to?Quoted 8 lines
Quoted 8 lines
=20
Sorry, wrong wording. I meant without this patch, it's correct for kexec.
=20Quoted 4 lines
Quoted 2 lines
This patch disables ptcal from the cell specific
machine_crash_shutdown()callback.=20=20
I'd rather you used thecrash_shutdown_register()infrastructure Mike=y
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
added for EHEA - it's designed for just this sort of thing.
=20
Thanks for pointing this out, I wasn't aware of that call. New patch coming up.=20
In theory we can register lots of call backs but currently the maximum is set to 1 throughCRASH_HANDLER_MAX. This is to discourage people from using this infrastructure at all.
Quoted 8 lines
Yeah true. In this case I think it's the less horrible solution to something that's fundamentally kdump-unfriendly.
Quoted 2 lines
Unless there's some crazy arse company that's going to mix a CBE with an eHEA, we are probably ok leaving this at 1. Right?
No comment *cough*. I guess I'd say just increase it to 2 on the off chance, can't hurt much.
Ok.. but this one really really is the last one!! :-)
Mikey