.33 patches

15 files changed, 711 insertions, 0 deletions

diff --git a/queue-2.6.33/blacklist-traxdata-cdr4120-and-iomega-zip-drive-to-avoid-lock-ups.patch b/queue-2.6.33/blacklist-traxdata-cdr4120-and-iomega-zip-drive-to-avoid-lock-ups.patch
new file mode 100644
index 0000000..8a709fe
--- /dev/null
+++ b/queue-2.6.33/blacklist-traxdata-cdr4120-and-iomega-zip-drive-to-avoid-lock-ups.patch
@@ -0,0 +1,40 @@
+From 82103978189e9731658cd32da5eb85ab7b8542b8 Mon Sep 17 00:00:00 2001
+From: Werner Fink <werner@novell.com>
+Date: Thu, 9 Jun 2011 10:54:24 +0530
+Subject: [SCSI] Blacklist Traxdata CDR4120 and IOMEGA Zip drive to avoid lock ups.
+
+From: Werner Fink <werner@novell.com>
+
+commit 82103978189e9731658cd32da5eb85ab7b8542b8 upstream.
+
+This patch resulted from the discussion at
+https://bugzilla.novell.com/show_bug.cgi?id=679277,
+https://bugzilla.novell.com/show_bug.cgi?id=681840 .
+
+Signed-off-by: Werner Fink <werner@novell.com>
+Signed-off-by: Ankit Jain <jankit@suse.de>
+Signed-off-by: James Bottomley <JBottomley@Parallels.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/scsi/scsi_devinfo.c |    2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/scsi/scsi_devinfo.c
++++ b/drivers/scsi/scsi_devinfo.c
+@@ -196,6 +196,7 @@ static struct {
+ 	{"IBM", "ProFibre 4000R", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
+ 	{"IBM", "2105", NULL, BLIST_RETRY_HWERROR},
+ 	{"iomega", "jaz 1GB", "J.86", BLIST_NOTQ | BLIST_NOLUN},
++	{"IOMEGA", "ZIP", NULL, BLIST_NOTQ | BLIST_NOLUN},
+ 	{"IOMEGA", "Io20S         *F", NULL, BLIST_KEY},
+ 	{"INSITE", "Floptical   F*8I", NULL, BLIST_KEY},
+ 	{"INSITE", "I325VM", NULL, BLIST_KEY},
+@@ -242,6 +243,7 @@ static struct {
+ 	{"Tornado-", "F4", "*", BLIST_NOREPORTLUN},
+ 	{"TOSHIBA", "CDROM", NULL, BLIST_ISROM},
+ 	{"TOSHIBA", "CD-ROM", NULL, BLIST_ISROM},
++	{"Traxdata", "CDR4120", NULL, BLIST_NOLUN},	/* locks up */
+ 	{"USB2.0", "SMARTMEDIA/XD", NULL, BLIST_FORCELUN | BLIST_INQUIRY_36},
+ 	{"WangDAT", "Model 2600", "01.7", BLIST_SELECT_NO_ATN},
+ 	{"WangDAT", "Model 3200", "02.2", BLIST_SELECT_NO_ATN},
diff --git a/queue-2.6.33/cciss-do-not-attempt-to-read-from-a-write-only-register.patch b/queue-2.6.33/cciss-do-not-attempt-to-read-from-a-write-only-register.patch
new file mode 100644
index 0000000..531362b
--- /dev/null
+++ b/queue-2.6.33/cciss-do-not-attempt-to-read-from-a-write-only-register.patch
@@ -0,0 +1,32 @@
+From 07d0c38e7d84f911c72058a124c7f17b3c779a65 Mon Sep 17 00:00:00 2001
+From: "Stephen M. Cameron" <scameron@beardog.cce.hp.com>
+Date: Sat, 9 Jul 2011 09:04:12 +0200
+Subject: cciss: do not attempt to read from a write-only register
+
+From: "Stephen M. Cameron" <scameron@beardog.cce.hp.com>
+
+commit 07d0c38e7d84f911c72058a124c7f17b3c779a65 upstream.
+
+Most smartarrays will tolerate it, but some new ones don't.
+
+Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
+
+Note: this is a regression caused by commit 1ddd5049
+Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/block/cciss.h |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/block/cciss.h
++++ b/drivers/block/cciss.h
+@@ -181,7 +181,7 @@ static void SA5_submit_command( ctlr_inf
+ 	 printk("Sending %x - down to controller\n", c->busaddr );
+ #endif /* CCISS_DEBUG */ 
+          writel(c->busaddr, h->vaddr + SA5_REQUEST_PORT_OFFSET);
+-	readl(h->vaddr + SA5_REQUEST_PORT_OFFSET);
++	readl(h->vaddr + SA5_SCRATCHPAD_OFFSET);
+ 	 h->commands_outstanding++;
+ 	 if ( h->commands_outstanding > h->max_outstanding)
+ 		h->max_outstanding = h->commands_outstanding;
diff --git a/queue-2.6.33/ehci-fix-direction-handling-for-interrupt-data-toggles.patch b/queue-2.6.33/ehci-fix-direction-handling-for-interrupt-data-toggles.patch
new file mode 100644
index 0000000..d4ab832
--- /dev/null
+++ b/queue-2.6.33/ehci-fix-direction-handling-for-interrupt-data-toggles.patch
@@ -0,0 +1,72 @@
+From e04f5f7e423018bcec84c11af2058cdce87816f3 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Tue, 19 Jul 2011 14:01:23 -0400
+Subject: EHCI: fix direction handling for interrupt data toggles
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit e04f5f7e423018bcec84c11af2058cdce87816f3 upstream.
+
+This patch (as1480) fixes a rather obscure bug in ehci-hcd.  The
+qh_update() routine needs to know the number and direction of the
+endpoint corresponding to its QH argument.  The number can be taken
+directly from the QH data structure, but the direction isn't stored
+there.  The direction is taken instead from the first qTD linked to
+the QH.
+
+However, it turns out that for interrupt transfers, qh_update() gets
+called before the qTDs are linked to the QH.  As a result, qh_update()
+computes a bogus direction value, which messes up the endpoint toggle
+handling.  Under the right combination of circumstances this causes
+usb_reset_endpoint() not to work correctly, which causes packets to be
+dropped and communications to fail.
+
+Now, it's silly for the QH structure not to have direct access to all
+the descriptor information for the corresponding endpoint.  Ultimately
+it may get a pointer to the usb_host_endpoint structure; for now,
+adding a copy of the direction flag solves the immediate problem.
+
+This allows the Spyder2 color-calibration system (a low-speed USB
+device that sends all its interrupt data packets with the toggle set
+to 0 and hance requires constant use of usb_reset_endpoint) to work
+when connected through a high-speed hub.  Thanks to Graeme Gill for
+supplying the hardware that allowed me to track down this bug.
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-by: Graeme Gill <graeme@argyllcms.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/host/ehci-q.c |    3 ++-
+ drivers/usb/host/ehci.h   |    1 +
+ 2 files changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/ehci-q.c
++++ b/drivers/usb/host/ehci-q.c
+@@ -103,7 +103,7 @@ qh_update (struct ehci_hcd *ehci, struct
+ 	if (!(hw->hw_info1 & cpu_to_hc32(ehci, 1 << 14))) {
+ 		unsigned	is_out, epnum;
+ 
+-		is_out = !(qtd->hw_token & cpu_to_hc32(ehci, 1 << 8));
++		is_out = qh->is_out;
+ 		epnum = (hc32_to_cpup(ehci, &hw->hw_info1) >> 8) & 0x0f;
+ 		if (unlikely (!usb_gettoggle (qh->dev, epnum, is_out))) {
+ 			hw->hw_token &= ~cpu_to_hc32(ehci, QTD_TOGGLE);
+@@ -945,6 +945,7 @@ done:
+ 	hw = qh->hw;
+ 	hw->hw_info1 = cpu_to_hc32(ehci, info1);
+ 	hw->hw_info2 = cpu_to_hc32(ehci, info2);
++	qh->is_out = !is_input;
+ 	usb_settoggle (urb->dev, usb_pipeendpoint (urb->pipe), !is_input, 1);
+ 	qh_refresh (ehci, qh);
+ 	return qh;
+--- a/drivers/usb/host/ehci.h
++++ b/drivers/usb/host/ehci.h
+@@ -365,6 +365,7 @@ struct ehci_qh {
+ #define NO_FRAME ((unsigned short)~0)			/* pick new start */
+ 
+ 	struct usb_device	*dev;		/* access to TT */
++	unsigned		is_out:1;	/* bulk or intr OUT */
+ 	unsigned		clearing_tt:1;	/* Clear-TT-Buf in progress */
+ };
+ 
diff --git a/queue-2.6.33/ehci-only-power-off-port-if-over-current-is-active.patch b/queue-2.6.33/ehci-only-power-off-port-if-over-current-is-active.patch
new file mode 100644
index 0000000..0583723
--- /dev/null
+++ b/queue-2.6.33/ehci-only-power-off-port-if-over-current-is-active.patch
@@ -0,0 +1,43 @@
+From 81463c1d707186adbbe534016cd1249edeab0dac Mon Sep 17 00:00:00 2001
+From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
+Date: Wed, 6 Jul 2011 23:19:38 +0400
+Subject: EHCI: only power off port if over-current is active
+
+From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
+
+commit 81463c1d707186adbbe534016cd1249edeab0dac upstream.
+
+MAX4967 USB power supply chip we use on our boards signals over-current when
+power is not enabled; once it's enabled, over-current signal returns to normal.
+That unfortunately caused the endless stream of "over-current change on port"
+messages. The EHCI root hub code reacts on every over-current signal change
+with powering off the port -- such change event is generated the moment the
+port power is enabled, so once enabled the power is immediately cut off.
+I think we should only cut off power when we're seeing the active over-current
+signal, so I'm adding such check to that code. I also think that the fact that
+we've cut off the port power should be reflected in the result of GetPortStatus
+request immediately, hence I'm adding a PORTSCn register readback after write...
+
+Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
+Acked-by: Alan Stern <stern@rowland.harvard.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/usb/host/ehci-hub.c |    3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/usb/host/ehci-hub.c
++++ b/drivers/usb/host/ehci-hub.c
+@@ -760,10 +760,11 @@ static int ehci_hub_control (
+ 			 * power switching; they're allowed to just limit the
+ 			 * current.  khubd will turn the power back on.
+ 			 */
+-			if (HCS_PPC (ehci->hcs_params)){
++			if ((temp & PORT_OC) && HCS_PPC(ehci->hcs_params)) {
+ 				ehci_writel(ehci,
+ 					temp & ~(PORT_RWC_BITS | PORT_POWER),
+ 					status_reg);
++				temp = ehci_readl(ehci, status_reg);
+ 			}
+ 		}
+ 
diff --git a/queue-2.6.33/ext3-fix-oops-in-ext3_try_to_allocate_with_rsv.patch b/queue-2.6.33/ext3-fix-oops-in-ext3_try_to_allocate_with_rsv.patch
new file mode 100644
index 0000000..35afa26
--- /dev/null
+++ b/queue-2.6.33/ext3-fix-oops-in-ext3_try_to_allocate_with_rsv.patch
@@ -0,0 +1,50 @@
+From ad95c5e9bc8b5885f94dce720137cac8fa8da4c9 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Mon, 30 May 2011 13:29:20 +0200
+Subject: ext3: Fix oops in ext3_try_to_allocate_with_rsv()
+
+From: Jan Kara <jack@suse.cz>
+
+commit ad95c5e9bc8b5885f94dce720137cac8fa8da4c9 upstream.
+
+Block allocation is called from two places: ext3_get_blocks_handle() and
+ext3_xattr_block_set(). These two callers are not necessarily synchronized
+because xattr code holds only xattr_sem and i_mutex, and
+ext3_get_blocks_handle() may hold only truncate_mutex when called from
+writepage() path. Block reservation code does not expect two concurrent
+allocations to happen to the same inode and thus assertions can be triggered
+or reservation structure corruption can occur.
+
+Fix the problem by taking truncate_mutex in xattr code to serialize
+allocations.
+
+CC: Sage Weil <sage@newdream.net>
+Reported-by: Fyodor Ustinov <ufm@ufm.su>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ fs/ext3/xattr.c |   12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/fs/ext3/xattr.c
++++ b/fs/ext3/xattr.c
+@@ -803,8 +803,16 @@ inserted:
+ 			/* We need to allocate a new block */
+ 			ext3_fsblk_t goal = ext3_group_first_block_no(sb,
+ 						EXT3_I(inode)->i_block_group);
+-			ext3_fsblk_t block = ext3_new_block(handle, inode,
+-							goal, &error);
++			ext3_fsblk_t block;
++
++			/*
++			 * Protect us agaist concurrent allocations to the
++			 * same inode from ext3_..._writepage(). Reservation
++			 * code does not expect racing allocations.
++			 */
++			mutex_lock(&EXT3_I(inode)->truncate_mutex);
++			block = ext3_new_block(handle, inode, goal, &error);
++			mutex_unlock(&EXT3_I(inode)->truncate_mutex);
+ 			if (error)
+ 				goto cleanup;
+ 			ea_idebug(inode, "creating block %d", block);
diff --git a/queue-2.6.33/fix-crash-in-scsi_dispatch_cmd.patch b/queue-2.6.33/fix-crash-in-scsi_dispatch_cmd.patch
new file mode 100644
index 0000000..15654aa
--- /dev/null
+++ b/queue-2.6.33/fix-crash-in-scsi_dispatch_cmd.patch
@@ -0,0 +1,71 @@
+From bfe159a51203c15d23cb3158fffdc25ec4b4dda1 Mon Sep 17 00:00:00 2001
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+Date: Thu, 7 Jul 2011 15:45:40 -0500
+Subject: [SCSI] fix crash in scsi_dispatch_cmd()
+
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+
+commit bfe159a51203c15d23cb3158fffdc25ec4b4dda1 upstream.
+
+USB surprise removal of sr is triggering an oops in
+scsi_dispatch_command().  What seems to be happening is that USB is
+hanging on to a queue reference until the last close of the upper
+device, so the crash is caused by surprise remove of a mounted CD
+followed by attempted unmount.
+
+The problem is that USB doesn't issue its final commands as part of
+the SCSI teardown path, but on last close when the block queue is long
+gone.  The long term fix is probably to make sr do the teardown in the
+same way as sd (so remove all the lower bits on ejection, but keep the
+upper disk alive until last close of user space).  However, the
+current oops can be simply fixed by not allowing any commands to be
+sent to a dead queue.
+
+Signed-off-by: James Bottomley <JBottomley@Parallels.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ block/blk-core.c        |    3 +++
+ block/blk-exec.c        |    7 +++++++
+ drivers/scsi/scsi_lib.c |    2 ++
+ 3 files changed, 12 insertions(+)
+
+--- a/block/blk-core.c
++++ b/block/blk-core.c
+@@ -865,6 +865,9 @@ struct request *blk_get_request(struct r
+ {
+ 	struct request *rq;
+ 
++	if (unlikely(test_bit(QUEUE_FLAG_DEAD, &q->queue_flags)))
++		return NULL;
++
+ 	BUG_ON(rw != READ && rw != WRITE);
+ 
+ 	spin_lock_irq(q->queue_lock);
+--- a/block/blk-exec.c
++++ b/block/blk-exec.c
+@@ -50,6 +50,13 @@ void blk_execute_rq_nowait(struct reques
+ {
+ 	int where = at_head ? ELEVATOR_INSERT_FRONT : ELEVATOR_INSERT_BACK;
+ 
++	if (unlikely(test_bit(QUEUE_FLAG_DEAD, &q->queue_flags))) {
++		rq->errors = -ENXIO;
++		if (rq->end_io)
++			rq->end_io(rq, rq->errors);
++		return;
++	}
++
+ 	rq->rq_disk = bd_disk;
+ 	rq->end_io = done;
+ 	WARN_ON(irqs_disabled());
+--- a/drivers/scsi/scsi_lib.c
++++ b/drivers/scsi/scsi_lib.c
+@@ -215,6 +215,8 @@ int scsi_execute(struct scsi_device *sde
+ 	int ret = DRIVER_ERROR << 24;
+ 
+ 	req = blk_get_request(sdev->request_queue, write, __GFP_WAIT);
++	if (!req)
++		return ret;
+ 
+ 	if (bufflen &&	blk_rq_map_kern(sdev->request_queue, req,
+ 					buffer, bufflen, __GFP_WAIT))
diff --git a/queue-2.6.33/geode-reflect-mfgpt-dependency-on-mfd.patch b/queue-2.6.33/geode-reflect-mfgpt-dependency-on-mfd.patch
new file mode 100644
index 0000000..cea02f0
--- /dev/null
+++ b/queue-2.6.33/geode-reflect-mfgpt-dependency-on-mfd.patch
@@ -0,0 +1,43 @@
+From 703f03c896fdbd726b809066ae279df513992f0e Mon Sep 17 00:00:00 2001
+From: "Philip A. Prindeville" <philipp@redfish-solutions.com>
+Date: Mon, 25 Jul 2011 17:13:05 -0700
+Subject: geode: reflect mfgpt dependency on mfd
+
+From: "Philip A. Prindeville" <philipp@redfish-solutions.com>
+
+commit 703f03c896fdbd726b809066ae279df513992f0e upstream.
+
+As stated in drivers/mfd/cs5535-mfd.c, the mfd driver exposes the BARs
+which then make the GPIO, MFGPT, ACPI, etc.  all visible to the system.
+
+So the dependencies of the MFGPT stuff have changed, and most people
+expect Kconfig to bring in the necessary dependencies.  Without them, the
+module fails to load and most people don't understand why because the
+details of the rewrite aren't captured anywhere most people who know to
+look.
+
+This dependency needs to be reflected in Kconfig.
+
+Signed-off-by: Philip A. Prindeville <philipp@redfish-solutions.com>
+Acked-by: Alexandros C. Couloumbis <alex@ozo.com>
+Acked-by: Andres Salomon <dilinger@queued.net>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/misc/Kconfig |    3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/misc/Kconfig
++++ b/drivers/misc/Kconfig
+@@ -189,8 +189,7 @@ config SGI_XP
+ 
+ config CS5535_MFGPT
+ 	tristate "CS5535/CS5536 Geode Multi-Function General Purpose Timer (MFGPT) support"
+-	depends on PCI
+-	depends on X86
++	depends on PCI && X86 && MFD_CS5535
+ 	default n
+ 	help
+ 	  This driver provides access to MFGPT functionality for other
diff --git a/queue-2.6.33/kexec-x86-fix-incorrect-jump-back-address-if-not.patch b/queue-2.6.33/kexec-x86-fix-incorrect-jump-back-address-if-not.patch
new file mode 100644
index 0000000..7fc8431
--- /dev/null
+++ b/queue-2.6.33/kexec-x86-fix-incorrect-jump-back-address-if-not.patch
@@ -0,0 +1,57 @@
+From 050438ed5a05b25cdf287f5691e56a58c2606997 Mon Sep 17 00:00:00 2001
+From: Huang Ying <ying.huang@intel.com>
+Date: Thu, 14 Jul 2011 09:34:37 +0800
+Subject: kexec, x86: Fix incorrect jump back address if not
+ preserving context
+
+From: Huang Ying <ying.huang@intel.com>
+
+commit 050438ed5a05b25cdf287f5691e56a58c2606997 upstream.
+
+In kexec jump support, jump back address passed to the kexeced
+kernel via function calling ABI, that is, the function call
+return address is the jump back entry.
+
+Furthermore, jump back entry == 0 should be used to signal that
+the jump back or preserve context is not enabled in the original
+kernel.
+
+But in the current implementation the stack position used for
+function call return address is not cleared context
+preservation is disabled. The patch fixes this bug.
+
+Reported-and-tested-by: Yin Kangkai <kangkai.yin@intel.com>
+Signed-off-by: Huang Ying <ying.huang@intel.com>
+Cc: Eric W. Biederman <ebiederm@xmission.com>
+Cc: Vivek Goyal <vgoyal@redhat.com>
+Link: http://lkml.kernel.org/r/1310607277-25029-1-git-send-email-ying.huang@intel.com
+Signed-off-by: Ingo Molnar <mingo@elte.hu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/x86/kernel/relocate_kernel_32.S |    2 ++
+ arch/x86/kernel/relocate_kernel_64.S |    2 ++
+ 2 files changed, 4 insertions(+)
+
+--- a/arch/x86/kernel/relocate_kernel_32.S
++++ b/arch/x86/kernel/relocate_kernel_32.S
+@@ -97,6 +97,8 @@ relocate_kernel:
+ 	ret
+ 
+ identity_mapped:
++	/* set return address to 0 if not preserving context */
++	pushl	$0
+ 	/* store the start address on the stack */
+ 	pushl   %edx
+ 
+--- a/arch/x86/kernel/relocate_kernel_64.S
++++ b/arch/x86/kernel/relocate_kernel_64.S
+@@ -100,6 +100,8 @@ relocate_kernel:
+ 	ret
+ 
+ identity_mapped:
++	/* set return address to 0 if not preserving context */
++	pushq	$0
+ 	/* store the start address on the stack */
+ 	pushq   %rdx
+ 
diff --git a/queue-2.6.33/pci-ari-is-a-pcie-v2-feature.patch b/queue-2.6.33/pci-ari-is-a-pcie-v2-feature.patch
new file mode 100644
index 0000000..8f49995
--- /dev/null
+++ b/queue-2.6.33/pci-ari-is-a-pcie-v2-feature.patch
@@ -0,0 +1,50 @@
+From 864d296cf948aef0fa32b81407541572583f7572 Mon Sep 17 00:00:00 2001
+From: Chris Wright <chrisw@sous-sol.org>
+Date: Wed, 13 Jul 2011 10:14:33 -0700
+Subject: PCI: ARI is a PCIe v2 feature
+
+From: Chris Wright <chrisw@sous-sol.org>
+
+commit 864d296cf948aef0fa32b81407541572583f7572 upstream.
+
+The function pci_enable_ari() may mistakenly set the downstream port
+of a v1 PCIe switch in ARI Forwarding mode.  This is a PCIe v2 feature,
+and with an SR-IOV device on that switch port believing the switch above
+is ARI capable it may attempt to use functions 8-255, translating into
+invalid (non-zero) device numbers for that bus.  This has been seen
+to cause Completion Timeouts and general misbehaviour including hangs
+and panics.
+
+Acked-by: Don Dutile <ddutile@redhat.com>
+Tested-by: Don Dutile <ddutile@redhat.com>
+Signed-off-by: Chris Wright <chrisw@sous-sol.org>
+Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/pci/pci.c |    7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/pci/pci.c
++++ b/drivers/pci/pci.c
+@@ -1528,7 +1528,7 @@ void pci_enable_ari(struct pci_dev *dev)
+ {
+ 	int pos;
+ 	u32 cap;
+-	u16 ctrl;
++	u16 flags, ctrl;
+ 	struct pci_dev *bridge;
+ 
+ 	if (!pci_is_pcie(dev) || dev->devfn)
+@@ -1546,6 +1546,11 @@ void pci_enable_ari(struct pci_dev *dev)
+ 	if (!pos)
+ 		return;
+ 
++	/* ARI is a PCIe v2 feature */
++	pci_read_config_word(bridge, pos + PCI_EXP_FLAGS, &flags);
++	if ((flags & PCI_EXP_FLAGS_VERS) < 2)
++		return;
++
+ 	pci_read_config_dword(bridge, pos + PCI_EXP_DEVCAP2, &cap);
+ 	if (!(cap & PCI_EXP_DEVCAP2_ARI))
+ 		return;
diff --git a/queue-2.6.33/pmcraid-reject-negative-request-size.patch b/queue-2.6.33/pmcraid-reject-negative-request-size.patch
new file mode 100644
index 0000000..499253c
--- /dev/null
+++ b/queue-2.6.33/pmcraid-reject-negative-request-size.patch
@@ -0,0 +1,52 @@
+From b5b515445f4f5a905c5dd27e6e682868ccd6c09d Mon Sep 17 00:00:00 2001
+From: Dan Rosenberg <drosenberg@vsecurity.com>
+Date: Mon, 11 Jul 2011 14:08:23 -0700
+Subject: [SCSI] pmcraid: reject negative request size
+
+From: Dan Rosenberg <drosenberg@vsecurity.com>
+
+commit b5b515445f4f5a905c5dd27e6e682868ccd6c09d upstream.
+
+There's a code path in pmcraid that can be reached via device ioctl that
+causes all sorts of ugliness, including heap corruption or triggering the
+OOM killer due to consecutive allocation of large numbers of pages.
+
+First, the user can call pmcraid_chr_ioctl(), with a type
+PMCRAID_PASSTHROUGH_IOCTL.  This calls through to
+pmcraid_ioctl_passthrough().  Next, a pmcraid_passthrough_ioctl_buffer
+is copied in, and the request_size variable is set to
+buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit
+signed value provided by the user.  If a negative value is provided
+here, bad things can happen.  For example,
+pmcraid_build_passthrough_ioadls() is called with this request_size,
+which immediately calls pmcraid_alloc_sglist() with a negative size.
+The resulting math on allocating a scatter list can result in an
+overflow in the kzalloc() call (if num_elem is 0, the sglist will be
+smaller than expected), or if num_elem is unexpectedly large the
+subsequent loop will call alloc_pages() repeatedly, a high number of
+pages will be allocated and the OOM killer might be invoked.
+
+It looks like preventing this value from being negative in
+pmcraid_ioctl_passthrough() would be sufficient.
+
+Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: James Bottomley <JBottomley@Parallels.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/scsi/pmcraid.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/scsi/pmcraid.c
++++ b/drivers/scsi/pmcraid.c
+@@ -3576,6 +3576,9 @@ static long pmcraid_ioctl_passthrough(
+ 			pmcraid_err("couldn't build passthrough ioadls\n");
+ 			goto out_free_buffer;
+ 		}
++	} else if (request_size < 0) {
++		rc = -EINVAL;
++		goto out_free_buffer;
+ 	}
+ 
+ 	/* If data is being written into the device, copy the data from user
diff --git a/queue-2.6.33/powerpc-kdump-fix-timeout-in-crash_kexec_wait_realmode.patch b/queue-2.6.33/powerpc-kdump-fix-timeout-in-crash_kexec_wait_realmode.patch
new file mode 100644
index 0000000..be2c65b
--- /dev/null
+++ b/queue-2.6.33/powerpc-kdump-fix-timeout-in-crash_kexec_wait_realmode.patch
@@ -0,0 +1,43 @@
+From 63f21a56f1cc0b800a4c00349c59448f82473d19 Mon Sep 17 00:00:00 2001
+From: Michael Neuling <mikey@neuling.org>
+Date: Mon, 4 Jul 2011 20:40:10 +0000
+Subject: powerpc/kdump: Fix timeout in crash_kexec_wait_realmode
+
+From: Michael Neuling <mikey@neuling.org>
+
+commit 63f21a56f1cc0b800a4c00349c59448f82473d19 upstream.
+
+The existing code it pretty ugly.  How about we clean it up even more
+like this?
+
+From: Anton Blanchard <anton@samba.org>
+
+We check for timeout expiry in the outer loop, but we also need to
+check it in the inner loop or we can lock up forever waiting for a
+CPU to hit real mode.
+
+Signed-off-by: Anton Blanchard <anton@samba.org>
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/powerpc/kernel/crash.c |    6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/arch/powerpc/kernel/crash.c
++++ b/arch/powerpc/kernel/crash.c
+@@ -176,12 +176,8 @@ static void crash_kexec_wait_realmode(in
+ 
+ 		while (paca[i].kexec_state < KEXEC_STATE_REAL_MODE) {
+ 			barrier();
+-			if (!cpu_possible(i)) {
++			if (!cpu_possible(i) || !cpu_online(i) || (msecs <= 0))
+ 				break;
+-			}
+-			if (!cpu_online(i)) {
+-				break;
+-			}
+ 			msecs--;
+ 			mdelay(1);
+ 		}
diff --git a/queue-2.6.33/series b/queue-2.6.33/series
index d241b08..c921a49 100644
--- a/queue-2.6.33/series
+++ b/queue-2.6.33/series
@@ -22,3 +22,17 @@ arm-pxa-cm-x300-fix-v3020-rtc-functionality.patch
 jme-fix-unmap-error-causing-system-freeze.patch
 libsas-remove-expander-from-dev-list-on-error.patch
 mac80211-restart-sta-timers-only-on-associated-state.patch
+blacklist-traxdata-cdr4120-and-iomega-zip-drive-to-avoid-lock-ups.patch
+ses-requesting-a-fault-indication.patch
+fix-crash-in-scsi_dispatch_cmd.patch
+pmcraid-reject-negative-request-size.patch
+kexec-x86-fix-incorrect-jump-back-address-if-not.patch
+powerpc-kdump-fix-timeout-in-crash_kexec_wait_realmode.patch
+pci-ari-is-a-pcie-v2-feature.patch
+cciss-do-not-attempt-to-read-from-a-write-only-register.patch
+geode-reflect-mfgpt-dependency-on-mfd.patch
+xtensa-prevent-arbitrary-read-in-ptrace.patch
+ext3-fix-oops-in-ext3_try_to_allocate_with_rsv.patch
+svcrpc-fix-list-corrupting-race-on-nfsd-shutdown.patch
+ehci-only-power-off-port-if-over-current-is-active.patch
+ehci-fix-direction-handling-for-interrupt-data-toggles.patch
diff --git a/queue-2.6.33/ses-requesting-a-fault-indication.patch b/queue-2.6.33/ses-requesting-a-fault-indication.patch
new file mode 100644
index 0000000..d9197c0
--- /dev/null
+++ b/queue-2.6.33/ses-requesting-a-fault-indication.patch
@@ -0,0 +1,54 @@
+From 2a350cab9daf9a46322d83b091bb05cf54ccf6ab Mon Sep 17 00:00:00 2001
+From: Douglas Gilbert <dgilbert@interlog.com>
+Date: Thu, 9 Jun 2011 00:27:07 -0400
+Subject: [SCSI] ses: requesting a fault indication
+
+From: Douglas Gilbert <dgilbert@interlog.com>
+
+commit 2a350cab9daf9a46322d83b091bb05cf54ccf6ab upstream.
+
+Noticed that when the sysfs interface of the SCSI SES
+driver was used to request a fault indication the LED
+flashed but the buzzer didn't sound. So it was doing
+what REQUEST IDENT (locate) should do.
+
+Changelog:
+   - fix the setting of REQUEST FAULT for the device slot
+     and array device slot elements in the enclosure control
+     diagnostic page
+   - note the potentially defective code that reads the
+     FAULT SENSED and FAULT REQUESTED bits from the enclosure
+     status diagnostic page
+
+The attached patch is against git/scsi-misc-2.6
+
+Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
+Signed-off-by: James Bottomley <JBottomley@Parallels.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ drivers/scsi/ses.c |    6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/ses.c
++++ b/drivers/scsi/ses.c
+@@ -157,6 +157,10 @@ static unsigned char *ses_get_page2_desc
+ 	return NULL;
+ }
+ 
++/* For device slot and array device slot elements, byte 3 bit 6
++ * is "fault sensed" while byte 3 bit 5 is "fault reqstd". As this
++ * code stands these bits are shifted 4 positions right so in
++ * sysfs they will appear as bits 2 and 1 respectively. Strange. */
+ static void ses_get_fault(struct enclosure_device *edev,
+ 			  struct enclosure_component *ecomp)
+ {
+@@ -178,7 +182,7 @@ static int ses_set_fault(struct enclosur
+ 		/* zero is disabled */
+ 		break;
+ 	case ENCLOSURE_SETTING_ENABLED:
+-		desc[2] = 0x02;
++		desc[3] = 0x20;
+ 		break;
+ 	default:
+ 		/* SES doesn't do the SGPIO blink settings */
diff --git a/queue-2.6.33/svcrpc-fix-list-corrupting-race-on-nfsd-shutdown.patch b/queue-2.6.33/svcrpc-fix-list-corrupting-race-on-nfsd-shutdown.patch
new file mode 100644
index 0000000..caf2530
--- /dev/null
+++ b/queue-2.6.33/svcrpc-fix-list-corrupting-race-on-nfsd-shutdown.patch
@@ -0,0 +1,54 @@
+From ebc63e531cc6a457595dd110b07ac530eae788c3 Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Wed, 29 Jun 2011 16:49:04 -0400
+Subject: svcrpc: fix list-corrupting race on nfsd shutdown
+
+From: "J. Bruce Fields" <bfields@redhat.com>
+
+commit ebc63e531cc6a457595dd110b07ac530eae788c3 upstream.
+
+After commit 3262c816a3d7fb1eaabce633caa317887ed549ae "[PATCH] knfsd:
+split svc_serv into pools", svc_delete_xprt (then svc_delete_socket) no
+longer removed its xpt_ready (then sk_ready) field from whatever list it
+was on, noting that there was no point since the whole list was about to
+be destroyed anyway.
+
+That was mostly true, but forgot that a few svc_xprt_enqueue()'s might
+still be hanging around playing with the about-to-be-destroyed list, and
+could get themselves into trouble writing to freed memory if we left
+this xprt on the list after freeing it.
+
+(This is actually functionally identical to a patch made first by Ben
+Greear, but with more comments.)
+
+Cc: gnb@fmeh.org
+Reported-by: Ben Greear <greearb@candelatech.com>
+Tested-by: Ben Greear <greearb@candelatech.com>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ net/sunrpc/svc_xprt.c |   11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+--- a/net/sunrpc/svc_xprt.c
++++ b/net/sunrpc/svc_xprt.c
+@@ -884,12 +884,13 @@ void svc_delete_xprt(struct svc_xprt *xp
+ 	if (!test_and_set_bit(XPT_DETACHED, &xprt->xpt_flags))
+ 		list_del_init(&xprt->xpt_list);
+ 	/*
+-	 * We used to delete the transport from whichever list
+-	 * it's sk_xprt.xpt_ready node was on, but we don't actually
+-	 * need to.  This is because the only time we're called
+-	 * while still attached to a queue, the queue itself
+-	 * is about to be destroyed (in svc_destroy).
++	 * The only time we're called while xpt_ready is still on a list
++	 * is while the list itself is about to be destroyed (in
++	 * svc_destroy).  BUT svc_xprt_enqueue could still be attempting
++	 * to add new entries to the sp_sockets list, so we can't leave
++	 * a freed xprt on it.
+ 	 */
++	list_del_init(&xprt->xpt_ready);
+ 	if (test_bit(XPT_TEMP, &xprt->xpt_flags))
+ 		serv->sv_tmpcnt--;
+ 
diff --git a/queue-2.6.33/xtensa-prevent-arbitrary-read-in-ptrace.patch b/queue-2.6.33/xtensa-prevent-arbitrary-read-in-ptrace.patch
new file mode 100644
index 0000000..c1a2121
--- /dev/null
+++ b/queue-2.6.33/xtensa-prevent-arbitrary-read-in-ptrace.patch
@@ -0,0 +1,36 @@
+From 0d0138ebe24b94065580bd2601f8bb7eb6152f56 Mon Sep 17 00:00:00 2001
+From: Dan Rosenberg <drosenberg@vsecurity.com>
+Date: Mon, 25 Jul 2011 17:11:53 -0700
+Subject: xtensa: prevent arbitrary read in ptrace
+
+From: Dan Rosenberg <drosenberg@vsecurity.com>
+
+commit 0d0138ebe24b94065580bd2601f8bb7eb6152f56 upstream.
+
+Prevent an arbitrary kernel read.  Check the user pointer with access_ok()
+before copying data in.
+
+[akpm@linux-foundation.org: s/EIO/EFAULT/]
+Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
+Cc: Christian Zankel <chris@zankel.net>
+Cc: Oleg Nesterov <oleg@redhat.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
+
+---
+ arch/xtensa/kernel/ptrace.c |    3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/arch/xtensa/kernel/ptrace.c
++++ b/arch/xtensa/kernel/ptrace.c
+@@ -136,6 +136,9 @@ int ptrace_setxregs(struct task_struct *
+ 	elf_xtregs_t *xtregs = uregs;
+ 	int ret = 0;
+ 
++	if (!access_ok(VERIFY_READ, uregs, sizeof(elf_xtregs_t)))
++		return -EFAULT;
++
+ #if XTENSA_HAVE_COPROCESSORS
+ 	/* Flush all coprocessors before we overwrite them. */
+ 	coprocessor_flush_all(ti);