- 8-bit interface mode never worked properly.  The only adapter I have
  which supports the 8b mode (the Jmicron) had some problems with its
  clock wiring and they discovered it only now.  We also discovered that
  ProHG media is more sensitive to the ordering of initialization
  commands.

- Make the driver fall back to highest supported mode instead of always
  falling back to serial.  The driver will attempt the switch to 8b mode
  for any new MSPro card, but not all of them support it.  Previously,
  these new cards ended up in serial mode, which is not the best idea
  (they work fine with 4b, after all).

- Edit some macros for better conformance to Sony documentation
Signed-off-by: NAlex Dubov <oakad@yahoo.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Herton Krzesinski reports that the error-checking changes in
04ebd4ae ("block/ioctl.c and
fs/partition/check.c: check value returned by add_partition") cause his
buggy USB camera to no longer mount.  "The camera is an Olympus X-840.
The original issue comes from the camera itself: its format program
creates a partition with an off by one error".

Buggy devices happen.  It is better for the kernel to warn and to proceed
with the mount.
Reported-by: NHerton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: Abdel Benamrouche <draconux@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: David Brownell <david-b@pacbell.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix the section mismatch warning generated by the incorrect naming of
s3c24xx_spidrv which should be s3c24xx_spi_driver:

WARNING: drivers/spi/spi_s3c24xx.o(.data+0x4):
  Section mismatch in reference from the variable s3c24xx_spidrv
  to the (unknown reference) .exit.text:(unknown)
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When suspending the system with atmel_lcdfb enabled, I sometimes see
this:

	atmel_lcdfb atmel_lcdfb.0: FIFO underflow 0x10

Which can be explained by the fact that we're not stopping the LCD
controller and its DMA engine when suspending, we're just gating the
clocks to them.

There's another potential issue which may be harder to trigger but
much more nasty: If we gate the clocks at _just_ the right moment,
e.g. when the DMA engine is doing a bus transaction, we may cause the
DMA engine to violate the system bus protocol and cause a lockup.

Avoid these issues by shutting down the LCD controller before entering
suspend (and restarting it when resuming). This prevents the underrun
from happening in the first place, and prevents whatever nastiness is
happening when the bus clock stops in the middle of a DMA transfer.
Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If you are on ia64 and you modprobe xpc then modprobe -r xpc, you
immediately get a panic.  xpc depends on xp which depends on gru for a
symbol.  That symbol is only used when we are running on UV hardware.

Currently, the GRU driver detects we are not on UV hardware and does no
initializing.  It does not do the same check when unloading.  As a result,
the gru driver attempts to tear down stuff that was not setup.

This is a simple two-line workaround to get us through this release.  Once
2.6.28 is opened, we need to rework the symbols that xp is depending on
from gru so the gru driver can properly fail to load when hardware is not
available.
Signed-off-by: NRobin Holt <holt@sgi.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It should be linux-uvc-devel@lists.berlios.de.
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Provide summary ABI docs about the /sys/class/gpio files.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The iterator for_each_zone_zonelist() uses a struct zoneref *z cursor when
scanning zonelists to keep track of where in the zonelist it is.  The
zoneref that is returned corresponds to the the next zone that is to be
scanned, not the current one.  It was intended to be treated as an opaque
list.

When the page allocator is scanning a zonelist, it marks elements in the
zonelist corresponding to zones that are temporarily full.  As the
zonelist is being updated, it uses the cursor here;

  if (NUMA_BUILD)
        zlc_mark_zone_full(zonelist, z);

This is intended to prevent rescanning in the near future but the zoneref
cursor does not correspond to the zone that has been found to be full.
This is an easy misunderstanding to make so this patch corrects the
problem by changing zoneref cursor to be the current zone being scanned
instead of the next one.
Signed-off-by: NMel Gorman <mel@csn.ul.ie>
Cc: Andy Whitcroft <apw@shadowen.org>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: <stable@kernel.org>		[2.6.26.x]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixes two DMA bugs in the pxa2xx_spi driver.  The first bug is in all
versions of this driver; the second was introduced in the 2.6.20 kernel,
and prevents using the driver with chips like m25p16 flash (which can
issue large DMA reads).

 1. Zero length transfers are permitted for use to insert timing,
    but pxa2xx_spi.c will fail if this is requested in DMA mode.
    Fixed by using programmed I/O (PIO) mode for such transfers.

 2. Transfers larger than 8191 are not permitted in DMA mode.  A
    test for length rejects all large transfers regardless of DMA
    or PIO mode.  Worked around by rejecting only large transfers
    with DMA mapped buffers, and forcing all other transfers
    larger than 8191 to use PIO mode.  A rate limited warning is
    issued for DMA transfers forced to PIO mode.

This patch should apply to all kernels back to and including 2.6.20;
it was test patched against 2.6.20.  An additional patch would be
required for older kernels, but those versions are very buggy anyway.
Signed-off-by: NNed Forrester <nforrester@whoi.edu>
Cc: Vernon Sauder <vernoninhand@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixes several chipselect bugs in the pxa2xx_spi driver.  These bugs are in
all versions of this driver and prevent using it with chips like m25p16
flash.

 1. The spi_transfer.cs_change flag is handled too early:
    before spi_transfer.delay_usecs applies, thus making the
    delay ineffective at holding chip select.

 2. spi_transfer.delay_usecs is ignored on the last transfer
    of a message (likewise not holding chipselect long enough).

 3. If spi_transfer.cs_change is set on the last transfer, the
    chip select is always disabled, instead of the intended
    meaning: optionally holding chip select enabled for the
    next message.

Those first three bugs were fixed with a relocation of delays
and chip select de-assertions.

 4. If a message has the cs_change flag set on the last transfer,
    and had the chip select stayed enabled as requested (see 3,
    above), it would not have been disabled if the next message is
    for a different chip.  Fixed by dropping chip select regardless
    of cs_change at end of a message, if there is no next message
    or if the next message is for a different chip.

This patch should apply to all kernels back to and including 2.6.20;
it was test patched against 2.6.20.  An additional patch would be
required for older kernels, but those versions are very buggy anyway.
Signed-off-by: NNed Forrester <nforrester@whoi.edu>
Cc: Vernon Sauder <vernoninhand@gmail.com>
Cc: Eric Miao <eric.y.miao@gmail.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Error out on transfer length != multiple of bytes per word with -EINVAL.
Fixes a buffer overrun crash if length < bytes per word.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Acked-by: NJoakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit a61f5345 (spi_mpc83xx clockrate fixes) broke clockrate calculation
for low speeds.  SPMODE_DIV16 should be set if the divider is higher than
64, not only if the divider gets clipped to 1024.

Furthermore, the clipping check was off by a factor 16 as well.
Signed-off-by: NPeter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A "Quicklists:          0 kB" line has just started appearing in
/proc/meminfo, but most architectures (including x86) don't have
them configured, so #ifdef it, like the highmem lines.

And those architectures which do have quicklists configured are
using them for page tables: so let's place it next to PageTables.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Acked-by: NChristoph Lameter <cl@linux-foundation.org>
Acked-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This fixes:

  =============================================
  [ INFO: possible recursive locking detected ]
  2.6.27-rc5-00283-g70bb0896 #68
  ---------------------------------------------
  touch/6855 is trying to acquire lock:
   (&info->bfs_lock){--..}, at: [<c02262f5>] bfs_delete_inode+0x9e/0x18c

  but task is already holding lock:
   (&info->bfs_lock){--..}, at: [<c0226c00>] bfs_create+0x45/0x187

  other info that might help us debug this:
  2 locks held by touch/6855:
   #0:  (&type->i_mutex_dir_key#5){--..}, at: [<c018ad13>] do_filp_open+0x10b/0x62f
   #1:  (&info->bfs_lock){--..}, at: [<c0226c00>] bfs_create+0x45/0x187

  stack backtrace:
  Pid: 6855, comm: touch Not tainted 2.6.27-rc5-00283-g70bb0896 #68
   [<c013e769>] validate_chain+0x458/0x9f4
   [<c013bece>] ? trace_hardirqs_off+0xb/0xd
   [<c013f36b>] __lock_acquire+0x666/0x6e0
   [<c013f440>] lock_acquire+0x5b/0x77
   [<c02262f5>] ? bfs_delete_inode+0x9e/0x18c
   [<c06aab74>] mutex_lock_nested+0xbc/0x234
   [<c02262f5>] ? bfs_delete_inode+0x9e/0x18c
   [<c02262f5>] ? bfs_delete_inode+0x9e/0x18c
   [<c02262f5>] bfs_delete_inode+0x9e/0x18c
   [<c0226257>] ? bfs_delete_inode+0x0/0x18c
   [<c01925e1>] generic_delete_inode+0x94/0xfe
   [<c019265d>] generic_drop_inode+0x12/0x12f
   [<c0191b7e>] iput+0x4b/0x4e
   [<c0226d1e>] bfs_create+0x163/0x187
   [<c0188b42>] vfs_create+0xa6/0x114
   [<c018adb5>] do_filp_open+0x1ad/0x62f
   [<c0107cdc>] ? native_sched_clock+0x82/0x96
   [<c06ac309>] ? _spin_unlock+0x27/0x3c
   [<c019379e>] ? alloc_fd+0xbf/0xc9
   [<c06ae2f4>] ? sub_preempt_count+0x9d/0xab
   [<c019379e>] ? alloc_fd+0xbf/0xc9
   [<c0180391>] do_sys_open+0x42/0xb8
   [<c041d564>] ? trace_hardirqs_on_thunk+0xc/0x10
   [<c0180449>] sys_open+0x1e/0x26
   [<c01038bd>] sysenter_do_call+0x12/0x31
   =======================

The problem is that we don't unlock the bfs->lock mutex before calling
iput (we do in the other cases).
Signed-off-by: NEric Sesterhenn <snakebyte@gmx.de>
Cc: Tigran Aivazian <tigran@aivazian.fsnet.co.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There is no description of bit 4 of coredump_filter in the
documentation.  This patch adds it.
Signed-off-by: NHidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Roland McGrath <roland@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Acked-by: NKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If all the cpus in a cpuset are offlined, the tasks in it will be moved to
the nearest ancestor with non-empty cpus.
Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Acked-by: NPaul Jackson <pj@sgi.com>
Cc: Paul Menage <menage@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

After the patch:

commit 0b2f630a
Author: Miao Xie <miaox@cn.fujitsu.com>
Date:   Fri Jul 25 01:47:21 2008 -0700

    cpusets: restructure the function update_cpumask() and update_nodemask()

It might happen that 'echo 0 > /cpuset/sub/cpus' returned failure but 'cpus'
has been changed, because cpus was changed before calling heap_init() which
may return -ENOMEM.

This patch restores the orginal behavior.
Signed-off-by: NLi Zefan <lizf@cn.fujitsu.com>
Acked-by: NPaul Menage <menage@google.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

akpm: these have no callers at this time, but they shall soon, so let's
get them right.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NHiroshi DOYU <Hiroshi.DOYU@nokia.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Print parent directory name as well.

The aim is to catch non-creation of parent directory when proc_mkdir will
return NULL and all subsequent registrations go directly in /proc instead
of intended directory.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
[ Fixed insane printk string while at it.  - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
  sg: disable interrupts inside sg_copy_buffer

Change the MN10300 fault handler to make it check in_atomic() rather than
in_interrupt() as commit 6edaf68a did for other
architectures:

	Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
	Date:   Wed Dec 6 20:32:18 2006 -0800

	[PATCH] mm: arch do_page_fault() vs in_atomic()

	In light of the recent pagefault and filemap_copy_from_user work I've
	gone through all the arch pagefault handlers to make sure the
	inc_preempt_count() 'feature' works as expected.

	Several sections of code (including the new filemap_copy_from_user)
	rely on the fact that faults do not take locks under increased preempt
	count.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The callers of sg_copy_buffer must disable interrupts before calling
it (since it uses kmap_atomic). Some callers use it on
interrupt-disabled code but some need to take the trouble to disable
interrupts just for this. No wonder they forget about it and we hit a
bug like:

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

James said that it might be better to disable interrupts inside the
function rather than risk the callers getting it wrong.
Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

* 'for-linus' of git://git.kernel.dk/linux-2.6-block:
  block: disable sysfs parts of the disk command filter

* 'kvm-updates/2.6.27' of git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm:
  KVM: VMX: Always return old for clear_flush_young() when using EPT
  KVM: SVM: fix guest global tlb flushes with NPT
  KVM: SVM: fix random segfaults with NPT enabled

* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
  [SCSI] fix check of PQ and PDT bits for WLUNs
  [SCSI] make scsi_check_sense HARDWARE_ERROR return ADD_TO_MLQUEUE on retry
  [SCSI] scsi_dh: make check_sense return ADD_TO_MLQUEUE
  [SCSI] zfcp: Remove duplicated unlikely() macros.
  [SCSI] zfcp: channel cannot be detached due to refcount imbalance
  [SCSI] zfcp: Fix reference counter for remote ports
  [SCSI] zfcp: Simplify ccw notify handler
  [SCSI] zfcp: Correctly query end flag in gpn_ft response
  [SCSI] zfcp: Fix request queue locking
  [SCSI] sd: select CRC_T10DIF only when necessary

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6:
  [IA64] prevent ia64 from invoking irq handlers on offline CPUs
  [IA64] arch/ia64/sn/pci/tioca_provider.c: introduce missing kfree
  [IA64] fix up bte.h
  [IA64] fix compile failure with non modular builds

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-udf-2.6:
  udf: add llseek method
  udf: Fix error paths in udf_new_inode()
  udf: Fix lock inversion between iprune_mutex and alloc_mutex (v2)

We still have life time issues with the sysfs command filter kobject,
so disable it for 2.6.27 release. We can revisit this and make it work
properly for 2.6.28, for 2.6.27 release it's too risky.
Signed-off-by: NJens Axboe <jens.axboe@oracle.com>

As well as discard fake accessed bit and dirty bit of EPT.
Signed-off-by: NSheng Yang <sheng.yang@intel.com>
Signed-off-by: NAvi Kivity <avi@qumranet.com>

Accesses to CR4 are intercepted even with Nested Paging enabled. But the code
does not check if the guest wants to do a global TLB flush. So this flush gets
lost. This patch adds the check and the flush to svm_set_cr4.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NAvi Kivity <avi@qumranet.com>

This patch introduces a guest TLB flush on every NPF exit in KVM. This fixes
random segfaults and #UD exceptions in the guest seen under some workloads
(e.g. long running compile workloads or tbench). A kernbench run with and
without that fix showed that it has a slowdown lower than 0.5%

Cc: stable@kernel.org
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NAvi Kivity <avi@qumranet.com>

* git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6:
  add deprecated ide-scsi to feature-removal-schedule.txt
  ide: Fix pointer arithmetic in hpt3xx driver code (3rd try)

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

commit 0d3244d6 ("V4L/DVB (8342):
sh_mobile_ceu_camera: Add SuperH Mobile CEU driver V3") introduced
VIDEO_SH_MOBILE_CEU, which selects VIDEOBUF_DMA_CONTIG. This circumvents the
dependency on HAS_DMA of VIDEOBUF_DMA_CONTIG.

Add a dependency on HAS_DMA to VIDEO_SH_MOBILE_CEU to fix this.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NPaul Mundt <lethal@linux-sh.org>
Acked-by: NMagnus Damm <damm@igel.co.jp>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This fixes a SWIOTLB oops

With SWIOTLB being enabled and straight-forward page allocation
failure [1], the swiotlb_alloc_coherent fall-back path hits an
issue [2], resulting in my webcam failing to work.

At the time of oops, RDI is clearly a pointer to a structure which
has arrived as NULL, leading to the typo in swiotlb_map_single's
callsite arguments.

Correctly passing the device structure [3] addresses the issue and
gets my webcam working again (the allocation failure still occuring).

 --- [1]

skype: page allocation failure. order:3, mode:0x1
Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1

Call Trace:
 [<ffffffff802b7cf0>] __alloc_pages_internal+0x4a0/0x5d0
 [<ffffffff802d5ddd>] alloc_pages_current+0xad/0x110
 [<ffffffff802b4ccd>] __get_free_pages+0x1d/0x60
 [<ffffffff8046cd39>] swiotlb_alloc_coherent+0x49/0x180
 [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310
 [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90
 [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40
 [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo]
 [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo]
 [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo]
 [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo]
 [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
 [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
 [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev]
 [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo]
 [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30
 [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo]
 [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32]
 [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32]
 [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0
 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0
 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0
 [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
 [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c
 [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f

Mem-Info:
Node 0 DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
CPU    1: hi:    0, btch:   1 usd:   0
Node 0 DMA32 per-cpu:
CPU    0: hi:  186, btch:  31 usd:   3
CPU    1: hi:  186, btch:  31 usd:   0
Node 0 Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd:  23
CPU    1: hi:  186, btch:  31 usd: 179
Active:78545 inactive:48683 dirty:31 writeback:0 unstable:2
 free:830202 slab:17516 mapped:17473 pagetables:3496 bounce:0
Node 0 DMA free:36kB min:28kB low:32kB high:40kB active:0kB
inactive:0kB present:15156kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 3207 3956 3956
Node 0 DMA32 free:3197192kB min:6512kB low:8140kB high:9768kB
active:0kB inactive:0kB present:3284896kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0 748 748
Node 0 Normal free:123580kB min:1516kB low:1892kB high:2272kB
active:314180kB inactive:194732kB present:766464kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
Node 0 DMA: 1*4kB 0*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 36kB
Node 0 DMA32: 4*4kB 3*8kB 2*16kB 3*32kB 4*64kB 5*128kB 3*256kB 5*512kB
4*1024kB 5*2048kB 776*4096kB = 3197224kB
Node 0 Normal: 14*4kB 14*8kB 8*16kB 6*32kB 1*64kB 3*128kB 3*256kB
2*512kB 4*1024kB 1*2048kB 28*4096kB = 123560kB
64847 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 502752kB
Total swap = 502752kB
1048576 pages RAM
52120 pages reserved
71967 pages shared
143004 pages non-shared

 --- [2]

BUG: unable to handle kernel NULL pointer dereference at 00000000000002c8
IP: [<ffffffff8046c84c>] map_single+0x1c/0x280
PGD 10e54e067 PUD 10e595067 PMD 0
Oops: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: kvm_intel kvm microcode uvcvideo compat_ioctl32
videodev v4l1_compat shpchp pci_hotplug
Pid: 5895, comm: skype Not tainted 2.6.27-rc6-235c-debug #1
RIP: 0010:[<ffffffff8046c84c>]  [<ffffffff8046c84c>] map_single+0x1c/0x280
RSP: 0018:ffff88010e78d988  EFLAGS: 00210296
RAX: 0000780000000000 RBX: 0000000000000000 RCX: 0000000000000002
RDX: 0000000000005000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff88010e78d9e8 R08: 0000000000000000 R09: 0000000000000001
R10: ffff88010e78d698 R11: 0000000000000001 R12: 0000000000000002
R13: 0000000000000000 R14: 0000000000005000 R15: ffff88012f1c9968
FS:  0000000000000000(0000) GS:ffffffff80a6cdc0(0063) knlGS:00000000f6355b90
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000000002c8 CR3: 000000010e57d000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process skype (pid: 5895, threadinfo ffff88010e78c000, task ffff88012b9cc460)
Stack:  0000000200000000 0000000000005000 0000000000000000 0000000000000000
 00000000000017b8 0000000000000000 ffff88010e78d9c8 0000000000000000
 0000000000000002 0000000000000000 0000000000005000 ffff88012f1c9968
Call Trace:
 [<ffffffff8046cbb0>] swiotlb_map_single_attrs+0x60/0xf0
 [<ffffffff8046cc4c>] swiotlb_map_single+0xc/0x10
 [<ffffffff8046cdee>] swiotlb_alloc_coherent+0xfe/0x180
 [<ffffffff80212731>] dma_alloc_coherent+0x281/0x310
 [<ffffffff805621c0>] hcd_buffer_alloc+0x50/0x90
 [<ffffffff805547fd>] usb_buffer_alloc+0x2d/0x40
 [<ffffffffa0056763>] uvc_alloc_urb_buffers+0x53/0xf0 [uvcvideo]
 [<ffffffffa0056958>] uvc_init_video+0x158/0x3e0 [uvcvideo]
 [<ffffffffa0056c17>] uvc_video_enable+0x37/0x80 [uvcvideo]
 [<ffffffffa0055853>] uvc_v4l2_do_ioctl+0x723/0x1260 [uvcvideo]
 [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
 [<ffffffff8026dd61>] ? trace_hardirqs_off_caller+0x21/0xc0
 [<ffffffffa0032c9f>] video_usercopy+0x19f/0x390 [videodev]
 [<ffffffffa0055130>] ? uvc_v4l2_do_ioctl+0x0/0x1260 [uvcvideo]
 [<ffffffff8026d0ce>] ? put_lock_stats+0xe/0x30
 [<ffffffffa0054dad>] uvc_v4l2_ioctl+0x4d/0x80 [uvcvideo]
 [<ffffffffa0045083>] native_ioctl+0x83/0x90 [compat_ioctl32]
 [<ffffffffa004534e>] v4l_compat_ioctl32+0x2be/0x1da4 [compat_ioctl32]
 [<ffffffff806aad21>] ? do_page_fault+0x3d1/0xae0
 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff80270c59>] ? trace_hardirqs_on_caller+0x149/0x1b0
 [<ffffffff80270ccd>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff80329afa>] compat_sys_ioctl+0x8a/0x3c0
 [<ffffffff806a700d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
 [<ffffffff8022f816>] sysenter_dispatch+0x7/0x2c
 [<ffffffff806a6fce>] ? trace_hardirqs_on_thunk+0x3a/0x3f

Code: 45 31 c0 48 89 e5 e8 a4 ff ff ff c9 c3 66 90 55 48 89 e5 41 57
41 56 41 55 41 54 53 48 83 ec 38 48 89 75 b0 48 89 55 a8 89 4d a4 <48>
8b 87 c8 02 00 00 48 85 c0 0f 84 1c 02 00 00 48 8b 58 08 48
RIP  [<ffffffff8046c84c>] map_single+0x1c/0x280
 RSP <ffff88010e78d988>
CR2: 00000000000002c8
---[ end trace 5d15baeeb7025a0e ]---

 --- [3]

ffffffff8046c830 <map_single>:
map_single():
/store/kernel/linux/lib/swiotlb.c:291
ffffffff8046c830:       55                      push   %rbp
ffffffff8046c831:       48 89 e5                mov    %rsp,%rbp
ffffffff8046c834:       41 57                   push   %r15
ffffffff8046c836:       41 56                   push   %r14
ffffffff8046c838:       41 55                   push   %r13
ffffffff8046c83a:       41 54                   push   %r12
ffffffff8046c83c:       53                      push   %rbx
ffffffff8046c83d:       48 83 ec 38             sub    $0x38,%rsp
ffffffff8046c841:       48 89 75 b0             mov    %rsi,-0x50(%rbp)
ffffffff8046c845:       48 89 55 a8             mov    %rdx,-0x58(%rbp)
ffffffff8046c849:       89 4d a4                mov    %ecx,-0x5c(%rbp)
dma_get_seg_boundary():
/store/kernel/linux/include/linux/dma-mapping.h:80
ffffffff8046c84c:       48 8b 87 c8 02 00 00    mov    0x2c8(%rdi),%rax <----

 --- [4]
Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

git commit 74811f35 causes crash at
module load (or boot) time on my machine with a hpt374 controller.
The reason for this is that for initializing second controller which sets
(hwif->dev == host->dev[1]) to true (1), adds 1 to a void ptr, which
advances it by one byte instead of advancing it by sizeof(hpt_info) bytes.
Because of this, all initialization functions get corrupted data in info
variable which causes a crash at boot time.

This patch fixes that and makes my machine boot again.

The card itself is a HPT374 raid conroller: Here is the lspci -v output:
03:06.0 RAID bus controller: HighPoint Technologies, Inc. HPT374 (rev
07)
        Subsystem: HighPoint Technologies, Inc. Unknown device 0001
        Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 28
        I/O ports at 8000 [size=8]
        I/O ports at 7800 [size=4]
        I/O ports at 7400 [size=8]
        I/O ports at 7000 [size=4]
        I/O ports at 6800 [size=256]
        Expansion ROM at fe8e0000 [disabled] [size=128K]
        Capabilities: [60] Power Management version 2

03:06.1 RAID bus controller: HighPoint Technologies, Inc. HPT374 (rev
07)
        Subsystem: HighPoint Technologies, Inc. Unknown device 0001
        Flags: bus master, 66MHz, medium devsel, latency 120, IRQ 28
        I/O ports at 9800 [size=8]
        I/O ports at 9400 [size=4]
        I/O ports at 9000 [size=8]
        I/O ports at 8800 [size=4]
        I/O ports at 8400 [size=256]
        Capabilities: [60] Power Management version 2
Signed-off-by: NMasoud Sharbiani <masouds@google.com>
Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
[bart: use dev_get_drvdata() per Sergei's suggestion]
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

Make ia64 refrain from clearing a given to-be-offlined CPU's bit in the
cpu_online_mask until it has processed pending irqs.  This change
prevents other CPUs from being blindsided by an apparently offline CPU
nevertheless changing globally visible state.  Also remove the existing
redundant cpu_clear(cpu, cpu_online_map).
Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Error handling code following a kmalloc should free the allocated data.
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NTony Luck <tony.luck@intel.com>

bte.h expects a #define of L1_CACHE_MASK which is currently only
in bte.c.  This small patch gets bte.h to include cleanly and makes
BTE_UNALIGNED_COPY not report errors.
Signed-off-by: NRobin Holt <holt@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>