Hi all,
The Hotplug CPU patch for 2.5.0 is uploaded.
http://sourceforge.net/projects/lhcs/
This patch works on s390, s390x, x86 and ia64 architectures.
It can also be applied against 2.4.16 with a little modification.
Down CPU
echo 0 > /proc/sys/kernel/cpu/<id>/online
Up CPU
echo 1 > /proc/sys/kernel/cpu/<id>/online
For ia64, number of CPUs to be initialized can be
specified with "initcpus=<num>" option for elilo.
With using the option, you can test real hot-add CPU
function without a HW ready for hotplug.
Thanks,
Kimi
--
Kimio Suganuma <[email protected]>
On Thu, Dec 13, 2001 at 01:29:42PM -0800, Kimio Suganuma wrote:
> Down CPU
> echo 0 > /proc/sys/kernel/cpu/<id>/online
>
> Up CPU
> echo 1 > /proc/sys/kernel/cpu/<id>/online
Please use /proc/sys/cpu/*/ so that we have all CPU information in
a consistent place. Please see linux/include/linux/sysctl.h for the
sysctl allocation.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Hi,
On Thu, 13 Dec 2001 22:44:00 +0000
Russell King <[email protected]> wrote:
> On Thu, Dec 13, 2001 at 01:29:42PM -0800, Kimio Suganuma wrote:
> > Down CPU
> > echo 0 > /proc/sys/kernel/cpu/<id>/online
> >
> > Up CPU
> > echo 1 > /proc/sys/kernel/cpu/<id>/online
>
> Please use /proc/sys/cpu/*/ so that we have all CPU information in
> a consistent place. Please see linux/include/linux/sysctl.h for the
> sysctl allocation.
I don't know much about sysctl specification, so could you show me
pointer to any document or something?
There is no /proc/sys/cpu directory on the latest kernel, and
I guess someone is thinking the structure under the directory,
right?
I guess the operation would be
echo 1 > /proc/sys/cpu/hotplug/<cpu-id>/online
or
echo 1 > /proc/sys/cpu/<cpu-id>/online
or
echo <cpu-id> > /proc/sys/cpu/online
Which is the right way?
Regards,
Kimi
--
Kimio Suganuma <[email protected]>
On Thu, 13 Dec 2001, Kimio Suganuma wrote:
> There is no /proc/sys/cpu directory on the latest kernel, and
> I guess someone is thinking the structure under the directory,
> right?
The current /proc/sys/cpu/ sysctls have been added as part of
Russell's cpu frequency scaling work. Currently, only the ARM
specific bits are merged. There are generic bits and x86 bits
waiting to be merged at some point..
The x86 part of this work uses the same framework, and was
done by myself and Arjan van de Ven. It's almost in a state
ready for merging also.
If you're interested in looking at this, it's in cvs..
cvs -d:pserver:[email protected]:/mnt/src/cvsroot login
cvs -d:pserver:[email protected]:/mnt/src/cvsroot checkout
cpufreq
> echo 1 > /proc/sys/cpu/<cpu-id>/online
> or
> Which is the right way?
This one looks most sensible to me, and fits in with the
current scheme nicely.
regards,
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
Hi!
> The Hotplug CPU patch for 2.5.0 is uploaded.
>
> http://sourceforge.net/projects/lhcs/
>
> This patch works on s390, s390x, x86 and ia64 architectures.
> It can also be applied against 2.4.16 with a little modification.
>
> Down CPU
> echo 0 > /proc/sys/kernel/cpu/<id>/online
>
> Up CPU
> echo 1 > /proc/sys/kernel/cpu/<id>/online
Such patches are neccessary for ACPI S3/S4 sleep support. It would be nice to
apply them soon.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi,
As you mentioned, CPU online caused panic when MTRR was on
on my system. I've only tested with no MTRR configuration. :-(
I'll investigate the problem but I'm not sure I can find
a resolution. (I know nothing about MTRR... )
Does anybody have an idea for the problem?
Thanks,
Kimi
On Tue, 18 Dec 2001 18:29:30 -0800 (PST)
"Randy.Dunlap" <[email protected]> wrote:
> Hi,
>
> I applied this patch to Linux 2.5.0 and tried to use it on
> a 2-way x86 system with dual Intel Pentium III's (1 GHz).
> Results:
> echo 0 > /proc/sys/kernel/cpu/1/online
> seems to work: "top" stops reporting about the second CPU.
>
> However,
> echo 1 > /proc/sys/kernel/cpu/1/online
> results in an Oops in set_mtrr_var_range_testing().
>
> (same oops that I had encountered when I ported the 2.4.5
> patch to 2.4.13)
>
> Does this work for you? I can connect a serial console to
> it and provide you with a complete oops report if you want
> that, and I'm available to help work on it.
>
> In linux/arch/i386/kernel/mtrr.c, the functions
> set_mtrr_var_range_testing() and
> set_mtrr_fixed_testing()
> need to have the "__init" removed from them, but this
> doesn't fix the oops problem.
>
> Thanks,
> --
> ~Randy
--
Kimio Suganuma <[email protected]>
> From: Pavel Machek [mailto:[email protected]]
> > This patch works on s390, s390x, x86 and ia64 architectures.
> > It can also be applied against 2.4.16 with a little modification.
> >
> > Down CPU
> > echo 0 > /proc/sys/kernel/cpu/<id>/online
> >
> > Up CPU
> > echo 1 > /proc/sys/kernel/cpu/<id>/online
>
> Such patches are neccessary for ACPI S3/S4 sleep support. It
> would be nice to
> apply them soon.
They are???
How so?
Regards -- Andy
Hi!
> > From: Pavel Machek [mailto:[email protected]]
> > > This patch works on s390, s390x, x86 and ia64 architectures.
> > > It can also be applied against 2.4.16 with a little modification.
> > >
> > > Down CPU
> > > echo 0 > /proc/sys/kernel/cpu/<id>/online
> > >
> > > Up CPU
> > > echo 1 > /proc/sys/kernel/cpu/<id>/online
> >
> > Such patches are neccessary for ACPI S3/S4 sleep support. It
> > would be nice to
> > apply them soon.
>
> They are???
If you are going to S4 sleep, you should better make sure no other
processors are changing stuff under your hands. Easiest way to do that
is by putting them offline (I see no other good solutions). For S3
having to save state of one CPU is bad enough, having to save state of
8 would be bad, so putting them offline would be handy, too.
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
Hi-
I've identified and fixed the problems on x86.
There were problems in arch/i386/kernel/mtrr.c and bluesmoke.c.
In both cases, the problems are with __init functions
and/or __initdata.
Patch is at end of email. CPU online/offline support now works
with mtrr.c and bluesmoke.c in my testing.
This patch is against Linux 2.5.0 plus your version 0.7
2.5.0 hotplug cpu patch (from sf.net/projects/lhcs).
Thanks,
~Randy
On Wed, 19 Dec 2001, Kimio Suganuma wrote:
| Hi,
|
| As you mentioned, CPU online caused panic when MTRR was on
| on my system. I've only tested with no MTRR configuration. :-(
| I'll investigate the problem but I'm not sure I can find
| a resolution. (I know nothing about MTRR... )
| Does anybody have an idea for the problem?
|
| Thanks,
| Kimi
|
| On Tue, 18 Dec 2001 18:29:30 -0800 (PST)
| "Randy.Dunlap" <[email protected]> wrote:
|
| > Hi,
| >
| > I applied this patch to Linux 2.5.0 and tried to use it on
| > a 2-way x86 system with dual Intel Pentium III's (1 GHz).
| > Results:
| > echo 0 > /proc/sys/kernel/cpu/1/online
| > seems to work: "top" stops reporting about the second CPU.
| >
| > However,
| > echo 1 > /proc/sys/kernel/cpu/1/online
| > results in an Oops in set_mtrr_var_range_testing().
| >
| > (same oops that I had encountered when I ported the 2.4.5
| > patch to 2.4.13)
| >
| > Does this work for you? I can connect a serial console to
| > it and provide you with a complete oops report if you want
| > that, and I'm available to help work on it.
| >
| > In linux/arch/i386/kernel/mtrr.c, the functions
| > set_mtrr_var_range_testing() and
| > set_mtrr_fixed_testing()
| > need to have the "__init" removed from them, but this
| > doesn't fix the oops problem.
| >
| > Thanks,
| > --
| > ~Randy
--- linux-250/arch/i386/kernel/mtrr.c Mon Dec 17 17:45:35 2001
+++ linux-250-cpu/arch/i386/kernel/mtrr.c Wed Jan 16 16:19:44 2002
@@ -839,7 +839,7 @@
/* Set the MSR pair relating to a var range. Returns TRUE if
changes are made */
-static int __init set_mtrr_var_range_testing (unsigned int index,
+static int set_mtrr_var_range_testing (unsigned int index,
struct mtrr_var_range *vr)
{
unsigned int lo, hi;
@@ -877,7 +877,7 @@
rdmsr(MTRRfix4K_C0000_MSR + i, p[6 + i*2], p[7 + i*2]);
} /* End Function get_fixed_ranges */
-static int __init set_fixed_ranges_testing(mtrr_type *frs)
+static int set_fixed_ranges_testing(mtrr_type *frs)
{
unsigned long *p = (unsigned long *)frs;
int changed = FALSE;
@@ -949,7 +949,7 @@
/* Free resources associated with a struct mtrr_state */
static void __init finalize_mtrr_state(struct mtrr_state *state)
{
- if (state->var_ranges) kfree (state->var_ranges);
+ /* NOT for cpu online/offline support: if (state->var_ranges) kfree (state->var_ranges); */
} /* End Function finalize_mtrr_state */
@@ -1876,13 +1876,13 @@
mtrr_type type;
} arr_state_t;
-arr_state_t arr_state[8] __initdata =
+arr_state_t arr_state[8] =
{
{0UL,0UL,0UL}, {0UL,0UL,0UL}, {0UL,0UL,0UL}, {0UL,0UL,0UL},
{0UL,0UL,0UL}, {0UL,0UL,0UL}, {0UL,0UL,0UL}, {0UL,0UL,0UL}
};
-unsigned char ccr_state[7] __initdata = { 0, 0, 0, 0, 0, 0, 0 };
+unsigned char ccr_state[7] = { 0, 0, 0, 0, 0, 0, 0 };
static void cyrix_arr_init_secondary(void)
{
@@ -2170,8 +2170,8 @@
#ifdef CONFIG_SMP
-static volatile unsigned long smp_changes_mask __initdata = 0;
-static struct mtrr_state smp_mtrr_state __initdata = {0, 0};
+static volatile unsigned long smp_changes_mask = 0;
+static struct mtrr_state smp_mtrr_state = {0, 0};
void __init mtrr_init_boot_cpu(void)
{
--- linux-250/arch/i386/kernel/bluesmoke.c.org Tue Jan 15 14:55:38 2002
+++ linux-250-cpu/arch/i386/kernel/bluesmoke.c Wed Jan 16 17:52:26 2002
@@ -10,7 +10,7 @@
#include <asm/processor.h>
#include <asm/msr.h>
-static int mce_disabled __initdata = 0;
+static int mce_disabled = 0;
/*
* Machine Check Handler For PII/PIII
@@ -120,7 +120,7 @@
* Set up machine check reporting for Intel processors
*/
-static void __init intel_mcheck_init(struct cpuinfo_x86 *c)
+static void intel_mcheck_init(struct cpuinfo_x86 *c)
{
u32 l, h;
int i;
@@ -191,7 +191,7 @@
* Set up machine check reporting on the Winchip C6 series
*/
-static void __init winchip_mcheck_init(struct cpuinfo_x86 *c)
+static void winchip_mcheck_init(struct cpuinfo_x86 *c)
{
u32 lo, hi;
/* Not supported on C3 */
In message <[email protected]> you
write:
> Hi-
>
> I've identified and fixed the problems on x86.
> There were problems in arch/i386/kernel/mtrr.c and bluesmoke.c.
>
> In both cases, the problems are with __init functions
> and/or __initdata.
>
> Patch is at end of email. CPU online/offline support now works
> with mtrr.c and bluesmoke.c in my testing.
Hi,
I've put it on my kernel page, and will upload to sf.net in a
little bit.
Thanks!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.