rpms/kernel/F-8 kernel.spec, 1.338, 1.339 linux-2.6-firewire-git-update.patch, 1.1, 1.2

Jarod Wilson (jwilson) fedora-extras-commits at redhat.com
Tue Feb 5 23:58:39 UTC 2008 

Author: jwilson

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

Modified Files:
	kernel.spec linux-2.6-firewire-git-update.patch 
Log Message:
* Tue Feb 05 2008 Jarod Wilson <jwilson at redhat.com> 2.6.23.14-130
- Pull in additional firewire fixes from upstream. Should resolve
  most 'giving up on config rom' problems (#429598).



Index: kernel.spec
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/F-8/kernel.spec,v
retrieving revision 1.338
retrieving revision 1.339
diff -u -r1.338 -r1.339
--- kernel.spec	5 Feb 2008 23:48:28 -0000	1.338
+++ kernel.spec	5 Feb 2008 23:57:47 -0000	1.339
@@ -2068,6 +2068,10 @@
 
 
 %changelog
+* Tue Feb 05 2008 Jarod Wilson <jwilson at redhat.com> 2.6.23.14-130
+- Pull in additional firewire fixes from upstream. Should resolve
+  most 'giving up on config rom' problems (#429598).
+
 * Tue Feb 05 2008 Chuck Ebbert <cebbert at redhat.com> 2.6.23.14-128
 - ASUS Eeepc hotkey ACPI driver.
 

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

View full diff with command:
/usr/bin/cvs -f diff  -kk -u -N -r 1.1 -r 1.2 linux-2.6-firewire-git-update.patch
Index: linux-2.6-firewire-git-update.patch
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/F-8/linux-2.6-firewire-git-update.patch,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- linux-2.6-firewire-git-update.patch	11 Jan 2008 22:20:56 -0000	1.1
+++ linux-2.6-firewire-git-update.patch	5 Feb 2008 23:57:47 -0000	1.2
@@ -1,27 +1,546 @@
-IEEE 1394 updates for Linux 2.6.23 (v601 2008-01-11)
+IEEE 1394 updates for Linux 2.6.23 (v629 2008-02-03)
 
- drivers/firewire/fw-cdev.c               |   57 +
- drivers/firewire/fw-device.h             |    5 
- drivers/firewire/fw-ohci.c               |  528 ++++++++++++-----
+ 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               |  700 +++++++++++++----------
- drivers/firewire/fw-topology.c           |   10 
+ drivers/firewire/fw-sbp2.c               |  945 +++++++++++++++--------
+ drivers/firewire/fw-topology.c           |   16 
  drivers/firewire/fw-topology.h           |    6 
- drivers/firewire/fw-transaction.c        |   16 
+ drivers/firewire/fw-transaction.c        |   18 
  drivers/ieee1394/csr1212.c               |   57 -
  drivers/ieee1394/csr1212.h               |    6 
- drivers/ieee1394/dma.c                   |   37 -
+ drivers/ieee1394/dma.c                   |   37 
  drivers/ieee1394/eth1394.c               |   16 
  drivers/ieee1394/ieee1394_core.c         |    2 
- drivers/ieee1394/ieee1394_transactions.c |   70 --
+ 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                  |   41 -
- drivers/ieee1394/sbp2.h                  |    1 
+ drivers/ieee1394/sbp2.c                  |   53 +
+ drivers/ieee1394/sbp2.h                  |    3 
  include/linux/firewire-cdev.h            |   15 
- 21 files changed, 1000 insertions(+), 636 deletions(-)
+ 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.
+
[...1783 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);

More information about the fedora-extras-commits mailing list