- 26 Jul, 2005 40 commits
-
-
Tom Rini authored
As Marcelo has been spending a great deal of time working on MPC8xx systems of late (thanks!) and has more time than I do now for it, I'm handing this over to him. Signed-off-by:
Tom Rini <trini@kernel.crashing.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Steven Rostedt authored
Here's the patch again to fix the code to handle if the values between MAX_USER_RT_PRIO and MAX_RT_PRIO are different. Without this patch, an SMP system will crash if the values are different. Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Dean Nelson <dcn@sgi.com> Signed-off-by:
-
Andreas Steinmetz authored
RLIMIT_RTPRIO is supposed to grant non privileged users the right to use SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by the RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used by audio users. Unfortunately this is broken in 2.6.13rc3 as you can see in the excerpt from sched_setscheduler below: /* * Allow unprivileged RT tasks to decrease priority: */ if (!capable(CAP_SYS_NICE)) { /* can't change policy */ if (policy != p->policy) return -EPERM; After the above unconditional test which causes sched_setscheduler to fail with no regard to the RLIMIT_RTPRIO value the following check is made: /* can't increase priority */ if (policy != SCHED_NORMAL && param->sched_priority > p->rt_priority && param->sched_priority > p->signal->rlim[RLIMIT_RTPRIO].rlim_cur) return -EPERM; Thus I do believe that the RLIMIT_RTPRIO value must be taken into account for the policy check, especially as the RLIMIT_RTPRIO limit is of no use without this change. The attached patch fixes this problem. Signed-off-by:Andreas Steinmetz <ast@domdv.de> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
Remove bogus initialization that was re-done (correctly) later.
-
Ben Dooks authored
Patch from Ben Dooks Split the s3c2440 specific clocks from the arch clock support, to make the code clearer. Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Eric W. Biederman authored
Now that all of the code paths that call acpi_power_off have been modified to call either call kernel_power_off (which calls apci_sleep_prepare by way of acpi_shutdown) or to call acpi_sleep_prepare directly it is redundant to call acpi_sleep_prepare from acpi_power_off. So simplify the code and simply don't call acpi_sleep_prepare. In addition there is a little error handling done so if we can't register the acpi class we don't hook pm_power_off. I think I have done the right thing with the CONFIG_PM define but I'm not certain. Can this code even be compiled if CONFIG_PM is false? Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Eric W. Biederman authored
machine_power_off on i386 and x86_64 now switch to the boot cpu out of paranoia and because the MP Specification indicates it is a good idea on reboot, so for those architectures it is a noop. I can't see anything in the acpi spec that requires you to be on the boot cpu to power off the system, so this should not be an issue for ia64. In addition ia64 has the altix a massive multi-node system where switching to the boot cpu sounds insane as we may hot removed the boot cpu. Signed-off-by:
-
Eric W. Biederman authored
i386 machine_power_off was disabling the local apic and all of it's users wanted to be on the boot cpu. So call machine_shutdown which places us on the boot cpu and disables the apics. This keeps us in sync and reduces the number of cases we need to worry about in the power management code. Signed-off-by:
-
Eric W. Biederman authored
machine_power_off now always switches to the boot cpu so there is no reason for APM to also do that. Signed-off-by:
-
Eric W. Biederman authored
Call machine_shutdown() to move to the boot cpu and disable apics. Both acpi_power_off and apm_power_off want to move to the boot cpu. and we are already disabling the local apics so calling machine_shutdown simply reuses code. ia64 doesn't have a special path in power_off for efi so there is no reason i386 should. If we really need to call the efi power off path the efi driver can set pm_power_off like everyone else. Signed-off-by:
-
Eric W. Biederman authored
This appears to be a typo I introduced when cleaning this code up earlier. Ooops. Signed-off-by:
-
Eric W. Biederman authored
The call appears to come from process context so kernel_power_off should be safe. And acpi_power_off won't necessarily work if you just call machine_power_off. Signed-off-by:
-
Eric W. Biederman authored
The suspend to disk code was a poor copy of the code in sys_reboot now that we have kernel_power_off, kernel_restart and kernel_halt use them instead of poorly duplicating them inline. Signed-off-by:
-
Eric W. Biederman authored
The 68328serial.c driver has a weird local reimplementation of magic sysrq. The code is architecture specific enough that calling machine_restart() is probably ok. But there is no reason not to call emergency_restart() so do so. Signed-off-by:
-
Eric W. Biederman authored
If we've hung a clean reboot does not sound like a real option. Signed-off-by:
-
Eric W. Biederman authored
If a watchdog driver has decided it is time to reboot the system we know something is wrong and we are in interrupt context so emergency_reboot() is what we want. Signed-off-by:
-
Eric W. Biederman authored
sysrq calls into the reboot path from an interrupt handler we can either push the code do into process context and call kernel_restart and get a clean reboot or we can simply reboot the machine, and increase our chances of actually rebooting. emergency_reboot() seems like the closest match to what we have previously done, and what we want. Signed-off-by:
-
Eric W. Biederman authored
We know the system is in trouble so there is no question if this is an emergecy :) Signed-off-by:
-
Eric W. Biederman authored
We already do all of the gymnastics to run from process context to call the power off code so call into the power off code cleanly. This especially helps acpi as part of it's shutdown logic should run acpi_shutdown called from device_shutdown which was not being called from here. Signed-off-by:
-
Eric W. Biederman authored
It is not safe to call set_cpus_allowed() in interrupt context and disabling the apics is complicated code. So unconditionally skip machine_shutdown in machine_emergency_reboot on x86_64. Signed-off-by:
-
Eric W. Biederman authored
We only want to shutdown the apics if reboot_force is not specified. Be we are doing this both in machine_shutdown which is called unconditionally and if (!reboot_force). So simply call machine_shutdown if (!reboot_force). It looks like something went weird with merging some of the kexec patches for x86_64, and caused this. Signed-off-by:
-
Eric W. Biederman authored
set_cpus_allowed is not safe in interrupt context and disabling apics is complicated code so don't call machine_shutdown on i386 from emergency_restart(). Signed-off-by:
-
Eric W. Biederman authored
machine_restart, machine_halt and machine_power_off are machine specific hooks deep into the reboot logic, that modules have no business messing with. Usually code should be calling kernel_restart, kernel_halt, kernel_power_off, or emergency_restart. So don't export machine_restart, machine_halt, and machine_power_off so we can catch buggy users. Signed-off-by:
-
Eric W. Biederman authored
It appears machine_restart has been working cris just by luck. Signed-off-by:
-
Eric W. Biederman authored
When the kernel is working well and we want to restart cleanly kernel_restart is the function to use. But in many instances the kernel wants to reboot when thing are expected to be working very badly such as from panic or a software watchdog handler. This patch adds the function emergency_restart() so that callers can be clear what semantics they expect when calling restart. emergency_restart() is expected to be callable from interrupt context and possibly reliable in even more trying circumstances. This is an initial generic implementation for all architectures. Signed-off-by:
-
Eric W. Biederman authored
It is obvious we wanted to call kernel_restart here but since we don't have it the code was expanded inline and hasn't been correct since sometime in 2.4. Signed-off-by:
-
Eric W. Biederman authored
Because the factors of sys_reboot don't exist people calling into the reboot path duplicate the code badly, leading to inconsistent expectations of code in the reboot path. This patch should is just code motion. Signed-off-by:
-
Eric W. Biederman authored
In the recent addition of device_suspend calls into sys_reboot two code paths were missed. Signed-off-by:
-
Andrew Morton authored
*** Warning: "fc_remote_port_block" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! *** Warning: "scsi_is_fc_rport" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! *** Warning: "fc_remote_port_unblock" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! *** Warning: "fc_remote_port_rolechg" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! *** Warning: "fc_release_transport" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! *** Warning: "fc_remove_host" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! *** Warning: "fc_remote_port_add" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! *** Warning: "fc_attach_transport" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined! Cc: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Andrew Morton authored
Older gcc's dont support anonymous unions, so this driver gets hundreds of error. Fortunately the fix is easy... Cc: James Bottomley <James.Bottomley@steeleye.com> Signed-off-by:
-
Andrew Morton authored
Cc: Robert Love <rml@novell.com> Cc: John McCutchan <ttb@tentacle.dhs.org> Signed-off-by:
-
Robert Love authored
Add inotify syscall entries to x86-64. Signed-off-by:
Robert Love <rml@novell.com> Signed-off-by:
John McCutchan <ttb@tentacle.dhs.org> Signed-off-by:
-
Robert Love authored
Add missing fsnotify_open() hook to sys32_open(). Add fsnotify_open() hook to sys32_open() on x86-64. Signed-off-by:
-
Robert Love authored
Check for (unlikely) errors in the filesystem initialization stuff in our module_init() function. Signed-off-by:
-
Robert Love authored
Change default inotify limits: Maximum instances per user to 128 and maximum events per queue to 16k. The max instances used to be 128; the change to 8 was a mistake. Memory consumption is fine. Signed-off-by:
-
Robert Love authored
Handle error out paths better. Signed-off-by:
-
Robert Love authored
Bug fix: Ensure that the fd passed to inotify_add_watch() and inotify_rm_watch() belongs to inotify. Signed-off-by:
-
Robert Love authored
As an optimization, use fget_light() and fput_light() where possible. Signed-off-by:
-
