linux-toradex.git, branch v2.6.34.4

Linux 2.6.34.4

2010-08-13T20:29:15+00:00

x86: don't send SIGBUS for kernel page faults

2010-08-13T20:27:39+00:00

commit 96054569190bdec375fe824e48ca1f4e3b53dd36 upstream.

It's wrong for several reasons, but the most direct one is that the
fault may be for the stack accesses to set up a previous SIGBUS.  When
we have a kernel exception, the kernel exception handler does all the
fixups, not some user-level signal handler.

Even apart from the nested SIGBUS issue, it's also wrong to give out
kernel fault addresses in the signal handler info block, or to send a
SIGBUS when a system call already returns EFAULT.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm: fix missing page table unmap for stack guard page failure case

2010-08-13T20:27:39+00:00

commit 5528f9132cf65d4d892bcbc5684c61e7822b21e9 upstream.

.. which didn't show up in my tests because it's a no-op on x86-64 and
most other architectures.  But we enter the function with the last-level
page table mapped, and should unmap it at exit.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm: keep a guard page below a grow-down stack segment

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

commit 320b2b8de12698082609ebbc1a17165727f4c893 upstream.

This is a rather minimally invasive patch to solve the problem of the
user stack growing into a memory mapped area below it.  Whenever we fill
the first page of the stack segment, expand the segment down by one
page.

Now, admittedly some odd application might _want_ the stack to grow down
into the preceding memory mapping, and so we may at some point need to
make this a process tunable (some people might also want to have more
than a single page of guarding), but let's try the minimal approach
first.

Tested with trivial application that maps a single page just below the
stack, and then starts recursing.  Without this, we will get a SIGSEGV
_after_ the stack has smashed the mapping.  With this patch, we'll get a
nice SIGBUS just as the stack touches the page just above the mapping.

Requested-by: Keith Packard 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

md/raid1: delay reads that could overtake behind-writes.

2010-08-13T20:27:37+00:00

commit e555190d82c0f58e825e3cbd9e6ebe2e7ac713bd upstream.

When a raid1 array is configured to support write-behind
on some devices, it normally only reads from other devices.
If all devices are write-behind (because the rest have failed)
it is possible for a read request to be serviced before a
behind-write request, which would appear as data corruption.

So when forced to read from a WriteMostly device, wait for any
write-behind to complete, and don't start any more behind-writes.

Signed-off-by: NeilBrown 
Signed-off-by: Greg Kroah-Hartman

ibmvfc: Reduce error recovery timeout

2010-08-13T20:27:37+00:00

commit daa142d1773dd3a986f02a8a4da929608d24daaa upstream.

If a command times out resulting in EH getting invoked, we wait for the
aborted commands to come back after sending the abort. Shorten
the amount of time we wait for these responses, to ensure we don't
get stuck in EH for several minutes.

Signed-off-by: Brian King 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

ibmvfc: Fix command completion handling

2010-08-13T20:27:37+00:00

commit f5832fa2f8dc39adcf3ae348d2d6383163235e79 upstream.

Commands which are completed by the VIOS are placed on a CRQ
in kernel memory for the ibmvfc driver to process. Each CRQ
entry is 16 bytes. The ibmvfc driver reads the first 8 bytes
to check if the entry is valid, then reads the next 8 bytes to get
the handle, which is a pointer the completed command. This fixes
an issue seen on Power 7 where the processor reordered the
loads from memory, resulting in processing command completion
with a stale handle. This could result in command timeouts,
and also early completion of commands.

Signed-off-by: Brian King 
Signed-off-by: James Bottomley 
Signed-off-by: Greg Kroah-Hartman

i915: fix ironlake edp panel setup (v4)

2010-08-13T20:27:36+00:00

commit fe27d53e5c597ee5ba5d72a29d517091f244e974 upstream.

The eDP spec claims a 20% overhead for the 8:10 encoding scheme used
on the wire. Take this into account when picking the lane/clock speed
for the panel.

v3: some panels are out of spec, try our best to deal with them, don't
refuse modes on eDP panels, and try the largest allowed settings if
all else fails on eDP.
v4: fix stupid typo, forgot to git add before amending.

Fixes several reports in bugzilla:

      https://bugs.freedesktop.org/show_bug.cgi?id=28070

Signed-off-by: Dave Airlie 
Signed-off-by: Eric Anholt 
Cc: Manoj Iyer 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Use RSEN instead of HTPLG for tfp410 monitor detection.

2010-08-13T20:27:34+00:00

commit f458823b864c6def488f951a79986fa205aba4f1 upstream.

Presence detection of a digital monitor seems not to be reliable using
the HTPLG bit.

Dave Müller 
Signed-off-by: Greg Kroah-Hartman

xen: Do not suspend IPI IRQs.

2010-08-13T20:27:34+00:00

commit 4877c737283813bdb4bebfa3168c1585f6e3a8ca upstream.

In general the semantics of IPIs are that they are are expected to
continue functioning after dpm_suspend_noirq().

Specifically I have seen a deadlock between the callfunc IPI and the
stop machine used by xen's do_suspend() routine. If one CPU has already
called dpm_suspend_noirq() then there is a window where it can be sent
a callfunc IPI before all the other CPUs have entered stop_cpu().

If this happens then the first CPU ends up spinning in stop_cpu()
waiting for the other to rendezvous in state STOPMACHINE_PREPARE while
the other is spinning in csd_lock_wait().

Signed-off-by: Ian Campbell 
Cc: Jeremy Fitzhardinge 
Cc: xen-devel@lists.xensource.com
LKML-Reference: <1280398595-29708-4-git-send-email-ian.campbell@citrix.com>
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman