rpms/kernel/F-7 linux-2.6-firewire-git-update.patch, NONE, 1.1 kernel-2.6.spec, 1.3424, 1.3425

Jarod Wilson (jwilson) fedora-extras-commits at redhat.com
Wed Feb 6 00:04:35 UTC 2008 

Author: jwilson

Update of /cvs/pkgs/rpms/kernel/F-7
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv10683

Modified Files:
	kernel-2.6.spec 
Added Files:
	linux-2.6-firewire-git-update.patch 
Log Message:
* Tue Feb 05 2008 Jarod Wilson <jwilson at redhat.com> 2.6.23.14-74
- FireWire updates from linux1394-git tree, should resolve a
  bunch of FireWire disk issues for people


linux-2.6-firewire-git-update.patch:

--- NEW FILE linux-2.6-firewire-git-update.patch ---
IEEE 1394 updates for Linux 2.6.23 (v629 2008-02-03)

 drivers/firewire/fw-cdev.c               |   68 +
 drivers/firewire/fw-device.c             |   86 +-
 drivers/firewire/fw-device.h             |   19 
 drivers/firewire/fw-ohci.c               |  528 +++++++++---
 drivers/firewire/fw-ohci.h               |    2 
 drivers/firewire/fw-sbp2.c               |  945 +++++++++++++++--------
 drivers/firewire/fw-topology.c           |   16 
 drivers/firewire/fw-topology.h           |    6 
 drivers/firewire/fw-transaction.c        |   18 
 drivers/ieee1394/csr1212.c               |   57 -
 drivers/ieee1394/csr1212.h               |    6 
 drivers/ieee1394/dma.c                   |   37 
 drivers/ieee1394/eth1394.c               |   16 
 drivers/ieee1394/ieee1394_core.c         |    2 
 drivers/ieee1394/ieee1394_transactions.c |   70 -
 drivers/ieee1394/nodemgr.c               |   22 
 drivers/ieee1394/ohci1394.c              |   12 
 drivers/ieee1394/pcilynx.c               |   29 
 drivers/ieee1394/raw1394.c               |    4 
 drivers/ieee1394/sbp2.c                  |   53 +
 drivers/ieee1394/sbp2.h                  |    3 
 include/linux/firewire-cdev.h            |   15 
 22 files changed, 1311 insertions(+), 703 deletions(-)

========================================================================
Date: Sun, 3 Feb 2008 23:13:13 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: firewire: fw-sbp2: fix I/O errors during reconnect

While fw-sbp2 takes the necessary time to reconnect to a logical unit
after bus reset, the SCSI core keeps sending new commands.  They are all
immediately completed with host busy status, and application clients or
filesystems will break quickly.  The SCSI device might even be taken
offline:  http://bugzilla.kernel.org/show_bug.cgi?id=9734

The only remedy seems to be to block the SCSI device until reconnect.
Alas the SCSI core has no useful API to block only one logical unit i.e.
the scsi_device, therefore we block the entire Scsi_Host.  This
currently corresponds to an SBP-2 target.  In case of targets with
multiple logical units, we need to satisfy the dependencies between
logical units by carefully tracking the blocking state of the target and
its units.  We block all logical units of a target as soon as one of
them needs to be blocked, and keep them blocked until all of them are
ready to be unblocked.

Furthermore, as the history of the old sbp2 driver has shown, the
scsi_block_requests() API is a minefield with high potential of
deadlocks.  We therefore take extra measures to keep logical units
unblocked during __scsi_add_device() and during shutdown.

Signed-off-by: Stefan Richter <stefanr at s5r6.in-berlin.de>
---
 drivers/firewire/fw-sbp2.c |   71 +++++++++++++++++++++++++++++++++++--
 1 file changed, 69 insertions(+), 2 deletions(-)

========================================================================
Date: Sun, 3 Feb 2008 23:12:17 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: firewire: fw-sbp2: sort includes

Signed-off-by: Stefan Richter <stefanr at s5r6.in-berlin.de>
---
 drivers/firewire/fw-sbp2.c |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

========================================================================
Date: Sun, 3 Feb 2008 23:11:39 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: firewire: fw-sbp2: logout and login after failed reconnect

If fw-sbp2 was too late with requesting the reconnect, the target would
reject this.  In this case, log out before attempting the reconnect.
Else several firmwares will deny the re-login because they somehow
didn't invalidate the old login.

Also, don't retry reconnects in this situation.  The retries won't
succeed either.

These changes improve chances for successful re-login and shorten the
period during which the logical unit is inaccessible.

Signed-off-by: Stefan Richter <stefanr at s5r6.in-berlin.de>
---
 drivers/firewire/fw-sbp2.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

========================================================================
Date: Sun, 3 Feb 2008 23:10:47 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: firewire: fw-sbp2: don't add scsi_device twice

When a reconnect failed but re-login succeeded, __scsi_add_device was
called again.

Signed-off-by: Stefan Richter <stefanr at s5r6.in-berlin.de>
---
 drivers/firewire/fw-sbp2.c |    6 ++++++
 1 file changed, 6 insertions(+)

========================================================================
Date: Sun, 3 Feb 2008 23:09:50 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: firewire: fw-sbp2: log bus_id at management request failures

for easier readable logs if more than one SBP-2 device is present.

Signed-off-by: Stefan Richter <stefanr at s5r6.in-berlin.de>
---
 drivers/firewire/fw-sbp2.c |   66 ++++++++++++++++++-------------------
 1 file changed, 33 insertions(+), 33 deletions(-)

========================================================================
Date: Sun, 3 Feb 2008 23:08:58 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: firewire: fw-sbp2: wait for completion of fetch agent reset

Like the old sbp2 driver, wait for the write transaction to the
AGENT_RESET to complete before proceeding (after login, after reconnect,
or in SCSI error handling).

There is one occasion where AGENT_RESET is written to from atomic
context when getting DEAD status for a command ORB.  There we still
continue without waiting for the transaction to complete because this
is more difficult to fix...

Signed-off-by: Stefan Richter <stefanr at s5r6.in-berlin.de>
---
 drivers/firewire/fw-sbp2.c |   39 ++++++++++++++++++++++++++-----------
 1 file changed, 28 insertions(+), 11 deletions(-)

========================================================================
Date: Sun, 3 Feb 2008 23:07:44 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: ieee1394: sbp2: add INQUIRY delay workaround

Add the same workaround as found in fw-sbp2 for feature parity and
compatibility of the workarounds module parameter.

Signed-off-by: Stefan Richter <stefanr at s5r6.in-berlin.de>
---
 drivers/ieee1394/sbp2.c |   12 ++++++++++++
 drivers/ieee1394/sbp2.h |    2 ++
 2 files changed, 14 insertions(+)

========================================================================
Date: Sun, 3 Feb 2008 23:04:38 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: firewire: fw-sbp2: add INQUIRY delay workaround

Several different SBP-2 bridges accept a login early while the IDE
device is still powering up.  They are therefore unable to respond to
SCSI INQUIRY immediately, and the SCSI core has to retry the INQUIRY.
One of these retries is typically successful, and all is well.

But in case of Momobay FX-3A, the INQUIRY retries tend to fail entirely.
This can usually be avoided by waiting a little while after login before
letting the SCSI core send the INQUIRY.  The old sbp2 driver handles
this more gracefully for as yet unknown reasons (perhaps because it
waits for fetch agent resets to complete, unlike fw-sbp2 which quickly
proceeds after requesting the agent reset).  Therefore the workaround is
not as much necessary for sbp2.

Signed-off-by: Stefan Richter <stefanr at s5r6.in-berlin.de>
---
 drivers/firewire/fw-sbp2.c |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

========================================================================
Date: Sun, 3 Feb 2008 23:03:00 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: firewire: log GUID of new devices

This should help to interpret user reports.  E.g. one can look up the
vendor OUI (first three bytes of the GUID) and thus tell what is what.

Also simplifies the math in the GUID sysfs attribute.

Signed-off-by: Stefan Richter <stefanr at s5r6.in-berlin.de>
---
 drivers/firewire/fw-device.c |   28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

========================================================================
Date: Sun, 27 Jan 2008 19:14:44 +0100 (CET)
From: Stefan Richter <stefanr at s5r6.in-berlin.de>
Subject: firewire: fw-sbp2: don't retry login or reconnect after unplug

If a device is being unplugged while fw-sbp2 had a login or reconnect on
schedule, it would take about half a minute to shut the fw_unit down:

    Jan 27 18:34:54 stein firewire_sbp2: logged in to fw2.0 LUN 0000 (0 retries)
    <unplug>
    Jan 27 18:34:59 stein firewire_sbp2: sbp2_scsi_abort
    Jan 27 18:34:59 stein scsi 25:0:0:0: Device offlined - not ready after error recovery
    Jan 27 18:35:01 stein firewire_sbp2: orb reply timed out, rcode=0x11
    Jan 27 18:35:06 stein firewire_sbp2: orb reply timed out, rcode=0x11
    Jan 27 18:35:12 stein firewire_sbp2: orb reply timed out, rcode=0x11
[...4589 lines suppressed...]
 
@@ -359,12 +365,9 @@ static ssize_t
 guid_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
 	struct fw_device *device = fw_device(dev);
-	u64 guid;
-
-	guid = ((u64)device->config_rom[3] << 32) | device->config_rom[4];
 
-	return snprintf(buf, PAGE_SIZE, "0x%016llx\n",
-			(unsigned long long)guid);
+	return snprintf(buf, PAGE_SIZE, "0x%08x%08x\n",
+			device->config_rom[3], device->config_rom[4]);
 }
 
 static struct device_attribute fw_device_attributes[] = {
@@ -391,17 +394,21 @@ complete_transaction(struct fw_card *car
 	complete(&callback_data->done);
 }
 
-static int read_rom(struct fw_device *device, int index, u32 * data)
+static int
+read_rom(struct fw_device *device, int generation, int index, u32 *data)
 {
 	struct read_quadlet_callback_data callback_data;
 	struct fw_transaction t;
 	u64 offset;
 
+	/* device->node_id, accessed below, must not be older than generation */
+	smp_rmb();
+
 	init_completion(&callback_data.done);
 
 	offset = 0xfffff0000400ULL + index * 4;
 	fw_send_request(device->card, &t, TCODE_READ_QUADLET_REQUEST,
-			device->node_id, device->generation, device->max_speed,
+			device->node_id, generation, device->max_speed,
 			offset, NULL, 4, complete_transaction, &callback_data);
 
 	wait_for_completion(&callback_data.done);
@@ -411,7 +418,14 @@ static int read_rom(struct fw_device *de
 	return callback_data.rcode;
 }
 
-static int read_bus_info_block(struct fw_device *device)
+/*
+ * Read the bus info block, perform a speed probe, and read all of the rest of
+ * the config ROM.  We do all this with a cached bus generation.  If the bus
+ * generation changes under us, read_bus_info_block will fail and get retried.
+ * It's better to start all over in this case because the node from which we
+ * are reading the ROM may have changed the ROM during the reset.
+ */
+static int read_bus_info_block(struct fw_device *device, int generation)
 {
 	static u32 rom[256];
 	u32 stack[16], sp, key;
@@ -421,7 +435,7 @@ static int read_bus_info_block(struct fw
 
 	/* First read the bus info block. */
 	for (i = 0; i < 5; i++) {
-		if (read_rom(device, i, &rom[i]) != RCODE_COMPLETE)
+		if (read_rom(device, generation, i, &rom[i]) != RCODE_COMPLETE)
 			return -1;
 		/*
 		 * As per IEEE1212 7.2, during power-up, devices can
@@ -456,7 +470,8 @@ static int read_bus_info_block(struct fw
 			device->max_speed = device->card->link_speed;
 
 		while (device->max_speed > SCODE_100) {
-			if (read_rom(device, 0, &dummy) == RCODE_COMPLETE)
+			if (read_rom(device, generation, 0, &dummy) ==
+			    RCODE_COMPLETE)
 				break;
 			device->max_speed--;
 		}
@@ -489,7 +504,7 @@ static int read_bus_info_block(struct fw
 			return -1;
 
 		/* Read header quadlet for the block to get the length. */
-		if (read_rom(device, i, &rom[i]) != RCODE_COMPLETE)
+		if (read_rom(device, generation, i, &rom[i]) != RCODE_COMPLETE)
 			return -1;
 		end = i + (rom[i] >> 16) + 1;
 		i++;
@@ -508,7 +523,8 @@ static int read_bus_info_block(struct fw
 		 * it references another block, and push it in that case.
 		 */
 		while (i < end) {
-			if (read_rom(device, i, &rom[i]) != RCODE_COMPLETE)
+			if (read_rom(device, generation, i, &rom[i]) !=
+			    RCODE_COMPLETE)
 				return -1;
 			if ((key >> 30) == 3 && (rom[i] >> 30) > 1 &&
 			    sp < ARRAY_SIZE(stack))
@@ -598,12 +614,14 @@ static DECLARE_RWSEM(idr_rwsem);
 static DEFINE_IDR(fw_device_idr);
 int fw_cdev_major;
 
-struct fw_device *fw_device_from_devt(dev_t devt)
+struct fw_device *fw_device_get_by_devt(dev_t devt)
 {
 	struct fw_device *device;
 
 	down_read(&idr_rwsem);
 	device = idr_find(&fw_device_idr, MINOR(devt));
+	if (device)
+		fw_device_get(device);
 	up_read(&idr_rwsem);
 
 	return device;
@@ -615,13 +633,14 @@ static void fw_device_shutdown(struct wo
 		container_of(work, struct fw_device, work.work);
 	int minor = MINOR(device->device.devt);
 
-	down_write(&idr_rwsem);
-	idr_remove(&fw_device_idr, minor);
-	up_write(&idr_rwsem);
-
 	fw_device_cdev_remove(device);
 	device_for_each_child(&device->device, NULL, shutdown_unit);
 	device_unregister(&device->device);
+
+	down_write(&idr_rwsem);
+	idr_remove(&fw_device_idr, minor);
+	up_write(&idr_rwsem);
+	fw_device_put(device);
 }
 
 static struct device_type fw_device_type = {
@@ -655,7 +674,7 @@ static void fw_device_init(struct work_s
 	 * device.
 	 */
 
-	if (read_bus_info_block(device) < 0) {
+	if (read_bus_info_block(device, device->generation) < 0) {
 		if (device->config_rom_retries < MAX_RETRIES) {
 			device->config_rom_retries++;
 			schedule_delayed_work(&device->work, RETRY_DELAY);
@@ -670,10 +689,13 @@ static void fw_device_init(struct work_s
 	}
 
 	err = -ENOMEM;
+
+	fw_device_get(device);
 	down_write(&idr_rwsem);
 	if (idr_pre_get(&fw_device_idr, GFP_KERNEL))
 		err = idr_get_new(&fw_device_idr, device, &minor);
 	up_write(&idr_rwsem);
+
 	if (err < 0)
 		goto error;
 
@@ -705,13 +727,22 @@ static void fw_device_init(struct work_s
 	 */
 	if (atomic_cmpxchg(&device->state,
 		    FW_DEVICE_INITIALIZING,
-		    FW_DEVICE_RUNNING) == FW_DEVICE_SHUTDOWN)
+		    FW_DEVICE_RUNNING) == FW_DEVICE_SHUTDOWN) {
 		fw_device_shutdown(&device->work.work);
-	else
-		fw_notify("created new fw device %s "
-			  "(%d config rom retries, S%d00)\n",
-			  device->device.bus_id, device->config_rom_retries,
-			  1 << device->max_speed);
+	} else {
+		if (device->config_rom_retries)
+			fw_notify("created device %s: GUID %08x%08x, S%d00, "
+				  "%d config ROM retries\n",
+				  device->device.bus_id,
+				  device->config_rom[3], device->config_rom[4],
+				  1 << device->max_speed,
+				  device->config_rom_retries);
+		else
+			fw_notify("created device %s: GUID %08x%08x, S%d00\n",
+				  device->device.bus_id,
+				  device->config_rom[3], device->config_rom[4],
+				  1 << device->max_speed);
+	}
 
 	/*
 	 * Reschedule the IRM work if we just finished reading the
@@ -729,7 +760,9 @@ static void fw_device_init(struct work_s
 	idr_remove(&fw_device_idr, minor);
 	up_write(&idr_rwsem);
  error:
-	put_device(&device->device);
+	fw_device_put(device);		/* fw_device_idr's reference */
+
+	put_device(&device->device);	/* our reference */
 }
 
 static int update_unit(struct device *dev, void *data)
@@ -808,6 +841,7 @@ void fw_node_event(struct fw_card *card,
 
 		device = node->data;
 		device->node_id = node->node_id;
+		smp_wmb();  /* update node_id before generation */
 		device->generation = card->generation;
 		if (atomic_read(&device->state) == FW_DEVICE_RUNNING) {
 			PREPARE_DELAYED_WORK(&device->work, fw_device_update);


Index: kernel-2.6.spec
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/F-7/kernel-2.6.spec,v
retrieving revision 1.3424
retrieving revision 1.3425
diff -u -r1.3424 -r1.3425
--- kernel-2.6.spec	31 Jan 2008 00:45:58 -0000	1.3424
+++ kernel-2.6.spec	6 Feb 2008 00:03:52 -0000	1.3425
@@ -631,9 +631,9 @@
 Patch740: linux-2.6-snd-ad1988-fix-spdif-output.patch
 Patch741: linux-2.6-alsa-drivers-set-device-links.patch
 
-Patch750: linux-2.6-firewire-multi-lun.patch
-Patch751: linux-2.6-firewire-lockdep.patch
-Patch752: linux-2.6-firewire-ohci-1.0-iso-receive.patch
+# Updated firewire stack from linux1394 git
+# snap from http://me.in-berlin.de/~s5r6/linux1394/updates/2.6.23/
+Patch750: linux-2.6-firewire-git-update.patch
 
 Patch760: linux-2.6-acpi-button-send-initial-state.patch
 
@@ -1358,11 +1358,9 @@
 ApplyPatch linux-2.6-alsa-drivers-set-device-links.patch
 
 # misc
-# The multi-lun patch fixes #242254, but won't be in 2.6.23.
 #
-ApplyPatch linux-2.6-firewire-multi-lun.patch
-ApplyPatch linux-2.6-firewire-lockdep.patch
-ApplyPatch linux-2.6-firewire-ohci-1.0-iso-receive.patch
+# FireWire updates and fixes
+ApplyPatch linux-2.6-firewire-git-update.patch
 
 # USB
 #
@@ -2324,6 +2322,10 @@
 %endif
 
 %changelog
+* Tue Feb 05 2008 Jarod Wilson <jwilson at redhat.com> 2.6.23.14-74
+- FireWire updates from linux1394-git tree, should resolve a
+  bunch of FireWire disk issues for people
+
 * Wed Jan 30 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.23.14-73
 - Fix segfaults from using vdso=2 (F8#427641)
 
@@ -2390,6 +2392,7 @@
 - Another round of wireless fixes headed for 2.6.24
 - Another round of wireless updates headed for 2.6.25
 
+>>>>>>> 1.3424
 * Fri Dec 21 2007 Chuck Ebbert <cebbert at redhat.com> 2.6.23.12-54
 - USB: Use upstream version of the Huawei USB modem fix.

More information about the fedora-extras-commits mailing list