[PATCH 01/11] Altix: correct ioc4 port order

[PATCH 01/11] Altix: correct ioc4 port order

[Chris Wright]

[-- Attachment #1: altix-correct-ioc4-port-order.patch --]
[-- Type: text/plain, Size: 1067 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Brent Casavant <bcasavan@sgi.com>

Currently loading the ioc4 as a module will cause the ports to be numbered
in reverse order.  This mod maintains the proper order of cards for port
numbering.

Signed-off-by: Brent Casavant <bcasavan@sgi.com>
Cc: Pat Gefre <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---

 drivers/sn/ioc4.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.16.19.orig/drivers/sn/ioc4.c
+++ linux-2.6.16.19/drivers/sn/ioc4.c
@@ -313,7 +313,7 @@ ioc4_probe(struct pci_dev *pdev, const s
 	idd->idd_serial_data = NULL;
 	pci_set_drvdata(idd->idd_pdev, idd);
 	down_write(&ioc4_devices_rwsem);
-	list_add(&idd->idd_list, &ioc4_devices);
+	list_add_tail(&idd->idd_list, &ioc4_devices);
 	up_write(&ioc4_devices_rwsem);
 
 	/* Add this IOC4 to all submodules */

--

[PATCH 02/11] Altix: correct ioc3 port order

[Chris Wright]

[-- Attachment #1: altix-correct-ioc3-port-order.patch --]
[-- Type: text/plain, Size: 1002 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Pat Gefre <pfg@sgi.com>

Currently loading the ioc3 as a module will cause the ports to be numbered
in reverse order.  This mod maintains the proper order of cards for port
numbering.

Signed-off-by: Patrick Gefre <pfg@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---

 drivers/sn/ioc3.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-2.6.16.19.orig/drivers/sn/ioc3.c
+++ linux-2.6.16.19/drivers/sn/ioc3.c
@@ -677,7 +677,7 @@ static int ioc3_probe(struct pci_dev *pd
 	/* Track PCI-device specific data */
 	pci_set_drvdata(pdev, idd);
 	down_write(&ioc3_devices_rwsem);
-	list_add(&idd->list, &ioc3_devices);
+	list_add_tail(&idd->list, &ioc3_devices);
 	idd->id = ioc3_counter++;
 	up_write(&ioc3_devices_rwsem);
 

--

[PATCH 03/11] Cpuset: might sleep checking zones allowed fix

[Chris Wright]

[-- Attachment #1: cpuset-might-sleep-checking-zones-allowed-fix.patch --]
[-- Type: text/plain, Size: 2334 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Paul Jackson <pj@sgi.com>

Fix an infrequently encountered 'sleeping function called
from invalid context' in the cpuset hooks in __alloc_pages.
Could sleep while interrupts disabled.

The routine cpuset_zone_allowed() is called by code in
mm/page_alloc.c __alloc_pages() to determine if a zone is
allowed in the current tasks cpuset.  This routine can sleep,
for certain GFP_KERNEL allocations, if the zone is on a memory
node not allowed in the current cpuset, but might be allowed
in a parent cpuset.

But we can't sleep in __alloc_pages() if in interrupt, nor
if called for a GFP_ATOMIC request (__GFP_WAIT not set in
gfp_flags).

The rule was intended to be:
  Don't call cpuset_zone_allowed() if you can't sleep, unless you
  pass in the __GFP_HARDWALL flag set in gfp_flag, which disables
  the code that might scan up ancestor cpusets and sleep.

This rule was being violated due to a bogus change made (by myself,
pj) to __alloc_pages() as part of the November 2005 effort to
cleanup its logic.

The bogus change can be seen at:
  http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-11/4691.html
  [PATCH 01/05] mm fix __alloc_pages cpuset ALLOC_* flags

This was first noticed on a tight memory system, in code that
was disabling interrupts and doing allocation requests with
__GFP_WAIT not set, which resulted in __might_sleep() writing
complaints to the log "Debug: sleeping function called ...",
when the code in cpuset_zone_allowed() tried to take the
callback_sem cpuset semaphore.

Special thanks to Dave Chinner, for figuring this out,
and a tip of the hat to Nick Piggin who warned me of this
back in Nov 2005, before I was ready to listen.

Signed-off-by: Paul Jackson <pj@sgi.com>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 mm/page_alloc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.16.19.orig/mm/page_alloc.c
+++ linux-2.6.16.19/mm/page_alloc.c
@@ -949,7 +949,8 @@ restart:
 		alloc_flags |= ALLOC_HARDER;
 	if (gfp_mask & __GFP_HIGH)
 		alloc_flags |= ALLOC_HIGH;
-	alloc_flags |= ALLOC_CPUSET;
+	if (wait)
+		alloc_flags |= ALLOC_CPUSET;
 
 	/*
 	 * Go through the zonelist again. Let __GFP_HIGH and allocations

--

[PATCH 04/11] PowerMac: force only suspend-to-disk to be valid

[Chris Wright]

[-- Attachment #1: powermac-force-only-suspend-to-disk-to-be-valid.patch --]
[-- Type: text/plain, Size: 1575 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Johannes Berg <johannes@sipsolutions.net>

For a very long time, echoing 'standby' or 'mem' into /sys/power/state has
killed the machine on powerpc.  This patch fixes that.

This patch adds the .valid callback to pm_ops on PowerMac so that only the
suspend to disk state can be entered.  Note that just returning 0 would
suffice since the upper layers don't pass PM_SUSPEND_DISK down, but we
handle it there regardless just in case that changes.

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 arch/powerpc/platforms/powermac/setup.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- linux-2.6.16.19.orig/arch/powerpc/platforms/powermac/setup.c
+++ linux-2.6.16.19/arch/powerpc/platforms/powermac/setup.c
@@ -456,11 +456,23 @@ static int pmac_pm_finish(suspend_state_
 	return 0;
 }
 
+static int pmac_pm_valid(suspend_state_t state)
+{
+	switch (state) {
+	case PM_SUSPEND_DISK:
+		return 1;
+	/* can't do any other states via generic mechanism yet */
+	default:
+		return 0;
+	}
+}
+
 static struct pm_ops pmac_pm_ops = {
 	.pm_disk_mode	= PM_DISK_SHUTDOWN,
 	.prepare	= pmac_pm_prepare,
 	.enter		= pmac_pm_enter,
 	.finish		= pmac_pm_finish,
+	.valid		= pmac_pm_valid,
 };
 
 #endif /* CONFIG_SOFTWARE_SUSPEND */

--

[PATCH 05/11] Input: psmouse - fix new device detection logic

[Chris Wright]

[-- Attachment #1: input-psmouse-fix-new-device-detection-logic.patch --]
[-- Type: text/plain, Size: 1005 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Dmitry Torokhov <dtor_core@ameritech.net>

Reported to fix http://bugs.gentoo.org/130846

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Cc: Daniel Drake <dsd@gentoo.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 drivers/input/mouse/psmouse-base.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- linux-2.6.16.19.orig/drivers/input/mouse/psmouse-base.c
+++ linux-2.6.16.19/drivers/input/mouse/psmouse-base.c
@@ -300,8 +300,10 @@ static irqreturn_t psmouse_interrupt(str
  * Check if this is a new device announcement (0xAA 0x00)
  */
 	if (unlikely(psmouse->packet[0] == PSMOUSE_RET_BAT && psmouse->pktcnt <= 2)) {
-		if (psmouse->pktcnt == 1)
+		if (psmouse->pktcnt == 1) {
+			psmouse->last = jiffies;
 			goto out;
+		}
 
 		if (psmouse->packet[1] == PSMOUSE_RET_ID) {
 			__psmouse_set_state(psmouse, PSMOUSE_IGNORE);

--

[PATCH 06/11] ohci1394, sbp2: fix "scsi_add_device failed" with PL-3507 based devices

[Chris Wright]

[-- Attachment #1: ohci1394-sbp2-fix-scsi_add_device-failed-with-pl-3507-based-devices.patch --]
[-- Type: text/plain, Size: 2485 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

Re-enable posted writes for status FIFO.
Besides bringing back a very minor bandwidth tweak from Linux 2.6.15.x
and older, this also fixes an interoperability regression since 2.6.16:
http://bugzilla.kernel.org/show_bug.cgi?id=6356
(sbp2: scsi_add_device failed. IEEE1394 HD is not working anymore.)

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Tested-by: Vanei Heidemann <linux@javanei.com.br>
Tested-by: Martin Putzlocher <mputzi@gmx.de> (chip type unconfirmed)
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 drivers/ieee1394/ohci1394.c |    2 +-
 drivers/ieee1394/sbp2.c     |    9 +++++++--
 2 files changed, 8 insertions(+), 3 deletions(-)

--- linux-2.6.16.19.orig/drivers/ieee1394/ohci1394.c
+++ linux-2.6.16.19/drivers/ieee1394/ohci1394.c
@@ -2525,7 +2525,7 @@ static irqreturn_t ohci_irq_handler(int 
 			if (phys_dma) {
 				reg_write(ohci,OHCI1394_PhyReqFilterHiSet, 0xffffffff);
 				reg_write(ohci,OHCI1394_PhyReqFilterLoSet, 0xffffffff);
-				reg_write(ohci,OHCI1394_PhyUpperBound, 0xffff0000);
+				reg_write(ohci,OHCI1394_PhyUpperBound, 0x01000000);
 			} else {
 				reg_write(ohci,OHCI1394_PhyReqFilterHiSet, 0x00000000);
 				reg_write(ohci,OHCI1394_PhyReqFilterLoSet, 0x00000000);
--- linux-2.6.16.19.orig/drivers/ieee1394/sbp2.c
+++ linux-2.6.16.19/drivers/ieee1394/sbp2.c
@@ -754,11 +754,16 @@ static struct scsi_id_instance_data *sbp
 
 	/* Register the status FIFO address range. We could use the same FIFO
 	 * for targets at different nodes. However we need different FIFOs per
-	 * target in order to support multi-unit devices. */
+	 * target in order to support multi-unit devices.
+	 * The FIFO is located out of the local host controller's physical range
+	 * but, if possible, within the posted write area. Status writes will
+	 * then be performed as unified transactions. This slightly reduces
+	 * bandwidth usage, and some Prolific based devices seem to require it.
+	 */
 	scsi_id->status_fifo_addr = hpsb_allocate_and_register_addrspace(
 			&sbp2_highlevel, ud->ne->host, &sbp2_ops,
 			sizeof(struct sbp2_status_block), sizeof(quadlet_t),
-			~0ULL, ~0ULL);
+			0x010000000000ULL, CSR1212_ALL_SPACE_END);
 	if (!scsi_id->status_fifo_addr) {
 		SBP2_ERR("failed to allocate status FIFO address range");
 		goto failed_alloc;

--

[PATCH 07/11] the latest consensus libata resume fix

[Chris Wright]

[-- Attachment #1: the-latest-consensus-libata-resume-fix.patch --]
[-- Type: text/plain, Size: 1069 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Mark Lord <liml@rtr.ca>

Okay, just to sum things up.

This forces libata to wait for up to 2 seconds for BUSY|DRQ to clear
on resume before continuing.

[jgarzik adds...]  During testing we never saw DRQ asserted, but
nonetheless (a) this works and (b) testing for DRQ won't hurt.

Signed-off-by:  Mark Lord <liml@rtr.ca>
Acked-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---

 drivers/scsi/libata-core.c |    1 +
 1 file changed, 1 insertion(+)

--- linux-2.6.16.19.orig/drivers/scsi/libata-core.c
+++ linux-2.6.16.19/drivers/scsi/libata-core.c
@@ -4293,6 +4293,7 @@ static int ata_start_drive(struct ata_po
 int ata_device_resume(struct ata_port *ap, struct ata_device *dev)
 {
 	if (ap->flags & ATA_FLAG_SUSPENDED) {
+		ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 200000);
 		ap->flags &= ~ATA_FLAG_SUSPENDED;
 		ata_set_mode(ap);
 	}

--

[PATCH 08/11] ipw2200: Filter unsupported channels out in ad-hoc mode

[Chris Wright]

[-- Attachment #1: ipw2200-Filter-unsupported-channels-out-in-ad-hoc-mode.patch --]
[-- Type: text/plain, Size: 1787 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Zhu Yi <yi.zhu@intel.com>

Currently iwlist ethX freq[uency]/channel lists all the channels the card
supported for the current region, which includes some channels can only
be used in infrastructure mode. This patch filters these channels out if
the card is currently in ad-hoc mode.

Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---

 drivers/net/wireless/ipw2200.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

--- linux-2.6.16.19.orig/drivers/net/wireless/ipw2200.c
+++ linux-2.6.16.19/drivers/net/wireless/ipw2200.c
@@ -8391,20 +8391,28 @@ static int ipw_wx_get_range(struct net_d
 
 	i = 0;
 	if (priv->ieee->mode & (IEEE_B | IEEE_G)) {
-		for (j = 0; j < geo->bg_channels && i < IW_MAX_FREQUENCIES;
-		     i++, j++) {
+		for (j = 0; j < geo->bg_channels && i < IW_MAX_FREQUENCIES; j++) {
+			if ((priv->ieee->iw_mode == IW_MODE_ADHOC) &&
+			    (geo->bg[j].flags & IEEE80211_CH_PASSIVE_ONLY))
+				continue;
+
 			range->freq[i].i = geo->bg[j].channel;
 			range->freq[i].m = geo->bg[j].freq * 100000;
 			range->freq[i].e = 1;
+			i++;
 		}
 	}
 
 	if (priv->ieee->mode & IEEE_A) {
-		for (j = 0; j < geo->a_channels && i < IW_MAX_FREQUENCIES;
-		     i++, j++) {
+		for (j = 0; j < geo->a_channels && i < IW_MAX_FREQUENCIES; j++) {
+			if ((priv->ieee->iw_mode == IW_MODE_ADHOC) &&
+			    (geo->a[j].flags & IEEE80211_CH_PASSIVE_ONLY))
+				continue;
+
 			range->freq[i].i = geo->a[j].channel;
 			range->freq[i].m = geo->a[j].freq * 100000;
 			range->freq[i].e = 1;
+			i++;
 		}
 	}
 

--

[PATCH 09/11] x86_64: x86_64 add crashdump trigger points

[Chris Wright]

[-- Attachment #1: x86_64-add-crashdump-trigger-points.patch --]
[-- Type: text/plain, Size: 1766 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Vivek Goyal <vgoyal@in.ibm.com>

o Start booting into the capture kernel after an Oops if system is in a
  unrecoverable state. System will boot into the capture kernel, if one is
  pre-loaded by the user, and capture the kernel core dump.

o One of the following conditions should be true to trigger the booting of
  capture kernel.
        - panic_on_oops is set.
        - pid of current thread is 0
        - pid of current thread is 1
        - Oops happened inside interrupt context.

Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>

---
 arch/x86_64/kernel/traps.c |    5 +++++
 1 file changed, 5 insertions(+)

--- linux-2.6.16.19.orig/arch/x86_64/kernel/traps.c
+++ linux-2.6.16.19/arch/x86_64/kernel/traps.c
@@ -30,6 +30,7 @@
 #include <linux/moduleparam.h>
 #include <linux/nmi.h>
 #include <linux/kprobes.h>
+#include <linux/kexec.h>
 
 #include <asm/system.h>
 #include <asm/uaccess.h>
@@ -434,6 +435,8 @@ void __kprobes __die(const char * str, s
 	printk(KERN_ALERT "RIP ");
 	printk_address(regs->rip); 
 	printk(" RSP <%016lx>\n", regs->rsp); 
+	if (kexec_should_crash(current))
+		crash_kexec(regs);
 }
 
 void die(const char * str, struct pt_regs * regs, long err)
@@ -456,6 +459,8 @@ void __kprobes die_nmi(char *str, struct
 	 */
 	printk(str, safe_smp_processor_id());
 	show_registers(regs);
+	if (kexec_should_crash(current))
+		crash_kexec(regs);
 	if (panic_on_timeout || panic_on_oops)
 		panic("nmi watchdog");
 	printk("console shuts up ...\n");

--

[PATCH 10/11] x86_64: Dont do syscall exit tracing twice

[Chris Wright]

[-- Attachment #1: x86_64-don-t-do-syscall-exit-tracing-twice.patch --]
[-- Type: text/plain, Size: 1074 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Andi Kleen <ak@suse.de>

This fixes a regression from the earlier DOS fix for non canonical
IRET addresses. It broke UML.

int_ret_from_syscall already does syscall exit tracing, so 
no need to do it again in the caller.

This caused problems for UML and some other special programs doing
syscall interception.

Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---
 arch/x86_64/kernel/entry.S |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

--- linux-2.6.16.19.orig/arch/x86_64/kernel/entry.S
+++ linux-2.6.16.19/arch/x86_64/kernel/entry.S
@@ -281,12 +281,7 @@ tracesys:			 
 	ja  1f
 	movq %r10,%rcx	/* fixup for C */
 	call *sys_call_table(,%rax,8)
-	movq %rax,RAX-ARGOFFSET(%rsp)
-1:	SAVE_REST
-	movq %rsp,%rdi
-	call syscall_trace_leave
-	RESTORE_TOP_OF_STACK %rbx
-	RESTORE_REST
+1:	movq %rax,RAX-ARGOFFSET(%rsp)
 	/* Use IRET because user could have changed frame */
 	jmp int_ret_from_sys_call
 	CFI_ENDPROC

--

[PATCH 11/11] sbp2: backport read_capacity workaround for iPod

[Chris Wright]

[-- Attachment #1: sbp2-backport-read_capacity-workaround-for-ipod.patch --]
[-- Type: text/plain, Size: 1921 bytes --]

-stable review patch.  If anyone has any objections, please let us know.
------------------

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

There is a firmware bug in several Apple iPods which prevents access to
these iPods under certain conditions. The disk size reported by the iPod
is one sector too big. Once access to the end of the disk is attempted,
the iPod becomes inaccessible. This problem has been known for USB iPods
for some time and has recently been discovered to exist with
FireWire/USB combo iPods too.

This patch is derived from the fix in Linux 2.6.17, commit
e9a1c52c7b19d10342226c12f170d7ab644427e2, to be applicable to 2.6.16.x
without prerequisite patches. It hard-wires a workaround for three known
affected model numbers (those of 4th generation iPod, iPod Photo, iPod
mini).

Note: This patch lacks Linux 2.6.17's ability to enable and disable the
workaround via a module parameter.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
---

 drivers/ieee1394/sbp2.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

--- linux-2.6.16.19.orig/drivers/ieee1394/sbp2.c
+++ linux-2.6.16.19/drivers/ieee1394/sbp2.c
@@ -2491,9 +2491,20 @@ static int sbp2scsi_slave_alloc(struct s
 
 static int sbp2scsi_slave_configure(struct scsi_device *sdev)
 {
+	struct scsi_id_instance_data *scsi_id =
+		(struct scsi_id_instance_data *)sdev->host->hostdata[0];
+
 	blk_queue_dma_alignment(sdev->request_queue, (512 - 1));
 	sdev->use_10_for_rw = 1;
 	sdev->use_10_for_ms = 1;
+
+	if ((scsi_id->sbp2_firmware_revision & 0xffff00) == 0x0a2700 &&
+	    (scsi_id->ud->model_id == 0x000021 /* gen.4 iPod */ ||
+	     scsi_id->ud->model_id == 0x000023 /* iPod mini  */ ||
+	     scsi_id->ud->model_id == 0x00007e /* iPod Photo */ )) {
+		SBP2_INFO("enabling iPod workaround: decrement disk capacity");
+		sdev->fix_capacity = 1;
+	}
 	return 0;
 }
 

--

[PATCH 00/11] -stable review

[Chris Wright]

This is the start of the stable review cycle for the 2.6.16.20 release.
There are 11 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let us know.  If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the
Cc: line.  If you wish to be a reviewer, please email stable@kernel.org
to add your name to the list.  If you want to be off the reviewer list,
also email us.

Responses should be made by Sun, June 4, 19:45 UTC.
Anything received after that time, might be too late.

thanks,

the -stable release team
--

Re: [PATCH 07/11] the latest consensus libata resume fix

[Jens Axboe]

On Fri, Jun 02 2006, Chris Wright wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> ------------------
> 
> From: Mark Lord <liml@rtr.ca>
> 
> Okay, just to sum things up.
> 
> This forces libata to wait for up to 2 seconds for BUSY|DRQ to clear
> on resume before continuing.
> 
> [jgarzik adds...]  During testing we never saw DRQ asserted, but
> nonetheless (a) this works and (b) testing for DRQ won't hurt.
> 
> Signed-off-by:  Mark Lord <liml@rtr.ca>
> Acked-by: Jens Axboe <axboe@suse.de>
> Signed-off-by: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> ---
> 
>  drivers/scsi/libata-core.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> --- linux-2.6.16.19.orig/drivers/scsi/libata-core.c
> +++ linux-2.6.16.19/drivers/scsi/libata-core.c
> @@ -4293,6 +4293,7 @@ static int ata_start_drive(struct ata_po
>  int ata_device_resume(struct ata_port *ap, struct ata_device *dev)
>  {
>  	if (ap->flags & ATA_FLAG_SUSPENDED) {
> +		ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 200000);
>  		ap->flags &= ~ATA_FLAG_SUSPENDED;
>  		ata_set_mode(ap);
>  	}

I'm not against the patch as such, but last I checked 2.6.16 actually
worked ok. The timer fixes in 2.6.17-rc is what apparently got the
resume breaking.

So unless there's a bug report on 2.6.16.x for this, then it's a little
against the -stable rules to add it.

-- 
Jens Axboe

Re: [PATCH 07/11] the latest consensus libata resume fix

[Greg KH]

On Fri, Jun 02, 2006 at 09:50:46PM +0200, Jens Axboe wrote:
> On Fri, Jun 02 2006, Chris Wright wrote:
> > -stable review patch.  If anyone has any objections, please let us know.
> > ------------------
> > 
> > From: Mark Lord <liml@rtr.ca>
> > 
> > Okay, just to sum things up.
> > 
> > This forces libata to wait for up to 2 seconds for BUSY|DRQ to clear
> > on resume before continuing.
> > 
> > [jgarzik adds...]  During testing we never saw DRQ asserted, but
> > nonetheless (a) this works and (b) testing for DRQ won't hurt.
> > 
> > Signed-off-by:  Mark Lord <liml@rtr.ca>
> > Acked-by: Jens Axboe <axboe@suse.de>
> > Signed-off-by: Jeff Garzik <jeff@garzik.org>
> > Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > ---
> > 
> >  drivers/scsi/libata-core.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > --- linux-2.6.16.19.orig/drivers/scsi/libata-core.c
> > +++ linux-2.6.16.19/drivers/scsi/libata-core.c
> > @@ -4293,6 +4293,7 @@ static int ata_start_drive(struct ata_po
> >  int ata_device_resume(struct ata_port *ap, struct ata_device *dev)
> >  {
> >  	if (ap->flags & ATA_FLAG_SUSPENDED) {
> > +		ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 200000);
> >  		ap->flags &= ~ATA_FLAG_SUSPENDED;
> >  		ata_set_mode(ap);
> >  	}
> 
> I'm not against the patch as such, but last I checked 2.6.16 actually
> worked ok. The timer fixes in 2.6.17-rc is what apparently got the
> resume breaking.
> 
> So unless there's a bug report on 2.6.16.x for this, then it's a little
> against the -stable rules to add it.

Marcel (now on the To:) was the one reporting this.  Marcel, is this
really necessary for 2.6.16.x?

thanks,

greg k-h

Re: [stable] Re: [PATCH 07/11] the latest consensus libata resume fix

[Chris Wright]

* Jens Axboe (axboe@suse.de) wrote:
> I'm not against the patch as such, but last I checked 2.6.16 actually
> worked ok. The timer fixes in 2.6.17-rc is what apparently got the
> resume breaking.
> 
> So unless there's a bug report on 2.6.16.x for this, then it's a little
> against the -stable rules to add it.

We did get a report that this fix was needed, but I'm not 100% which
kernel base the report was against.  Marcel, were you testing on a 2.6.16
base, or 2.6.17-rc?

thanks,
-chris

Re: [PATCH 07/11] the latest consensus libata resume fix

[Marcel Holtmann]

Hi Jens,

> > -stable review patch.  If anyone has any objections, please let us know.
> > ------------------
> > 
> > From: Mark Lord <liml@rtr.ca>
> > 
> > Okay, just to sum things up.
> > 
> > This forces libata to wait for up to 2 seconds for BUSY|DRQ to clear
> > on resume before continuing.
> > 
> > [jgarzik adds...]  During testing we never saw DRQ asserted, but
> > nonetheless (a) this works and (b) testing for DRQ won't hurt.
> > 
> > Signed-off-by:  Mark Lord <liml@rtr.ca>
> > Acked-by: Jens Axboe <axboe@suse.de>
> > Signed-off-by: Jeff Garzik <jeff@garzik.org>
> > Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > ---
> > 
> >  drivers/scsi/libata-core.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > --- linux-2.6.16.19.orig/drivers/scsi/libata-core.c
> > +++ linux-2.6.16.19/drivers/scsi/libata-core.c
> > @@ -4293,6 +4293,7 @@ static int ata_start_drive(struct ata_po
> >  int ata_device_resume(struct ata_port *ap, struct ata_device *dev)
> >  {
> >  	if (ap->flags & ATA_FLAG_SUSPENDED) {
> > +		ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 200000);
> >  		ap->flags &= ~ATA_FLAG_SUSPENDED;
> >  		ata_set_mode(ap);
> >  	}
> 
> I'm not against the patch as such, but last I checked 2.6.16 actually
> worked ok. The timer fixes in 2.6.17-rc is what apparently got the
> resume breaking.
> 
> So unless there's a bug report on 2.6.16.x for this, then it's a little
> against the -stable rules to add it.

I had problems with resume on my IBM X41 since I got it (something
around 2.6.15) and only this patch made it work again.

Because of the SDHCI stuff I always used the latest kernel and thus I
wasn't sure if there actually was a problem or not. So I tested a plain
2.6.16 with and without this patch. The plain 2.6.16 doesn't resume on
my IBM X41 laptop. If I apply this patch, the resume works perfect.

Regards

Marcel

Re: [PATCH 07/11] the latest consensus libata resume fix

[Jens Axboe]

On Sat, Jun 03 2006, Marcel Holtmann wrote:
> Hi Jens,
> 
> > > -stable review patch.  If anyone has any objections, please let us know.
> > > ------------------
> > > 
> > > From: Mark Lord <liml@rtr.ca>
> > > 
> > > Okay, just to sum things up.
> > > 
> > > This forces libata to wait for up to 2 seconds for BUSY|DRQ to clear
> > > on resume before continuing.
> > > 
> > > [jgarzik adds...]  During testing we never saw DRQ asserted, but
> > > nonetheless (a) this works and (b) testing for DRQ won't hurt.
> > > 
> > > Signed-off-by:  Mark Lord <liml@rtr.ca>
> > > Acked-by: Jens Axboe <axboe@suse.de>
> > > Signed-off-by: Jeff Garzik <jeff@garzik.org>
> > > Signed-off-by: Chris Wright <chrisw@sous-sol.org>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > > ---
> > > 
> > >  drivers/scsi/libata-core.c |    1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > --- linux-2.6.16.19.orig/drivers/scsi/libata-core.c
> > > +++ linux-2.6.16.19/drivers/scsi/libata-core.c
> > > @@ -4293,6 +4293,7 @@ static int ata_start_drive(struct ata_po
> > >  int ata_device_resume(struct ata_port *ap, struct ata_device *dev)
> > >  {
> > >  	if (ap->flags & ATA_FLAG_SUSPENDED) {
> > > +		ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 200000);
> > >  		ap->flags &= ~ATA_FLAG_SUSPENDED;
> > >  		ata_set_mode(ap);
> > >  	}
> > 
> > I'm not against the patch as such, but last I checked 2.6.16 actually
> > worked ok. The timer fixes in 2.6.17-rc is what apparently got the
> > resume breaking.
> > 
> > So unless there's a bug report on 2.6.16.x for this, then it's a little
> > against the -stable rules to add it.
> 
> I had problems with resume on my IBM X41 since I got it (something
> around 2.6.15) and only this patch made it work again.
> 
> Because of the SDHCI stuff I always used the latest kernel and thus I
> wasn't sure if there actually was a problem or not. So I tested a plain
> 2.6.16 with and without this patch. The plain 2.6.16 doesn't resume on
> my IBM X41 laptop. If I apply this patch, the resume works perfect.

Ok, no problem from my end then.

-- 
Jens Axboe

Re: [PATCH 07/11] the latest consensus libata resume fix

[Chris Wright]

* Jens Axboe (axboe@suse.de) wrote:
> On Sat, Jun 03 2006, Marcel Holtmann wrote:
> > I had problems with resume on my IBM X41 since I got it (something
> > around 2.6.15) and only this patch made it work again.
> > 
> > Because of the SDHCI stuff I always used the latest kernel and thus I
> > wasn't sure if there actually was a problem or not. So I tested a plain
> > 2.6.16 with and without this patch. The plain 2.6.16 doesn't resume on
> > my IBM X41 laptop. If I apply this patch, the resume works perfect.
> 
> Ok, no problem from my end then.

Thanks guys.
-chris