It has been reported that the way Linux handles NODEFER for signals is
not consistent with the way other Unix boxes handle it. I've written a
program to test the behavior of how this flag affects signals and had
several reports from people who ran this on various Unix boxes,
confirming that Linux seems to be unique on the way this is handled.
The way NODEFER affects signals on other Unix boxes is as follows:
1) If NODEFER is set, other signals in sa_mask are still blocked.
2) If NODEFER is set and the signal is in sa_mask, then the signal is
still blocked. (Note: this is the behavior of all tested but Linux _and_
NetBSD 2.0 *).
The way NODEFER affects signals on Linux:
1) If NODEFER is set, other signals are _not_ blocked regardless of
sa_mask (Even NetBSD doesn't do this).
2) If NODEFER is set and the signal is in sa_mask, then the signal being
handled is not blocked.
The patch converts signal handling in all current Linux architectures to
the way most Unix boxes work.
Unix boxes that were tested: DU4, AIX 5.2, Irix 6.5, NetBSD 2.0, SFU
3.5 on WinXP, AIX 5.3, Mac OSX, and of course Linux 2.6.13-rcX.
* NetBSD was the only other Unix to behave like Linux on point #2. The
main concern was brought up by point #1 which even NetBSD isn't like
Linux. So with this patch, we leave NetBSD as the lonely one that
behaves differently here with #2.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This kills i386-specific stuff from arm Kconfig. Please apply,
Signed-off-by: Pavel Machek <pavel@suse.cz>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
- copy_from_user() can fail; ->write() must check its return value.
- severe buffer overruns both in ->read() and ->write() - lseek to the
end (i.e. to mmapper_size) and
if (count + *ppos > mmapper_size)
count = count + *ppos - mmapper_size;
will do absolutely nothing. Then it will call
copy_to_user(buf,&v_buf[*ppos],count);
with obvious results (similar for ->write()).
Fixed by turning read to simple_read_from_buffer() and by doing
normal limiting of count in ->write().
- gratitious lock_kernel() in ->mmap() - it's useless there.
- lots of gratuitous includes.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We are currently reserving one byte more than actually needed by the flash
device and overlapping into the next I/O expansion bus window. This a)
causes us to allocate an extra page of VM due to ARM ioremap() alignment
code and b) could cause problems if another driver tries to request the
next expansion bus window.
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Some nodes can have large holes on x86-64.
This fixes problems with the VM allowing too many dirty pages because it
overestimates the number of available RAM in a node. In extreme cases you
can end up with all RAM filled with dirty pages which can lead to deadlocks
and other nasty behaviour.
This patch just tells the VM about the known holes from e820. Reserved
(like the kernel text or mem_map) is still not taken into account, but that
should be only a few percent error now.
Small detail is that the flat setup uses the NUMA free_area_init_node() now
too because it offers more flexibility.
(akpm: lotsa thanks to Martin for working this problem out)
Cc: Martin Bligh <mbligh@mbligh.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The acpi-cpufreq driver does a P-state get after a P-state set
to verify whether set went through successfully. This test
is kind of redundant as set goes throught most of the times,
and the test is also expensive as a get of P-states can
take a lot of time (same as a set operation) as it goes
through SMM mode. Effectively, we are doubling the P-state
latency due to this get opertion.
momdule parameter "acpi_pstate_strict" restores orginal paranoia.
http://bugzilla.kernel.org/show_bug.cgi?id=5129
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Be more precise on deciding whether to call m8xx_ide_init() at
m8xx_setup.c:platform_init().
Compilation fails if CONFIG_BLK_DEV_IDE is defined but
CONFIG_BLK_DEV_MPC8xx_IDE isnt.
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Delete the ability to build an ACPI kernel that does
not include PCI support. When such a machine is created
and it requires a tuned kernel, send a patch.
http://bugzilla.kernel.org/show_bug.cgi?id=1364
Signed-off-by: Len Brown <len.brown@intel.com>
Build issues were mostly in the ACPI=n case -- don't do that.
Select ACPI from IA64_GENERIC.
Add some missing dependencies on ACPI.
Mark BLACKLIST_YEAR and some laptop-only ACPI drivers
as X86-only. Let me know when you get an IA64 Laptop.
Signed-off-by: Len Brown <len.brown@intel.com>
pcibios_bus_to_resource is exported on all architectures except ia64
and sparc. Add exports for the two missing architectures. Needed when
Yenta socket support is compiled as a module.
Signed-off-by: Keith Owens <kaos@sgi.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I mistakedly disabled fusion support in an earlier update. Fusion
is commonly used on many x86-64 systems, so this was a problem.
This patch fixes that.
Signed-off-by: And Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch puts back the export of machine_power_off() that was removed
by some janitor as it's used for emergency shutdown by the G5 thermal
control driver. Wether that driver should use kernel_power_off() instead
is debatable and a post-2.6.13 decision. In the meantime, please commit
that patch that fixes the driver for now.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The code to detect IO links on Opteron would not check
if the node had actually memory. This could lead to pci_bus_to_node
returning an invalid node, which might cause crashes later
when dma_alloc_coherent passes it to page_alloc_node().
The bug has been there forever but for some reason
it is causing now crashes.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
i386 floating-point exception handling has a bug that can cause error
code 0 to be sent instead of the proper code during signal delivery.
This is caused by unconditionally checking the IS and c1 bits from the
FPU status word when they are not always relevant. The IS bit tells
whether an exception is a stack fault and is only relevant when the
exception is IE (invalid operation.) The C1 bit determines whether a
stack fault is overflow or underflow and is only relevant when IS and IE
are set.
Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
a bunch of functions switched from volatile to __attribute__((noreturn)) and
from const to __attribute_pure__
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
use of explicit labels in inline asm is a Bad Idea(tm), since gcc can
decide to inline the function in several places. Fixed by use of 1f/f:
instead of .Lfitsin/.Lfitsin:
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
either icu_data declaration for SMP case should be taken out of m32102.h,
or its declarations for m32700ut and opsput should not be static for SMP.
Patch does the latter - judging by comments in m32102.h it is intended to
be non-static.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
extern on physid_2_cpu[] does not belong in smp.h - the thing is static.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
"=m" (lock->lock) / "1" (lock->lock) makes gcc4 unhappy; fixed by s/1/m/,
same as in case of i386 rwsem.h where such variant had been accepted
by both Linus and rth.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
on UP smp_call_function() is expanded to expression. Alpha oprofile
calls that puppy and ignores the return value. And has -Werror for
arch/*...
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
CONFIG_PM is broken on 44x; removed duplicate entry for CONFIG_PM, made
the inclusion of generic one conditional on BROKEN || !44x.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
MV64360 does not support IRQ_ALL_CPUS - see arch/ppc/kernel/mv64360_pic.c.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
ppc SMP is supported only for 6xx/POWER3/POWER4 - i.e. ones that have
PPC_STD_MMU. Dependency fixed.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Acked-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
DEBUG_PAGEALLOC is broken on m32r - the option had been blindly copied from
i386; kernel_map_pages() had not and that's what is needed for DEBUG_PAGEALLOC
to work (or link, while we are at it).
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
PCI support is broken on m32r (pci_map_... missing, etc.); marked as such
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NUMA is broken on m32r; marked as such
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NUMA is broken on alpha; marked as such
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Thanks to Stephane, we've now worked out the real cause of the
`Linux will not boot on simulator' problem. Turns out it's a stack
overflow because the stack pointer wasn't being initialised properly
in boot_head.S (it was being initialised to the lowest instead of the
highest address of the stack, so the first push started to overwrite
data in the BSS).
Signed-off-by: Peter Chubb <peterc@gelato.unsw.edu.au>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Plug a race in TSC synchronization
We need to do tsc_sync_wait() before the CPU is set online to prevent
multiple CPUs from doing it in parallel - which won't work because TSC
sync has global unprotected state.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I'm trying to get the nmi working with my laptop (IBM ThinkPad G41) and after
debugging it a while, I found that the nmi code doesn't want to set it up for
this particular CPU.
Here I have:
$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Mobile Intel(R) Pentium(R) 4 CPU 3.33GHz
stepping : 1
cpu MHz : 3320.084
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni
monitor ds_cpl est tm2 cid xtpr
bogomips : 6642.39
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Mobile Intel(R) Pentium(R) 4 CPU 3.33GHz
stepping : 1
cpu MHz : 3320.084
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 3
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe pni
monitor ds_cpl est tm2 cid xtpr
bogomips : 6637.46
And the following code shows:
$ cat linux-2.6.13-rc6/arch/i386/kernel/nmi.c
[...]
void setup_apic_nmi_watchdog (void)
{
switch (boot_cpu_data.x86_vendor) {
case X86_VENDOR_AMD:
if (boot_cpu_data.x86 != 6 && boot_cpu_data.x86 != 15)
return;
setup_k7_watchdog();
break;
case X86_VENDOR_INTEL:
switch (boot_cpu_data.x86) {
case 6:
if (boot_cpu_data.x86_model > 0xd)
return;
setup_p6_watchdog();
break;
case 15:
if (boot_cpu_data.x86_model > 0x3)
return;
Here I get boot_cpu_data.x86_model == 0x4. So I decided to change it and
reboot. I now seem to have a working NMI. So, unless there's something know
to be bad about this processor and the NMI. I'm submitting the following
patch.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Acked-by: Mikael Pettersson <mikpe@csd.uu.se>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
sparc_ksyms.c used to declare weak alias to several gcc intrinsics. It
doesn't work with gcc4 anymore - it wants a declaration for the thing
we are aliasing to and that's not going to happen for something like
.mul, etc. Replaced with direct injection of weak alias on the assembler
level - .weak <alias> followed by <alias> = <aliased>; that works on all
gcc versions.
Signed-off-by: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
GCC 4.x really dislikes the games we are playing in
unaligned.c, and the cleanest way to fix this is to
move things into assembler.
Noted by Al Viro.
Signed-off-by: David S. Miller <davem@davemloft.net>
Len Brown