mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Manuel Lauss <mano@roarinelk.homelinux.net>
Cc: Andreas Micklei <andreas.micklei@ivistar.de>,
	Andreas Messer <andreas.messer@stud-mail.uni-wuerzburg.de>,
	linux-kernel@vger.kernel.org,
	linux1394-devel@lists.sourceforge.net
Subject: Re: [BUG] firewire: mass-storage i/o-problems
Date: Tue, 24 Jul 2007 21:56:59 +0200	[thread overview]
Message-ID: <46A6598B.5080004@s5r6.in-berlin.de> (raw)
In-Reply-To: <20070723184405.GB3736@roarinelk.homelinux.net>

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

Manuel Lauss wrote:
> Actually, copying data to the disk while playing/seeking through a moviefile
> which is also located on it is already enough. Forget the NFS thing...
> 
> Afterwards the firewire_sbp2 module has to be rmmod-ed and modprobed again
> or it will continue to throw errors even for single reads.
> 
> I hope this helps tracking it down...

I tried this and similar tests on my main PC (PCIe based) and on an
Athlon/KM266 PC, with 1394b and 1394a hardware.  Nothing happened,
except for a single "status write for unknown orb", followed by command
abort from which the disk immediately recovered.  I did many tests and
it didn't happen again.  I.e. it's probable that the supposed bug
happens here too, but very rarely.

Could you (and everyone else who has repeated I/O errors with the new
drivers, but not with the old drivers) test the attached patches, one
patch at a time?  They apply to 2.6.22.
-- 
Stefan Richter
-=====-=-=== -=== ==---
http://arcgraph.de/sr/

[-- Attachment #2: test1-firewire-fw-sbp2-default-to-128k-transfers.patch --]
[-- Type: text/plain, Size: 853 bytes --]

firewire: fw-sbp2: default to 128k transfers

because that's what the old sbp2 driver does per default, to avoid
trouble with buggy devices.

A test on a 1394b hardware RAID0 shows a drop in bandwidth by 10% by
this patch.
---
This should not be hardwired but set by blk_queue_max_sectors() in
sbp2_scsi_slave_configure().

 drivers/firewire/fw-sbp2.c |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.22/drivers/firewire/fw-sbp2.c
===================================================================
--- linux-2.6.22.orig/drivers/firewire/fw-sbp2.c
+++ linux-2.6.22/drivers/firewire/fw-sbp2.c
@@ -1171,6 +1171,7 @@ static struct scsi_host_template scsi_dr
 	.this_id		= -1,
 	.sg_tablesize		= SG_ALL,
 	.use_clustering		= ENABLE_CLUSTERING,
+	.max_sectors		= 255,
 	.cmd_per_lun		= 1,
 	.can_queue		= 1,
 	.sdev_attrs		= sbp2_scsi_sysfs_attrs,

[-- Attachment #3: test2-firewire-fw-sbp2-increase-busy-timeout.patch --]
[-- Type: text/plain, Size: 2132 bytes --]

firewire: fw-sbp2: increase BUSY_TIMEOUT

Increase BUSY_TIMEOUT.retry_limit to a maximum, like the old sbp2 driver
does.  This lets targets retry more times in single phase retry if our
host adapter is too busy to accept packets.
---
 drivers/firewire/fw-sbp2.c |   30 ++++++++++++++++++++++++++----
 1 file changed, 26 insertions(+), 4 deletions(-)

Index: linux-2.6.22/drivers/firewire/fw-sbp2.c
===================================================================
--- linux-2.6.22.orig/drivers/firewire/fw-sbp2.c
+++ linux-2.6.22/drivers/firewire/fw-sbp2.c
@@ -538,6 +538,30 @@ release_sbp2_device(struct kref *kref)
 	scsi_host_put(host);
 }
 
+static void
+complete_set_busy_timeout(struct fw_card *card, int rcode,
+			  void *payload, size_t length, void *data)
+{
+	if (rcode != RCODE_COMPLETE)
+		fw_error("set_busy_timeout: rcode %x\n", rcode);
+	complete((struct completion *)data);
+}
+
+static void sbp2_set_busy_timeout(struct sbp2_device *sd)
+{
+	struct fw_device *device = fw_device(sd->unit->device.parent);
+	struct fw_transaction t;
+	struct completion done;
+	__be32 data = cpu_to_be32(0xf);
+
+	init_completion(&done);
+	fw_send_request(device->card, &t, TCODE_WRITE_QUADLET_REQUEST,
+			sd->node_id, sd->generation, device->node->max_speed,
+			0xfffff0000210ULL, &data, sizeof(data),
+			complete_set_busy_timeout, &done);
+	wait_for_completion(&done);
+}
+
 static void sbp2_login(struct work_struct *work)
 {
 	struct sbp2_device *sd =
@@ -587,10 +611,7 @@ static void sbp2_login(struct work_struc
 	fw_notify(" - status write address:        0x%012llx\n",
 		  (unsigned long long) sd->address_handler.offset);
 
-#if 0
-	/* FIXME: The linux1394 sbp2 does this last step. */
-	sbp2_set_busy_timeout(scsi_id);
-#endif
+	sbp2_set_busy_timeout(sd);
 
 	PREPARE_DELAYED_WORK(&sd->work, sbp2_reconnect);
 	sbp2_agent_reset(unit);
@@ -752,6 +773,7 @@ static void sbp2_reconnect(struct work_s
 
 	fw_notify("reconnected to unit %s (%d retries)\n",
 		  unit->device.bus_id, sd->retries);
+	sbp2_set_busy_timeout(sd);
 	sbp2_agent_reset(unit);
 	sbp2_cancel_orbs(unit);
 	kref_put(&sd->kref, release_sbp2_device);

  reply	other threads:[~2007-07-24 19:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-22 21:32 Andreas Messer
2007-07-22 23:34 ` Stefan Richter
2007-07-23  6:37   ` Manuel Lauss
2007-07-23  7:40     ` Stefan Richter
2007-07-23  8:45       ` Manuel Lauss
2007-07-23 11:34         ` Stefan Richter
2007-07-23 18:33           ` Manuel Lauss
2007-07-23 18:44             ` Manuel Lauss
2007-07-24 19:56               ` Stefan Richter [this message]
2007-07-25  5:12                 ` Manuel Lauss
2007-07-25 16:27                   ` Stefan Richter
2007-07-23  8:07   ` Andreas Messer
2007-07-23  9:58     ` Andreas Micklei
2007-07-23 11:30     ` Stefan Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46A6598B.5080004@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=andreas.messer@stud-mail.uni-wuerzburg.de \
    --cc=andreas.micklei@ivistar.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=mano@roarinelk.homelinux.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®