linux-toradex.git/arch, branch v3.2.15

sched/x86: Fix overflow in cyc2ns_offset

2012-04-13T15:33:50+00:00

commit 9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 upstream.

When a machine boots up, the TSC generally gets reset.  However,
when kexec is used to boot into a kernel, the TSC value would be
carried over from the previous kernel.  The computation of
cycns_offset in set_cyc2ns_scale is prone to an overflow, if the
machine has been up more than 208 days prior to the kexec.  The
overflow happens when we multiply *scale, even though there is
enough room to store the final answer.

We fix this issue by decomposing tsc_now into the quotient and
remainder of division by CYC2NS_SCALE_FACTOR and then performing
the multiplication separately on the two components.

Refactor code to share the calculation with the previous
fix in __cycles_2_ns().

Signed-off-by: Salman Qazi 
Acked-by: John Stultz 
Acked-by: Peter Zijlstra 
Cc: Paul Turner 
Cc: john stultz 
Link: http://lkml.kernel.org/r/20120310004027.19291.88460.stgit@dungbeetle.mtv.corp.google.com
Signed-off-by: Ingo Molnar 
Cc: Mike Galbraith 
Signed-off-by: Greg Kroah-Hartman

Revert "x86/ioapic: Add register level checks to detect bogus io-apic entries"

2012-04-13T15:33:49+00:00

This reverts commit 273fb194e86b795b08a724c7646d0f694949070b
[73d63d038ee9f769f5e5b46792d227fe20e442c5 upstream]

It causes problems, so needs to be reverted from 3.2-stable for now.

Reported-by: Konrad Rzeszutek Wilk 
Cc: Jon Dufresne 
Cc: Suresh Siddha 
Cc: 
Cc: Josh Boyer 
Cc: Ingo Molnar 
Cc: Teck Choon Giam 
Cc: Ben Guthro 
Signed-off-by: Greg Kroah-Hartman

x86/PCI: do not tie MSI MS-7253 use_crs quirk to BIOS version

2012-04-13T15:33:49+00:00

commit a97f4f5e524bcd09a85ef0b8821a14d35e69335f upstream.

Carlos was getting

	WARNING: at drivers/pci/pci.c:118 pci_ioremap_bar+0x24/0x52()

when probing his sound card, and sound did not work.  After adding
pci=use_crs to the kernel command line, no more trouble.

Ok, we can add a quirk.  dmidecode output reveals that this is an MSI
MS-7253, for which we already have a quirk, but the short-sighted
author tied the quirk to a single BIOS version, making it not kick in
on Carlos's machine with BIOS V1.2.  If a later BIOS update makes it
no longer necessary to look at the _CRS info it will still be
harmless, so let's stop trying to guess which versions have and don't
have accurate _CRS tables.

Addresses https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5533
Also see .

Reported-by: Carlos Luna 
Reviewed-by: Bjorn Helgaas 
Signed-off-by: Jonathan Nieder 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

x86/PCI: use host bridge _CRS info on MSI MS-7253

2012-04-13T15:33:49+00:00

commit 8411371709610c826bf65684f886bfdfb5780ca1 upstream.

In the spirit of commit 29cf7a30f8a0 ("x86/PCI: use host bridge _CRS
info on ASUS M2V-MX SE"), this DMI quirk turns on "pci_use_crs" by
default on a board that needs it.

This fixes boot failures and oopses introduced in 3e3da00c01d0
("x86/pci: AMD one chain system to use pci read out res").  The quirk
is quite targetted (to a specific board and BIOS version) for two
reasons:

 (1) to emphasize that this method of tackling the problem one quirk
     at a time is a little insane

 (2) to give BIOS vendors an opportunity to use simpler tables and
     allow us to return to generic behavior (whatever that happens to
     be) with a later BIOS update

In other words, I am not at all happy with having quirks like this.
But it is even worse for the kernel not to work out of the box on
these machines, so...

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42619
Reported-by: Svante Signell 
Signed-off-by: Jonathan Nieder 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

ARM: tegra: remove Tegra30 errata from MACH_TEGRA_DT

2012-04-13T15:33:48+00:00

[no upstream commit match, as this is a fix for a mis-applied patch in the
previous 3.2-stable release. - gregkh]

Commit 83e4194 "ARM: tegra: select required CPU and L2 errata options"
contained two chunks; one was errata for Tegra20 (correctly applied)
and the second errata for Tegra30. The latter was accidentally applied
to the wrong config option; Tegra30 support wasn't added until v3.3,
and so the second chunk should have just been dropped. This patch does
so.

Signed-off-by: Stephen Warren 
Signed-off-by: Greg Kroah-Hartman

x86,kgdb: Fix DEBUG_RODATA limitation using text_poke()

2012-04-13T15:33:48+00:00

commit 3751d3e85cf693e10e2c47c03c8caa65e171099b upstream.

There has long been a limitation using software breakpoints with a
kernel compiled with CONFIG_DEBUG_RODATA going back to 2.6.26. For
this particular patch, it will apply cleanly and has been tested all
the way back to 2.6.36.

The kprobes code uses the text_poke() function which accommodates
writing a breakpoint into a read-only page.  The x86 kgdb code can
solve the problem similarly by overriding the default breakpoint
set/remove routines and using text_poke() directly.

The x86 kgdb code will first attempt to use the traditional
probe_kernel_write(), and next try using a the text_poke() function.
The break point install method is tracked such that the correct break
point removal routine will get called later on.

Cc: x86@kernel.org
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: H. Peter Anvin 
Inspried-by: Masami Hiramatsu 
Signed-off-by: Jason Wessel 
Signed-off-by: Greg Kroah-Hartman

m68k/mac: Add missing platform check before registering platform devices

2012-04-13T15:33:47+00:00

commit 6cfeba53911d6d2f17ebbd1246893557d5ff5aeb upstream.

On multi-platform kernels, the Mac platform devices should be registered
when running on Mac only. Else it may crash later.

Signed-off-by: Geert Uytterhoeven 
Signed-off-by: Greg Kroah-Hartman

x86 bpf_jit: fix a bug in emitting the 16-bit immediate operand of AND

2012-04-13T15:33:45+00:00

[ Upstream commit 1d24fb3684f347226747c6b11ea426b7b992694e ]

When K >= 0xFFFF0000, AND needs the two least significant bytes of K as
its operand, but EMIT2() gives it the least significant byte of K and
0x2. EMIT() should be used here to replace EMIT2().

Signed-off-by: Feiran Zhuang  
Acked-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

x86, tls: Off by one limit check

2012-04-02T16:53:09+00:00

commit 8f0750f19789cf352d7e24a6cc50f2ab1b4f1372 upstream.

These are used as offsets into an array of GDT_ENTRY_TLS_ENTRIES members
so GDT_ENTRY_TLS_ENTRIES is one past the end of the array.

Signed-off-by: Dan Carpenter 
Link: http://lkml.kernel.org/r/20120324075250.GA28258@elgon.mountain
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, tsc: Skip refined tsc calibration on systems with reliable TSC

2012-04-02T16:53:09+00:00

commit 57779dc2b3b75bee05ef5d1ada47f615f7a13932 upstream.

While running the latest Linux as guest under VMware in highly
over-committed situations, we have seen cases when the refined TSC
algorithm fails to get a valid tsc_start value in
tsc_refine_calibration_work from multiple attempts. As a result the
kernel keeps on scheduling the tsc_irqwork task for later. Subsequently
after several attempts when it gets a valid start value it goes through
the refined calibration and either bails out or uses the new results.
Given that the kernel originally read the TSC frequency from the
platform, which is the best it can get, I don't think there is much
value in refining it.

So  for systems which get the TSC frequency from the platform we
should skip the refined tsc algorithm.

We can use the TSC_RELIABLE cpu cap flag to detect this, right now it is
set only on VMware and for Moorestown Penwell both of which have there
own TSC calibration methods.

Signed-off-by: Alok N Kataria 
Cc: John Stultz 
Cc: Dirk Brandewie 
Cc: Alan Cox 
[jstultz: Reworked to simply not schedule the refining work,
rather then scheduling the work and bombing out later]
Signed-off-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman