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

xen: drop xen_sched_clock in favour of using plain wallclock time

2010-08-13T20:50:38+00:00

commit 8a22b9996b001c88f2bfb54c6de6a05fc39e177a upstream.

xen_sched_clock only counts unstolen time.  In principle this should
be useful to the Linux scheduler so that it knows how much time a process
actually consumed.  But in practice this doesn't work very well as the
scheduler expects the sched_clock time to be synchronized between
cpus.  It also uses sched_clock to measure the time a task spends
sleeping, in which case "unstolen time" isn't meaningful.

So just use plain xen_clocksource_read to return wallclock nanoseconds
for sched_clock.

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

.gitignore updates

2010-08-06T17:53:05+00:00

commit c17dad6905fc82d8f523399e5c3f014e81d61df6 upstream.

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

x86, Calgary: Limit the max PHB number to 256

2010-08-02T17:18:51+00:00

commit d596043d71ff0d7b3d0bead19b1d68c55f003093 upstream.

The x3950 family can have as many as 256 PCI buses in a single system, so
change the limits to the maximum.  Since there can only be 256 PCI buses in one
domain, we no longer need the BUG_ON check.

Signed-off-by: Darrick J. Wong 
LKML-Reference: <20100701004519.GQ15515@tux1.beaverton.ibm.com>
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, Calgary: Increase max PHB number

2010-08-02T17:18:50+00:00

commit 499a00e92dd9a75395081f595e681629eb1eebad upstream.

Newer systems (x3950M2) can have 48 PHBs per chassis and 8
chassis, so bump the limits up and provide an explanation
of the requirements for each class.

Signed-off-by: Darrick J. Wong 
Acked-by: Muli Ben-Yehuda 
Cc: Corinna Schultz 
LKML-Reference: <20100624212647.GI15515@tux1.beaverton.ibm.com>
[ v2: Fixed build bug, added back PHBS_PER_CALGARY == 4 ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

parisc: clear floating point exception flag on SIGFPE signal

2010-07-05T18:08:47+00:00

commit 550f0d922286556c7ea43974bb7921effb5a5278 upstream.

Clear the floating point exception flag before returning to
user space. This is needed, else the libc trampoline handler
may hit the same SIGFPE again while building up a trampoline
to a signal handler.

Fixes debian bug #559406.

Signed-off-by: Helge Deller 
Signed-off-by: Kyle McMartin 
Signed-off-by: Greg Kroah-Hartman

powerpc/oprofile: fix potential buffer overrun in op_model_cell.c

2010-07-05T18:08:43+00:00

commit 238c1a78c957f3dc7cb848b161dcf4805793ed56 upstream.

Fix potential initial_lfsr buffer overrun.
Writing past the end of the buffer could happen when index == ENTRIES

Signed-off-by: Denis Kirjanov 
Signed-off-by: Robert Richter 
Signed-off-by: Greg Kroah-Hartman

powerpc/pseries: Make query_cpu_stopped callable outside hotplug cpu

2010-07-05T18:08:42+00:00

commit f8b67691828321f5c85bb853283aa101ae673130 upstream.

This moves query_cpu_stopped() out of the hotplug cpu code and into
smp.c so it can called in other places and renames it to
smp_query_cpu_stopped().

It also cleans up the return values by adding some #defines

Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc/pseries: Only call start-cpu when a CPU is stopped

2010-07-05T18:08:42+00:00

commit aef40e87d866355ffd279ab21021de733242d0d5 upstream.

Currently we always call start-cpu irrespective of if the CPU is
stopped or not. Unfortunatley on POWER7, firmware seems to not like
start-cpu being called when a cpu already been started.  This was not
the case on POWER6 and earlier.

This patch checks to see if the CPU is stopped or not via an
query-cpu-stopped-state call, and only calls start-cpu on CPUs which
are stopped.

This fixes a bug with kexec on POWER7 on PHYP where only the primary
thread would make it to the second kernel.

Reported-by: Ankita Garg 
Signed-off-by: Michael Neuling 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc: Fix handling of strncmp with zero len

2010-07-05T18:08:42+00:00

commit 637a99022fb119b90fb281715d13172f0394fc12 upstream.

Commit 0119536c, which added the assembly version of strncmp to
powerpc, mentions that it adds two instructions to the version from
boot/string.S to allow it to handle len=0. Unfortunately, it doesn't
always return 0 when that is the case. The length is passed in r5, but
the return value is passed back in r3. In certain cases, this will
happen to work. Otherwise it will pass back the address of the first
string as the return value.

This patch lifts the len <= 0 handling code from memcpy to handle that
case.

Reported by: Christian_Sellars@symantec.com
Signed-off-by: Jeff Mahoney 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

clockevent: Prevent dead lock on clockevents_lock

2010-05-26T21:27:07+00:00

This is a merge of two mainline commits, intended
for stable@kernel.org submission for 2.6.27 kernel.

commit f833bab87fca5c3ce13778421b1365845843b976
and

commit 918aae42aa9b611a3663b16ae849fdedc67c2292
Changelog of both:

    Currently clockevents_notify() is called with interrupts enabled at
    some places and interrupts disabled at some other places.

    This results in a deadlock in this scenario.

    cpu A holds clockevents_lock in clockevents_notify() with irqs enabled
    cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled
    cpu C doing set_mtrr() which will try to rendezvous of all the cpus.

    This will result in C and A come to the rendezvous point and waiting
    for B. B is stuck forever waiting for the spinlock and thus not
    reaching the rendezvous point.

    Fix the clockevents code so that clockevents_lock is taken with
    interrupts disabled and thus avoid the above deadlock.

    Also call lapic_timer_propagate_broadcast() on the destination cpu so
    that we avoid calling smp_call_function() in the clockevents notifier
    chain.

    This issue left us wondering if we need to change the MTRR rendezvous
    logic to use stop machine logic (instead of smp_call_function) or add
    a check in spinlock debug code to see if there are other spinlocks
    which gets taken under both interrupts enabled/disabled conditions.

    Signed-off-by: Suresh Siddha 
    Cc: "Brown Len" 
    Cc: stable@kernel.org
    LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com>
    Signed-off-by: Thomas Gleixner 

    I got following warning on ia64 box:
      In function 'acpi_processor_power_verify':
      642: warning: passing argument 2 of 'smp_call_function_single' from
      incompatible pointer type

    This smp_call_function_single() was introduced by a commit
    f833bab87fca5c3ce13778421b1365845843b976:

    The problem is that the lapic_timer_propagate_broadcast() has 2 versions:
    One is real code that modified in the above commit, and the other is NOP
    code that used when !ARCH_APICTIMER_STOPS_ON_C3:

      static void lapic_timer_propagate_broadcast(struct acpi_processor *pr) { }

    So I got warning because of !ARCH_APICTIMER_STOPS_ON_C3.

    We really want to do nothing here on !ARCH_APICTIMER_STOPS_ON_C3, so
    modify lapic_timer_propagate_broadcast() of real version to use
    smp_call_function_single() in it.

    Signed-off-by: Hidetoshi Seto 
    Acked-by: Suresh Siddha 
    Signed-off-by: Len Brown 

Signed-off-by: Thomas Renninger 
Signed-off-by: Greg Kroah-Hartman