linux-toradex.git/arch, branch v2.6.27.8

powerpc/spufs: add a missing mutex_unlock

2008-12-05T18:55:23+00:00

commit 6747c2ee8abf749e63fee8cd01a9ee293e6a4247 upstream.

A mutex_unlock(&gang->aff_mutex) in spufs_create_context() is missing
in case spufs_context_open() fails.  As a result, spu_create syscall
and spu_get_idle() may block.

This patch adds the mutex_unlock.

Signed-off-by: Kou Ishizaki 
Signed-off-by: Jeremy Kerr 
Acked-by: Andre Detsch 
Signed-off-by: Greg Kroah-Hartman

powerpc/spufs: Fix spinning in spufs_ps_fault on signal

2008-12-05T18:55:23+00:00

commit 606572634c3faa5b32a8fc430266e6e9d78d2179 upstream.

Currently, we can end up in an infinite loop if we get a signal
while the kernel has faulted in spufs_ps_fault. Eg:

 alarm(1);

 write(fd, some_spu_psmap_register_address, 4);

- the write's copy_from_user will fault on the ps mapping, and
signal_pending will be non-zero. Because returning from the fault
handler will never clear TIF_SIGPENDING, so we'll just keep faulting,
resulting in an unkillable process using 100% of CPU.

This change returns VM_FAULT_SIGBUS if there's a fatal signal pending,
letting us escape the loop.

Signed-off-by: Jeremy Kerr 
Signed-off-by: Greg Kroah-Hartman

x86: call dmi-quirks for HP Laptops after early-quirks are executed

2008-12-05T18:55:21+00:00

commit 35af28219e684a36cc8b1ff456c370ce22be157d upstream.

Impact: make warning message disappear - functionality unchanged

Problems with bogus IRQ0 override of those laptops should be fixed
with commits

x86: SB600: skip IRQ0 override if it is not routed to INT2 of IOAPIC
x86: SB450: skip IRQ0 override if it is not routed to INT2 of IOAPIC

that introduce early-quirks based on chipset configuration.

For further information, see
http://bugzilla.kernel.org/show_bug.cgi?id=11516

Instead of removing the related dmi-quirks completely we'd like to
keep them for (at least) one kernel version -- to double-check whether
the early-quirks really took effect. But the dmi-quirks need to be
called after early-quirks are executed. With this patch calling
sequence for dmi-quriks is changed as follows:

 acpi_boot_table_init()   (dmi-quirks)
 ...
 early_quirks()           (detect bogus IRQ0 override)
 ...
 acpi_boot_init()         (late dmi-quirks and setup IO APIC)

Note: Plan is to remove the "late dmi-quirks" with next kernel version.

Signed-off-by: Andreas Herrmann 
Acked-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: SB600: skip ACPI IRQ0 override if it is not routed to INT2 of IOAPIC

2008-12-05T18:55:20+00:00

commit 26adcfbf00e0726b4469070aa2f530dcf963f484 upstream.

On some more HP laptops BIOS reports an IRQ0 override
but the SB600 chipset is configured such that timer
interrupts go to INT0 of IOAPIC.

Check IRQ0 routing and if it is routed to INT0 of IOAPIC skip the
timer override.

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

Signed-off-by: Andreas Herrmann 
Signed-off-by: Len Brown 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86: Hibernate: Fix breakage on x86_32 with CONFIG_NUMA set

2008-12-05T18:55:20+00:00

backport of commit 97a70e548bd97d5a46ae9d44f24aafcc013fd701 to the 2.6.27 kernel.

The NUMA code on x86_32 creates special memory mapping that allows
each node's pgdat to be located in this node's memory.  For this
purpose it allocates a memory area at the end of each node's memory
and maps this area so that it is accessible with virtual addresses
belonging to low memory.  As a result, if there is high memory,
these NUMA-allocated areas are physically located in high memory,
although they are mapped to low memory addresses.

Our hibernation code does not take that into account and for this
reason hibernation fails on all x86_32 systems with CONFIG_NUMA=y and
with high memory present.  Fix this by adding a special mapping for
the NUMA-allocated memory areas to the temporary page tables created
during the last phase of resume.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

xen: do not reserve 2 pages of padding between hypervisor and fixmap.

2008-12-05T18:55:20+00:00

commit 5dc64a3442b98eaa0e3730c35fcf00cf962a93e7 upstream.

When reserving space for the hypervisor the Xen paravirt backend adds
an extra two pages (this was carried forward from the 2.6.18-xen tree
which had them "for safety"). Depending on various CONFIG options this
can cause the boot time fixmaps to span multiple PMDs which is not
supported and triggers a WARN in early_ioremap_init().

This was exposed by 2216d199b1430d1c0affb1498a9ebdbd9c0de439 which
moved the dmi table parsing earlier.
    x86: fix CONFIG_X86_RESERVE_LOW_64K=y

    The bad_bios_dmi_table() quirk never triggered because we do DMI setup
    too late. Move it a bit earlier.

There is no real reason to reserve these two extra pages and the
fixmap already incorporates FIX_HOLE which serves the same
purpose. None of the other callers of reserve_top_address do this.

Signed-off-by: Ian Campbell 
Signed-off-by: Ingo Molnar 
Cc: Jeremy Fitzhardinge 
Signed-off-by: Greg Kroah-Hartman

CPUFREQ: powernow-k8: ignore out-of-range PstateStatus value

2008-12-05T18:55:20+00:00

commit a266d9f1253a38ec2d5655ebcd6846298b0554f4 upstream.

A workaround for AMD CPU family 11h erratum 311 might cause that the
P-state Status Register shows a "current P-state" which is larger than
the "current P-state limit" in P-state Current Limit Register. For the
wrong P-state value there is no ACPI _PSS object defined and
powernow-k8/cpufreq can't determine the proper CPU frequency for that
state.

As a consequence this can cause a panic during boot (potentially with
all recent kernel versions -- at least I have reproduced it with
various 2.6.27 kernels and with the current .28 series), as an
example:

powernow-k8: Found 1 AMD Turion(tm)X2 Ultra DualCore Mobile ZM-82 processors (2 \
)
powernow-k8:    0 : pstate 0 (2200 MHz)
powernow-k8:    1 : pstate 1 (1100 MHz)
powernow-k8:    2 : pstate 2 (600 MHz)
BUG: unable to handle kernel paging request at ffff88086e7528b8
IP: [] cpufreq_stats_update+0x4a/0x5f
PGD 202063 PUD 0
Oops: 0002 [#1] SMP
last sysfs file:
CPU 1
Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.28-rc3-dirty #16
RIP: 0010:[]  [] cpufreq_stats_update+0x4a/0\
f
Synaptics claims to have extended capabilities, but I'm not able to read them.<6\
6
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88006e7528c0
RDX: 00000000ffffffff RSI: ffff88006e54af00 RDI: ffffffff808f056c
RBP: 00000000fffee697 R08: 0000000000000003 R09: ffff88006e73f080
R10: 0000000000000001 R11: 00000000002191c0 R12: ffff88006fb83c10
R13: 00000000ffffffff R14: 0000000000000001 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88006fb50740(0000) knlGS:0000000000000000
Unable to initialize Synaptics hardware.
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: ffff88086e7528b8 CR3: 0000000000201000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper (pid: 1, threadinfo ffff88006fb82000, task ffff88006fb816d0)
Stack:
 ffff88006e74da50 0000000000000000 ffff88006e54af00 ffffffff804863c7
 ffff88006e74da50 0000000000000000 00000000ffffffff 0000000000000000
 ffff88006fb83c10 ffffffff8024b46c ffffffff808f0560 ffff88006fb83c10
Call Trace:
 [] ? cpufreq_stat_notifier_trans+0x51/0x83
 [] ? notifier_call_chain+0x29/0x4c
 [] ? __srcu_notifier_call_chain+0x46/0x61
 [] ? cpufreq_notify_transition+0x93/0xa9
 [] ? powernowk8_target+0x1e8/0x5f3
 [] ? cpufreq_governor_performance+0x1b/0x20
 [] ? __cpufreq_governor+0x71/0xa8
 [] ? __cpufreq_set_policy+0x101/0x13e
 [] ? cpufreq_add_dev+0x3f0/0x4cd
 [] ? handle_update+0x0/0x8
 [] ? sysdev_driver_register+0xb6/0x10d
 [] ? powernowk8_init+0x0/0x7e
 [] ? cpufreq_register_driver+0x8f/0x140
 [] ? _stext+0x56/0x14f
 [] ? proc_register+0x122/0x17d
 [] ? create_proc_entry+0x73/0x8a
 [] ? register_irq_proc+0x92/0xaa
 [] ? init_irq_proc+0x57/0x69
 [] ? kernel_init+0x116/0x169
 [] ? child_rip+0xa/0x11
 [] ? kernel_init+0x0/0x169
 [] ? child_rip+0x0/0x11
Code: 05 c5 83 36 00 48 c7 c2 48 5d 86 80 48 8b 04 d8 48 8b 40 08 48 8b 34 02 48\

RIP  [] cpufreq_stats_update+0x4a/0x5f
 RSP 
CR2: ffff88086e7528b8
---[ end trace 0678bac75e67a2f7 ]---
Kernel panic - not syncing: Attempted to kill init!

In short, aftereffect of the wrong P-state is that
cpufreq_stats_update() uses "-1" as index for some array in

cpufreq_stats_update (unsigned int cpu)
{
...
     if (stat->time_in_state)
                stat->time_in_state[stat->last_index] =
                        cputime64_add(stat->time_in_state[stat->last_index],
                                      cputime_sub(cur_time, stat->last_time));
...
}

Fortunately, the wrong P-state value is returned only if the core is
in P-state 0. This fix solves the problem by detecting the
out-of-range P-state, ignoring it, and using "0" instead.

Cc: Mark Langsdorf 
Signed-off-by: Andreas Herrmann 
Signed-off-by: Dave Jones 
Signed-off-by: Greg Kroah-Hartman

x86: more general identifier for Phoenix BIOS

2008-12-05T18:55:14+00:00

commit 0af40a4b1050c050e62eb1dc30b82d5ab22bf221 upstream.

Impact: widen the reach of the low-memory-protect DMI quirk

Phoenix BIOSes variously identify their vendor as "Phoenix Technologies,
LTD" or "Phoenix Technologies LTD" (without the comma.)

This patch makes the identification string in the bad_bios_dmi_table
more general (following a suggestion by Ingo Molnar), so that both
versions are handled.

Again, the patched file compiles cleanly and the patch has been tested
successfully on my machine.

Signed-off-by: Philipp Kohlbecher 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

IA64: fix boot panic caused by offline CPUs

2008-12-05T18:55:12+00:00

commit 62ee0540f5e5a804b79cae8b3c0185a85f02436b upstream.

This fixes a regression introduced by 2c6e6db41f01b6b4eb98809350827c9678996698
"Minimize per_cpu reservations."  That patch incorrectly used information about
what CPUs are possible that was not yet initialized by ACPI.  The end result
was that per_cpu structures for offline CPUs were not initialized causing a
NULL pointer reference.

Since we cannot do the full acpi_boot_init() call any earlier, the simplest
fix is to just parse the MADT for SAPIC entries early to find the CPU
info.  This should also allow for some cleanup of the code added by the
"Minimize per_cpu reservations".  This patch just fixes the regressions, the
cleanup will come in a later patch.

Signed-off-by: Doug Chapman 
Signed-off-by: Alex Chiang 
CC: Robin Holt 
Signed-off-by: Tony Luck 
Cc: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

parisc: fix kernel crash when unwinding a userspace process

2008-12-05T18:55:11+00:00

commit 7a3f5134a8f5bd7fa38b5645eef05e8a4eb62951 upstream.

Any user on existing parisc 32- and 64bit-kernels can easily crash
the kernel and as such enforce a DSO.
A simple testcase is available here:
        http://gsyprf10.external.hp.com/~deller/crash.tgz

The problem is introduced by the fact, that the handle_interruption()
crash handler calls the show_regs() function, which in turn tries to
unwind the stack by calling parisc_show_stack().  Since the stack contains
userspace addresses, a try to unwind the stack is dangerous and useless
and leads to the crash.

The fix is trivial: For userspace processes
a) avoid to unwind the stack, and
b) avoid to resolve userspace addresses to kernel symbol names.

While touching this code, I converted print_symbol() to %pS
printk formats and made parisc_show_stack() static.

An initial patch for this was written by Kyle McMartin back in August:
http://marc.info/?l=linux-parisc&m=121805168830283&w=2

Compile and run-tested with a 64bit parisc kernel.

Signed-off-by: Helge Deller 
Cc: Grant Grundler 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Kyle McMartin 
Signed-off-by: Greg Kroah-Hartman