SETNAME only had a minor defect but probably never had a user and
MIPS_RDNVRAM was unimplemented anyway.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Nothing exciting; Linux just didn't know it yet so this is most adding
a value to a case statement.
Signed-off-by: Chris Dearman <chris@mips.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
common/au1000/irq.c was missing a mips_timer_interrupt() prototype,
whereas in common/au1000/time.c the actual mips_timer_interrupt()
implementation was missing an irq_exit() invocation, causing a
preempt_count() leak.
Signed-off-by: Herbert Valerio Riedel <hvr@hvrlab.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The ARM Architecture Reference Manual lists bit 4 of the PMD as "implementation
defined" and it must be set to zero on Intel XScale CPUs or the cache does
not behave properly. Found by Mike Rapoport while debugging a flash issue
on the PXA255:
http://marc.10east.com/?l=linux-arm-kernel&m=114845287600782&w=1
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Prevent calling of some platform functions on the clock chips of the eMac
as it seems to cause it to lockup at boot. For now, add a quirk to prevent
that from happening. Later, I might find out what's wrong and fix it but
that doesn't seem to be important as the machine appear to work fine
without running those. It's possible that Darwin doesn't run them.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Nathan Pilatzke <nathanpilatzke@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Uses of smp_processor_id() get pushed earlier and earlier in
the start_kernel() sequence. So just get it working before
we call start_kernel() to avoid all possible problems.
Signed-off-by: David S. Miller <davem@davemloft.net>
We don't enable the BTB on the ixp2350 as that can cause weird
crashes (erratum #42.) However, some bootloaders enable the BTB,
which means that we have to disable the BTB explicitly.
Found thanks to Tom Rini.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Deepak Saxena <dsaxena@plexity.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This reverts commit 5491d0f3e206beb95eeb506510d62a1dab462df1.
As per Andi:
"After some discussion with people who have the affected system it
seems best to revert for 2.6.17. It broke a common BIOS workaround
and PCI-X still doesn't work. Alternative is for people to change
the BIOS which seems to be better right now."
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
int_ret_from_syscall already does syscall exit tracing, so
no need to do it again in the caller.
This caused problems for UML and some other special programs doing
syscall interception.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Robert Hentosh <robert_hentosh@dell.com>
Actually, we just stumbled on a different bug found in find_e820_area() in
e820.c. The following code does not handle the edge condition correctly:
while (bad_addr(&addr, size) && addr+size < ei->addr + ei->size)
;
last = addr + size;
if ( last > ei->addr + ei->size )
continue;
The second statement in the while loop needs to be a <= b so that it is the
logical negavite of the if (a > b) outside it. It needs to read:
while (bad_addr(&addr, size) && addr+size <= ei->addr + ei->size)
;
In the case that failed bad_addr was returning an address that is exactly size
bellow the end of the e820 range.
AK: Again together with the earlier avoid edma fix this fixes
boot on a Dell PE6850/16GB
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Daniel Yeisley <dan.yeisley@unisys.com>
It is possible to boot a Unisys ES7000 with CPUs from multiple cells, and not
also include the memory from those cells. This can create a scenario where
node 0 has cpus, but no associated memory. The system will boot fine in a
configuration where node 0 has memory, but nodes 2 and 3 do not.
[AK: I rechecked the code and generic code seems to indeed handle that already.
Dan's original patch had a change for mm/slab.c that seems to be already in now.]
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: "Jan Beulich" <jbeulich@novell.com>
The PM timer code updates vxtime.last_tsc, but this update was done
incorrectly in two ways:
- offset_delay being in microseconds requires multiplying with cpu_mhz
rather than cpu_khz
- the multiplication of offset_delay and cpu_khz (both being 32-bit
values) on most current CPUs would overflow (observed value of the
delay was approximately 4000us, yielding an overflow for frequencies
starting a little above 1GHz)
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: "Jan Beulich" <jbeulich@novell.com>
When using apic= on the kernel command line, this had no effect for machines
matched by either the ACPI MADT or the MPS OEM table scan. However, when such
option is specified, it should also take effect for this set of systems.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Complaining about the IOMMU not compiled in doesn't make sense
here because it is clearly compiled in.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
ia32_setup_arg_pages would ignore the passed in random stack top
and use its own static value.
Now it uses the 8bit of randomness native i386 would use too.
This indirectly fixes mmap randomization for 32bit processes too,
which depends on the stack randomization.
Should also give slightly better virtual cache colouring and
possibly better performance with HyperThreading.
Signed-off-by: Andi Kleen <ak@suse.de>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This shouldn't have actually caused any problems
(as we return if we 'corrupt' 'i', but it's still not
very pretty. For the sake of adding another local variable,
this got cleaner.
Signed-off-by: Dave Jones <davej@redhat.com>
A typo crept in with commit ea1e847cc202e805769c3c46ba5e5c53714068a1
which defined TI_LOCAL_FLAGS to be the offset of the `flags' field
of struct thread_info, rather than the `local_flags' field. This
fixes it. The typo was pointed out by Guennadi Liakhovetski.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
[PATCH] powerpc: fix RTC/NVRAM accesses on Maple
[PATCH] ppc32 CPM_UART: various fixes for pq2 uart users
[PATCH] powerpc: linuxppc64.org no more
For a very long time, echoing 'standby' or 'mem' into /sys/power/state has
killed the machine on powerpc. This patch fixes that.
This patch adds the .valid callback to pm_ops on PowerMac so that only the
suspend to disk state can be entered. Note that just returning 0 would
suffice since the upper layers don't pass PM_SUSPEND_DISK down, but we
handle it there regardless just in case that changes.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Due to a firmware device tree bug, RTC and NVRAM accesses (including
halt/reboot) on Maple have been broken since January, when an untested
build fix went in. This code patches the device tree in Linux.
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes various odd things that missed update together with cpm_uart
platform_device move. Unified resources names, restructurisation, etc.
Also, addressed issue with recent phys/virt translation rework. Being
cache-coherent, CPM2's do alloc_bootmem() for the console stuff, and it was
used to treat console buffer descriptor mapping 1:1 (as in CPM1 case),
which is definitely wrong.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Add missing parentheses for type cast to u64.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Syscall number 224 was absent from the table, which I believe means that
the SPU can cause an oops by attempting to use it.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Paul Mackerras <paulus@samba.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Writing cr0 to cr2 register can't be right. This fixes the typo. I wonder
how it could survive so long.
Signed-off-by: Pavel Machek <pavel@suse.cz>
Cc: Zachary Amsden <zach@vmware.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Using asm-generic/dma-mapping.h does not work because pushing
the call down to pci_alloc_coherent() causes the gfp_t argument
of dma_alloc_coherent() to be ignored.
Fix this by implementing things directly, and adding a gfp_t
argument we can use in the internal call down to the PCI DMA
implementation of pci_alloc_coherent().
This fixes massive memory corruption when using the sound driver
layer, which passes things like __GFP_COMP down into these
routines and (correctly) expects that to work.
Signed-off-by: David S. Miller <davem@davemloft.net>
The 32 bit unsigned substraction (next - jiffies) in stop_hz_timer can
overflow if jiffies gets advanced between next_timer_interrupt and the read
under the xtime lock. The cast to a u64 then results in a large value
which causes the cpu to wait too long. Fix this by casting next and
jiffies independently to u64 before subtracting them.
(Spotted by Zachary Amsden <zach@vmware.com>)
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Problem:
If we put a probe onto a callq instruction and the probe is executed,
kernel panic of Bad RIP value occurs.
Root cause:
If resume_execution() found 0xff at first byte of p->ainsn.insn, it must
check the _second_ byte. But current resume_execution check _first_ byte
again.
I changed it checks second byte of p->ainsn.insn.
Kprobes on i386 don't have this problem, because the implementation is a
little bit different from x86_64.
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Satoshi Oshima <soshima@redhat.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
o Kdump second kernel boot fails after a system crash if second kernel
is UP and acpi=off and if crash occurred on a non-boot cpu.
o Issue here is that MP tables report boot cpu lapic id as 0 but second
kernel is booting on a different processor and MP table data is stale
in this context. Hence apic_id_registered() check fails in setup_local_APIC()
when called from APIC_init_uniprocessor().
o Problem is not seen if ACPI is enabled as in that case
boot_cpu_physical_apicid is read from the LAPIC.
o Problem is not seen with SMP kernels as well because in this case also
boot_cpu_physical_apicid is read from LAPIC. (smp_boot_cpus()).
o The problem is fixed by reading boot_cpu_physical_apicid from LAPIC
if it is a UP kernel and CRASH_DUMP is enabled.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
i386 stack dump has a "<0>" in the middle of the line and an extra space
between columns in multicolumn mode. Remove those and also remove an extra
blank line of source code.
Signed-off-by: Chuck Ebbert <76306.1226@compuserve.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* master.kernel.org:/home/rmk/linux-2.6-arm:
[ARM] 3533/1: Implement the __raw_(read|write)_can_lock functions on ARM
[ARM] 3530/1: PXA Mainstone: prevent double enable_irq() in pcmcia
[ARM] 3529/1: s3c24xx: fix restoring control register with undefined instruction
Patch from Thomas Gleixner
The mainstone board pcmcia interrupt have been enabled via setup_irq()
and the following socket check calls enable_irq again. Set the NOAUTOEN flag so the interrupt is not automatically enabled in setup_irq()
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Patch from Dimitry Andric
In arch/arm/mach-s3c2410/sleep.S, the coprocessor registers are saved at
suspend time, and restored at resume time. However, an undefined
instruction is used when attempting to restore a non-existent "auxiliary
control register". This leads to a crash on S3C2412, which has an ARM926
core instead of an ARM920.
At suspend time, the following fragment runs:
mrc p15, 0, r7, c2, c0, 0 @ translation table base address
mrc p15, 0, r8, c2, c0, 0 @ auxiliary control register
mrc p15, 0, r9, c1, c0, 0 @ control register
and at resume time, the following fragment runs:
mcr p15, 0, r7, c2, c0, 0 @ translation table base
mcr p15, 0, r8, c1, c1, 0 @ auxilliary control
...
mcr p15, 0, r9, c1, c0, 0 @ turn on MMU, etc
There are several problems with these fragments:
1. The ARM920 and ARM926 cores don't have any "auxiliary control
register", at least not according to the ARM920 and ARM926 TRM's.
2. The 2nd line of suspend erroneously saves the c2 register again.
3. This saved c2 value is restored using an undefined instruction. For
some reason this does not crash on ARM920, but does crash on ARM926.
The following patch fixes all these problems.
Signed-off-by: Dimitry Andric <dimitry@andric.com>
Yes, this looks sensible
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Calls to set_irq_info in set_irq_affinity_info() is redundant because
irq_affinity mask was set just one line immediately above it. Remove
that duplicate call.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
When CONFIG_PCI_MSI is set, move_irq() is an empty function, causing
grief when sys admin tries to bind interrupt to CPU.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
