linux-stable.git/init/main.c, branch linux-2.6.24.y

sched: proper prototype for kernel/sched.c:migration_init()

2007-11-09T21:39:39+00:00

This patch adds a proper prototype for migration_init() in
include/linux/sched.h

Since there's no point in always returning 0 to a caller that doesn't check
the return value it also changes the function to return void.

Signed-off-by: Adrian Bunk 
Signed-off-by: Andrew Morton 
Signed-off-by: Ingo Molnar

spelling fixes: init/

2007-10-19T23:28:29+00:00

Spelling fix in init/.

Signed-off-by: Simon Arlott 
Signed-off-by: Adrian Bunk

Drop the superfluous test for an old version of gcc.

2007-10-19T21:13:32+00:00

The header file  already enforces a suitably recent
version of gcc, so there's no point checking for that again.

Signed-off-by: Robert P. J. Day 
Signed-off-by: Adrian Bunk

Task Control Groups: basic task cgroup framework

2007-10-19T18:53:36+00:00

Generic Process Control Groups
--------------------------

There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
cgroups, and others.  These all need the basic abstraction of being
able to group together multiple processes in an aggregate, in order to
track/limit the resources permitted to those processes, or control
other behaviour of the processes, and all implement this grouping in
different ways.

This patchset provides a framework for tracking and grouping processes
into arbitrary "cgroups" and assigning arbitrary state to those
groupings, in order to control the behaviour of the cgroup as an
aggregate.

The intention is that the various resource management and
virtualization/cgroup efforts can also become task cgroup
clients, with the result that:

- the userspace APIs are (somewhat) normalised

- it's easier to test e.g. the ResGroups CPU controller in
 conjunction with the BeanCounters memory controller, or use either of
them as the resource-control portion of a virtual server system.

- the additional kernel footprint of any of the competing resource
 management systems is substantially reduced, since it doesn't need
 to provide process grouping/containment, hence improving their
 chances of getting into the kernel

This patch:

Add the main task cgroups framework - the cgroup filesystem, and the
basic structures for tracking membership and associating subsystem state
objects to tasks.

Signed-off-by: Paul Menage 
Cc: Serge E. Hallyn 
Cc: "Eric W. Biederman" 
Cc: Dave Hansen 
Cc: Balbir Singh 
Cc: Paul Jackson 
Cc: Kirill Korotaev 
Cc: Herbert Poetzl 
Cc: Srivatsa Vaddagiri 
Cc: Cedric Le Goater 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fix maxcpus=1 oops in show_stat()

2007-08-31T04:54:31+00:00

Alexey Dobriyan reports that maxcpus=1 is still broken in 2.6.23-rc4:
if CONFIG_HOTPLUG_CPU is not set, x86_64 bootup oopses in show_stat() -
for_each_possible_cpu accesses a per-cpu area which was never set up.

Alexey identified commit 61ec7567db103d537329b0db9a887db570431ff4
(ACPI: boot correctly with "nosmp" or "maxcpus=0") as the origin;
but it's not really to blame, just exposes a bug in 2.6.23-rc1's commit
8b3b295502444340dd0701855ac422fbf32e161d (Especially when !CONFIG_HOTPLUG_CPU,
avoid needlessy allocating resources for CPUs that can never become available).

rc1's test for max_cpus < 2 in start_kernel() wasn't working because
max_cpus was still NR_CPUS at that point: until rc4 moved the maxcpus
parsing earlier.  Now it sets cpu_possible_map to 1 before allocating
all possible per-cpu areas; then smp_init() expands cpu_possible_map
to cpu_present_map (0xf in my case) later on.

rc1's commit has good intentions, but expects cpu_present_map to be
limited by maxcpus, which is only the case on i386.  cpus_and(possible,
possible,present) might be good, but needs an audit of cpu_present_map
uses - there may well be assumptions that any cpu present is possible.

So stay safe for now and just revert those #ifndef CONFIG_HOTPLUG_CPU
optimizations in rc1's commit.

Signed-off-by: Hugh Dickins 
Cc: Alexey Dobriyan 
Cc: Len Brown 
Cc: Andrew Morton 
Cc: Jan Beulich 
Signed-off-by: Linus Torvalds

fix maxcpus=N parsing

2007-08-27T17:27:48+00:00

Commit 61ec7567db103d537329b0db9a887db570431ff4 ('ACPI: boot correctly
with "nosmp" or "maxcpus=0"') broke 'maxcpus=' handling on x86[-64].

maxcpus=N is now having no effect on x86_64, and freezing bootup on i386
(because of inconsistency with the separate maxcpus parsing down in
arch/i386, I guess).  That's because early_param parsing is a little
different from __setup parsing, and needs the "=" omitted: then it seems
to work as the original commit intended (no mention of IO-APIC in
/proc/interrupts when maxcpus=0).

Signed-off-by: Hugh Dickins 
Cc: Andrew Morton 
Cc: Len Brown 
Cc: Andi Kleen 
Cc: Rusty Russell 
Signed-off-by: Linus Torvalds

ACPI: boot correctly with "nosmp" or "maxcpus=0"

2007-08-21T04:33:35+00:00

In MPS mode, "nosmp" and "maxcpus=0" boot a UP kernel with IOAPIC disabled.
However, in ACPI mode, these parameters didn't completely disable
the IO APIC initialization code and boot failed.

init/main.c:
	Disable the IO_APIC if "nosmp" or "maxcpus=0"
	undefine disable_ioapic_setup() when it doesn't apply.

i386:
	delete ioapic_setup(), it was a duplicate of parse_noapic()
	delete undefinition of disable_ioapic_setup()

x86_64:
	rename disable_ioapic_setup() to parse_noapic() to match i386
	define disable_ioapic_setup() in header to match i386

http://bugzilla.kernel.org/show_bug.cgi?id=1641

Acked-by: Andi Kleen 
Signed-off-by: Len Brown

adjust nosmp handling

2007-07-16T16:05:47+00:00

Especially when !CONFIG_HOTPLUG_CPU, avoid needlessy allocating resources for
CPUs that can never become available.

Signed-off-by: Jan Beulich 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Allow softlockup to be runtime disabled

2007-07-16T16:05:47+00:00

It's useful sometimes to disable the softlockup checker at boottime.
Especially if it triggers during a distro install.

Signed-off-by: Dave Jones 
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

serial: convert early_uart to earlycon for 8250

2007-07-16T16:05:35+00:00

Beacuse SERIAL_PORT_DFNS is removed from include/asm-i386/serial.h and
include/asm-x86_64/serial.h.  the serial8250_ports need to be probed late in
serial initializing stage.  the console_init=>serial8250_console_init=>
register_console=>serial8250_console_setup will return -ENDEV, and console
ttyS0 can not be enabled at that time.  need to wait till uart_add_one_port in
drivers/serial/serial_core.c to call register_console to get console ttyS0.
that is too late.

Make early_uart to use early_param, so uart console can be used earlier.  Make
it to be bootconsole with CON_BOOT flag, so can use console handover feature.
and it will switch to corresponding normal serial console automatically.

new command line will be:
	console=uart8250,io,0x3f8,9600n8
	console=uart8250,mmio,0xff5e0000,115200n8
or
	earlycon=uart8250,io,0x3f8,9600n8
	earlycon=uart8250,mmio,0xff5e0000,115200n8

it will print in very early stage:
	Early serial console at I/O port 0x3f8 (options '9600n8')
	console [uart0] enabled
later for console it will print:
	console handover: boot [uart0] -> real [ttyS0]

Signed-off-by: 
Cc: Andi Kleen 
Cc: Bjorn Helgaas 
Cc: Russell King 
Cc: Gerd Hoffmann 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds