linux-toradex.git, branch v2.6.32.6

Linux 2.6.32.6

2010-01-25T18:50:10+00:00

perf: Honour event state for aux stream data

2010-01-25T18:49:46+00:00

commit 22e190851f8709c48baf00ed9ce6144cdc54d025 upstream.

Anton reported that perf record kept receiving events even after calling
ioctl(PERF_EVENT_IOC_DISABLE). It turns out that FORK,COMM and MMAP
events didn't respect the disabled state and kept flowing in.

Reported-by: Anton Blanchard 
Signed-off-by: Peter Zijlstra 
Tested-by: Anton Blanchard 
LKML-Reference: <1263459187.4244.265.camel@laptop>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf events: Dont report side-band events on each cpu for per-task-per-cpu events

2010-01-25T18:49:45+00:00

commit 5d27c23df09b702868d9a3bff86ec6abd22963ac upstream.

Acme noticed that his FORK/MMAP numbers were inflated by about
the same factor as his cpu-count.

This led to the discovery of a few more sites that need to
respect the event->cpu filter.

Reported-by: Arnaldo Carvalho de Melo 
Signed-off-by: Peter Zijlstra 
Cc: Paul Mackerras 
LKML-Reference: <20091217121830.215333434@chello.nl>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf timechart: Use tid not pid for COMM change

2010-01-25T18:49:44+00:00

commit 8f06d7e6e1bbfb32698d6d455583ab7460c090e2 upstream.

A process that changes its comm field, does this on a per kernel
task struct basis. The timechart tool used, incorrectly, the pid
to track this, and should have used the tid instead...

Signed-off-by: Arjan van de Ven 
Cc: Peter Zijlstra 
Cc: Mike Galbraith 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: Frederic Weisbecker 
LKML-Reference: <20100116125319.34ac3edd@infradead.org>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

vmalloc: remove BUG_ON due to racy counting of VM_LAZY_FREE

2010-01-25T18:49:43+00:00

commit 88f5004430babb836cfce886d5d54c82166f8ba4 upstream.

In free_unmap_area_noflush(), va->flags is marked as VM_LAZY_FREE first, and
then vmap_lazy_nr is increased atomically.

But, in __purge_vmap_area_lazy(), while traversing of vmap_are_list, nr
is counted by checking VM_LAZY_FREE is set to va->flags.  After counting
the variable nr, kernel reads vmap_lazy_nr atomically and checks a
BUG_ON condition whether nr is greater than vmap_lazy_nr to prevent
vmap_lazy_nr from being negative.

The problem is that, if interrupted right after marking VM_LAZY_FREE,
increment of vmap_lazy_nr can be delayed.  Consequently, BUG_ON
condition can be met because nr is counted more than vmap_lazy_nr.

It is highly probable when vmalloc/vfree are called frequently.  This
scenario have been verified by adding delay between marking VM_LAZY_FREE
and increasing vmap_lazy_nr in free_unmap_area_noflush().

Even the vmap_lazy_nr is for checking high watermark, it never be the
strict watermark.  Although the BUG_ON condition is to prevent
vmap_lazy_nr from being negative, vmap_lazy_nr is signed variable.  So,
it could go down to negative value temporarily.

Consequently, removing the BUG_ON condition is proper.

A possible BUG_ON message is like the below.

   kernel BUG at mm/vmalloc.c:517!
   invalid opcode: 0000 [#1] SMP
   EIP: 0060:[] EFLAGS: 00010297 CPU: 3
   EIP is at __purge_vmap_area_lazy+0x144/0x150
   EAX: ee8a8818 EBX: c08e77d4 ECX: e7c7ae40 EDX: c08e77ec
   ESI: 000081fe EDI: e7c7ae60 EBP: e7c7ae64 ESP: e7c7ae3c
   DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
   Call Trace:
   [] free_unmap_vmap_area_noflush+0x69/0x70
   [] remove_vm_area+0x22/0x70
   [] __vunmap+0x45/0xe0
   [] vmalloc+0x2c/0x30
   Code: 8d 59 e0 eb 04 66 90 89 cb 89 d0 e8 87 fe ff ff 8b 43 20 89 da 8d 48 e0 8d 43 20 3b 04 24 75 e7 fe 05 a8 a5 a3 c0 e9 78 ff ff ff <0f> 0b eb fe 90 8d b4 26 00 00 00 00 56 89 c6 b8 ac a5 a3 c0 31
   EIP: [] __purge_vmap_area_lazy+0x144/0x150 SS:ESP 0068:e7c7ae3c

[ See also http://marc.info/?l=linux-kernel&m=126335856228090&w=2 ]

Signed-off-by: Yongseok Koh 
Reviewed-by: Minchan Kim 
Cc: Nick Piggin 
Cc: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

USB: fix usbstorage for 2770:915d delivers no FAT

2010-01-25T18:49:42+00:00

commit 10d2cdb6102669279bee2d9a00a22431b74583d5 upstream.

Resolves kernel.org bug 14914.

Remove entry for 2770:915d (usb digital camera with mass storage
support) from unusual_devs.h. The fix triggered by the entry causes
the file system on the camera to be completely inaccessible (no
partition table, the device is not mountable).

The patch works, but let me clarify a few things about it.  All the
patch does is remove the entry for this device from the
drivers/usb/storage/unusual_devs.h, which is supposed to help with a
problem with the device's reported size (I think).  I'm pretty sure it
was originally added for a reason, so I'm not sure removing it won't
cause other problems to reappear.  Also, I should note that this
unusual_devs.h entry was present (and activating workarounds) in
2.6.29, but in that version everything works fine.  Starting with
2.6.30, things no longer work.

Signed-off-by: Ryan May 
Cc: Rohan Hart 
Signed-off-by: Greg Kroah-Hartman

x86/PCI/PAT: return EINVAL for pci mmap WC request for !pat_enabled

2010-01-25T18:49:41+00:00

commit 2992e545ea006992ec9dc91c4fa996ce1e15f921 upstream.

Thomas Schlichter reported:
> X.org uses libpciaccess which tries to mmap with write combining enabled via
> /sys/bus/pci/devices/*/resource0_wc. Currently, when PAT is not enabled, the
> kernel does fall back to uncached mmap. Then libpciaccess thinks it succeeded
> mapping with write combining enabled and does not set up suited MTRR entries.
> ;-(

Instead of silently mapping pci mmap region as UC minus in the case
of !pat_enabled and wc request, we can return error. Eric Anholt mentioned
that caller (like X) typically follows up with UC minus pci mmap request and
if there is a free mtrr slot, caller will manage adding WC mtrr.

Jesse Barnes says:
> Older versions of libpciaccess will behave better if we do it that way
> (iirc it only allocates an MTRR if the resource_wc file doesn't exist or
> fails to get mapped).

Reported-by: Thomas Schlichter 
Signed-off-by: Thomas Schlichter 
Signed-off-by: Suresh Siddha 
Acked-by: Eric Anholt 
Acked-by: Jesse Barnes 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

DM: Fix device mapper topology stacking

2010-01-25T18:49:41+00:00

commit b27d7f16d3c6c27345d4280a739809c1c2c4c0b5 upstream.

Make DM use bdev_stack_limits() function so that partition offsets get
taken into account when calculating alignment.  Clarify stacking
warnings.

Also remove obsolete clearing of final alignment_offset and misalignment
flag.

Signed-off-by: Martin K. Petersen 
Signed-off-by: Mike Snitzer 
Cc: Alasdair G. Kergon 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

block: bdev_stack_limits wrapper

2010-01-25T18:49:40+00:00

commit 17be8c245054b9c7786545af3ba3ca4e54cd4ad9 upstream.

DM does not want to know about partition offsets.  Add a partition-aware
wrapper that DM can use when stacking block devices.

Signed-off-by: Martin K. Petersen 
Acked-by: Mike Snitzer 
Reviewed-by: Alasdair G Kergon 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

drm/i915: try another possible DDC bus for the SDVO device with multiple outputs

2010-01-25T18:49:39+00:00

commit 7c3f0a2726fed78e0e0afe3b6fc3c1f5b298e447 upstream.

There exist multiple DDC buses for the SDVO cards with multiple outputs.
When we can't get the EDID by using the select DDC bus, we can try the other
possible DDC bus to see whether the EDID can be obtained.

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

Signed-off-by: Zhao Yakui 
Tested-by: Sebastien Caty 
Signed-off-by: Eric Anholt 
Signed-off-by: Greg Kroah-Hartman