2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-02-06 14:49:39 -05:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:39 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-03 23:12:17 +01:00
|
|
|
|
2008-08-14 21:47:21 +02:00
|
|
|
|
2009-06-04 21:09:38 +02:00
|
|
|
|
2008-02-03 23:12:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: reorganize header files
The three header files of firewire-core, i.e.
"drivers/firewire/fw-device.h",
"drivers/firewire/fw-topology.h",
"drivers/firewire/fw-transaction.h",
are replaced by
"drivers/firewire/core.h",
"include/linux/firewire.h".
The latter includes everything which a firewire high-level driver (like
firewire-sbp2) needs besides linux/firewire-constants.h, while core.h
contains the rest which is needed by firewire-core itself and by low-
level drivers (card drivers) like firewire-ohci.
High-level drivers can now also reside outside of drivers/firewire
without having to add drivers/firewire to the header file search path in
makefiles. At least the firedtv driver will be such a driver.
I also considered to spread the contents of core.h over several files,
one for each .c file where the respective implementation resides. But
it turned out that most core .c files will end up including most of the
core .h files. Also, the combined core.h isn't unreasonably big, and it
will lose more of its contents to linux/firewire.h anyway soon when more
firewire drivers are added. (IP-over-1394, firedtv, and there are plans
for one or two more.)
Furthermore, fw-ohci.h is renamed to ohci.h. The name of core.h and
ohci.h is chosen with regard to name changes of the .c files in a
follow-up change.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2009-06-05 16:26:18 +02:00
|
|
|
|
2009-06-04 21:09:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2009-06-04 21:09:38 +02:00
|
|
|
|
|
|
|
|
|
2008-02-03 23:12:17 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-06-17 23:55:41 +02:00
|
|
|
|
2006-12-27 14:49:23 -08:00
|
|
|
|
2009-06-04 21:09:38 +02:00
|
|
|
|
|
|
|
|
|
2007-07-01 13:54:57 +02:00
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
2007-08-12 12:51:18 +02:00
|
|
|
|
2009-06-04 21:09:38 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-17 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-13 09:32:20 +10:30
|
|
|
|
2007-06-17 23:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-03 23:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-11 00:35:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-03 23:04:38 +01:00
|
|
|
|
|
|
|
|
|
2008-05-11 00:35:04 +02:00
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-03 23:04:38 +01:00
|
|
|
|
2008-05-11 00:35:04 +02:00
|
|
|
|
|
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2014-03-07 10:19:57 -05:00
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2008-02-26 23:30:02 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-26 17:42:45 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2008-03-24 20:54:28 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-26 17:42:45 +01:00
|
|
|
|
2008-01-25 23:31:12 -05:00
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2009-06-06 18:35:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-24 15:26:20 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-08 00:39:31 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-03-07 01:43:31 -05:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2009-06-30 20:27:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-14 21:47:21 +02:00
|
|
|
|
2012-05-18 22:26:21 +02:00
|
|
|
|
|
|
|
|
|
2008-08-14 21:47:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-01-25 23:31:12 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2012-02-15 14:59:08 +00:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:34 -04:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-06-17 23:55:41 +02:00
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-28 20:52:02 +01:00
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
2009-06-30 20:27:59 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-01 13:55:31 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-26 17:42:45 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-11 00:35:04 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-02-03 23:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-06 19:33:50 +02:00
|
|
|
|
2008-02-03 23:04:38 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2008-05-11 00:35:04 +02:00
|
|
|
|
|
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2008-05-11 00:35:04 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2008-03-11 22:32:03 +01:00
|
|
|
|
|
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2008-03-11 22:32:03 +01:00
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
2009-01-29 00:11:59 +01:00
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
2009-01-29 00:11:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-11-22 12:38:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2010-06-20 22:50:35 +02:00
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-06 18:51:27 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-06 18:51:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2009-09-03 23:07:35 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
firewire: sbp2: fix memory leak in sbp2_cancel_orbs or at send error
When an ORB was canceled (Command ORB i.e. SCSI request timed out, or
Management ORB timed out), or there was a send error in the initial
transaction, we missed to drop one of the ORB's references and thus
leaked memory.
Background:
In total, we hold 3 references to each Operation Request Block:
- 1 during sbp2_scsi_queuecommand() or sbp2_send_management_orb()
respectively,
- 1 for the duration of the write transaction to the ORB_Pointer or
Management_Agent register of the target,
- 1 for as long as the ORB stays within the lu->orb_list, until
the ORB is unlinked from the list and the orb->callback was
executed.
The latter one of these 3 references is finished
- normally by sbp2_status_write() when the target wrote status
for a pending ORB,
- or by sbp2_cancel_orbs() in case of an ORB time-out,
- or by complete_transaction() in case of a send error.
Of them, the latter two lacked the kref_put.
Add the missing kref_put()s. Add comments to the gets and puts of
references for transaction callbacks and ORB callbacks so that it is
easier to see what is supposed to happen.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-08-16 21:58:03 +02:00
|
|
|
|
2009-09-03 23:07:35 +02:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2009-09-03 23:07:35 +02:00
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-03-15 00:04:42 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: sbp2: fix memory leak in sbp2_cancel_orbs or at send error
When an ORB was canceled (Command ORB i.e. SCSI request timed out, or
Management ORB timed out), or there was a send error in the initial
transaction, we missed to drop one of the ORB's references and thus
leaked memory.
Background:
In total, we hold 3 references to each Operation Request Block:
- 1 during sbp2_scsi_queuecommand() or sbp2_send_management_orb()
respectively,
- 1 for the duration of the write transaction to the ORB_Pointer or
Management_Agent register of the target,
- 1 for as long as the ORB stays within the lu->orb_list, until
the ORB is unlinked from the list and the orb->callback was
executed.
The latter one of these 3 references is finished
- normally by sbp2_status_write() when the target wrote status
for a pending ORB,
- or by sbp2_cancel_orbs() in case of an ORB time-out,
- or by complete_transaction() in case of a send error.
Of them, the latter two lacked the kref_put.
Add the missing kref_put()s. Add comments to the gets and puts of
references for transaction callbacks and ORB callbacks so that it is
easier to see what is supposed to happen.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-08-16 21:58:03 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
firewire: sbp2: fix memory leak in sbp2_cancel_orbs or at send error
When an ORB was canceled (Command ORB i.e. SCSI request timed out, or
Management ORB timed out), or there was a send error in the initial
transaction, we missed to drop one of the ORB's references and thus
leaked memory.
Background:
In total, we hold 3 references to each Operation Request Block:
- 1 during sbp2_scsi_queuecommand() or sbp2_send_management_orb()
respectively,
- 1 for the duration of the write transaction to the ORB_Pointer or
Management_Agent register of the target,
- 1 for as long as the ORB stays within the lu->orb_list, until
the ORB is unlinked from the list and the orb->callback was
executed.
The latter one of these 3 references is finished
- normally by sbp2_status_write() when the target wrote status
for a pending ORB,
- or by sbp2_cancel_orbs() in case of an ORB time-out,
- or by complete_transaction() in case of a send error.
Of them, the latter two lacked the kref_put.
Add the missing kref_put()s. Add comments to the gets and puts of
references for transaction callbacks and ORB callbacks so that it is
easier to see what is supposed to happen.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-08-16 21:58:03 +02:00
|
|
|
|
2007-08-25 10:40:42 +02:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
firewire: sbp2: fix memory leak in sbp2_cancel_orbs or at send error
When an ORB was canceled (Command ORB i.e. SCSI request timed out, or
Management ORB timed out), or there was a send error in the initial
transaction, we missed to drop one of the ORB's references and thus
leaked memory.
Background:
In total, we hold 3 references to each Operation Request Block:
- 1 during sbp2_scsi_queuecommand() or sbp2_send_management_orb()
respectively,
- 1 for the duration of the write transaction to the ORB_Pointer or
Management_Agent register of the target,
- 1 for as long as the ORB stays within the lu->orb_list, until
the ORB is unlinked from the list and the orb->callback was
executed.
The latter one of these 3 references is finished
- normally by sbp2_status_write() when the target wrote status
for a pending ORB,
- or by sbp2_cancel_orbs() in case of an ORB time-out,
- or by complete_transaction() in case of a send error.
Of them, the latter two lacked the kref_put.
Add the missing kref_put()s. Add comments to the gets and puts of
references for transaction callbacks and ORB callbacks so that it is
easier to see what is supposed to happen.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-08-16 21:58:03 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2011-05-01 21:06:42 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2011-05-01 21:06:42 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
firewire: sbp2: fix memory leak in sbp2_cancel_orbs or at send error
When an ORB was canceled (Command ORB i.e. SCSI request timed out, or
Management ORB timed out), or there was a send error in the initial
transaction, we missed to drop one of the ORB's references and thus
leaked memory.
Background:
In total, we hold 3 references to each Operation Request Block:
- 1 during sbp2_scsi_queuecommand() or sbp2_send_management_orb()
respectively,
- 1 for the duration of the write transaction to the ORB_Pointer or
Management_Agent register of the target,
- 1 for as long as the ORB stays within the lu->orb_list, until
the ORB is unlinked from the list and the orb->callback was
executed.
The latter one of these 3 references is finished
- normally by sbp2_status_write() when the target wrote status
for a pending ORB,
- or by sbp2_cancel_orbs() in case of an ORB time-out,
- or by complete_transaction() in case of a send error.
Of them, the latter two lacked the kref_put.
Add the missing kref_put()s. Add comments to the gets and puts of
references for transaction callbacks and ORB callbacks so that it is
easier to see what is supposed to happen.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-08-16 21:58:03 +02:00
|
|
|
|
|
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-06-10 21:31:36 +02:00
|
|
|
|
2011-05-01 21:06:42 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:47 -05:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:47 -05:00
|
|
|
|
2011-03-15 00:04:42 +01:00
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:32 -05:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
firewire: sbp2: fix memory leak in sbp2_cancel_orbs or at send error
When an ORB was canceled (Command ORB i.e. SCSI request timed out, or
Management ORB timed out), or there was a send error in the initial
transaction, we missed to drop one of the ORB's references and thus
leaked memory.
Background:
In total, we hold 3 references to each Operation Request Block:
- 1 during sbp2_scsi_queuecommand() or sbp2_send_management_orb()
respectively,
- 1 for the duration of the write transaction to the ORB_Pointer or
Management_Agent register of the target,
- 1 for as long as the ORB stays within the lu->orb_list, until
the ORB is unlinked from the list and the orb->callback was
executed.
The latter one of these 3 references is finished
- normally by sbp2_status_write() when the target wrote status
for a pending ORB,
- or by sbp2_cancel_orbs() in case of an ORB time-out,
- or by complete_transaction() in case of a send error.
Of them, the latter two lacked the kref_put.
Add the missing kref_put()s. Add comments to the gets and puts of
references for transaction callbacks and ORB callbacks so that it is
easier to see what is supposed to happen.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2010-08-16 21:58:03 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:47 -05:00
|
|
|
|
2007-02-06 14:49:33 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-06-27 16:04:33 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-05-09 19:23:14 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-01-19 13:15:05 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2008-01-27 19:14:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-04 14:23:00 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-05-09 19:23:14 -04:00
|
|
|
|
2008-07-25 19:44:49 -07:00
|
|
|
|
2007-07-02 21:04:44 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2008-01-20 01:25:31 +01:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
2008-01-20 01:25:31 +01:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
2008-01-25 23:31:12 -05:00
|
|
|
|
2008-01-19 13:15:05 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:47 -05:00
|
|
|
|
2007-07-02 21:04:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-25 19:44:49 -07:00
|
|
|
|
2007-07-02 21:04:44 +02:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-01-19 13:15:05 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-03-07 12:12:47 -05:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 19:23:14 -04:00
|
|
|
|
2007-07-02 21:04:44 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-09 19:23:14 -04:00
|
|
|
|
2007-07-02 21:04:44 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-03 23:08:58 +01:00
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2008-07-20 14:20:53 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-07-20 14:20:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-12 20:29:07 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2008-02-03 23:08:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-07-20 14:20:53 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-02-03 23:08:58 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-02-03 23:08:58 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2010-06-12 20:29:07 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2014-03-03 23:22:35 +01:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-28 20:53:45 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
2008-02-28 20:53:45 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-26 23:30:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-03-07 01:43:31 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: fw-sbp2: set single-phase retry_limit
Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT
register. Per the 1394-1995 specification, the retry_limt portion of the
register should be set to 0x0 initially, and set on the target by a logged in
initiator (i.e., a Linux host w/firewire controller(s)).
Well, as it turns out, lots of devices these days have actually moved on to
starting to implement SBP-3 compliance, which says that retry_limit should
default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops).
Prior to this change, the firewire driver stack didn't touch retry_limit, and
any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable
to retransmit when the host returned an ack_busy_X, which resulted in stalled
out I/O, eventually causing the SCSI layer to give up and offline the device.
The simple fix is for us to set retry_limit to 0xf in the register for all
devices (which actually matches what the old ieee1394 stack did).
Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip
would routinely encounter buffer I/O errors and wind up offlined by the SCSI
layer. With this change, I've encountered zero I/O failures moving tens of GB
of data around.
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-07 01:43:01 -05:00
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2008-07-20 14:20:53 +02:00
|
|
|
|
firewire: fw-sbp2: set single-phase retry_limit
Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT
register. Per the 1394-1995 specification, the retry_limt portion of the
register should be set to 0x0 initially, and set on the target by a logged in
initiator (i.e., a Linux host w/firewire controller(s)).
Well, as it turns out, lots of devices these days have actually moved on to
starting to implement SBP-3 compliance, which says that retry_limit should
default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops).
Prior to this change, the firewire driver stack didn't touch retry_limit, and
any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable
to retransmit when the host returned an ack_busy_X, which resulted in stalled
out I/O, eventually causing the SCSI layer to give up and offline the device.
The simple fix is for us to set retry_limit to 0xf in the register for all
devices (which actually matches what the old ieee1394 stack did).
Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip
would routinely encounter buffer I/O errors and wind up offlined by the SCSI
layer. With this change, I've encountered zero I/O failures moving tens of GB
of data around.
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-07 01:43:01 -05:00
|
|
|
|
2008-07-20 14:20:53 +02:00
|
|
|
|
|
|
|
|
|
2010-06-12 20:29:07 +02:00
|
|
|
|
firewire: fw-sbp2: set single-phase retry_limit
Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT
register. Per the 1394-1995 specification, the retry_limt portion of the
register should be set to 0x0 initially, and set on the target by a logged in
initiator (i.e., a Linux host w/firewire controller(s)).
Well, as it turns out, lots of devices these days have actually moved on to
starting to implement SBP-3 compliance, which says that retry_limit should
default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops).
Prior to this change, the firewire driver stack didn't touch retry_limit, and
any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable
to retransmit when the host returned an ack_busy_X, which resulted in stalled
out I/O, eventually causing the SCSI layer to give up and offline the device.
The simple fix is for us to set retry_limit to 0xf in the register for all
devices (which actually matches what the old ieee1394 stack did).
Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip
would routinely encounter buffer I/O errors and wind up offlined by the SCSI
layer. With this change, I've encountered zero I/O failures moving tens of GB
of data around.
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-07 01:43:01 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2008-02-03 23:09:50 +01:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2008-02-03 23:09:50 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2008-01-27 19:14:44 +01:00
|
|
|
|
2011-08-27 15:33:34 +02:00
|
|
|
|
2008-01-27 19:14:44 +01:00
|
|
|
|
2008-01-24 01:53:19 +01:00
|
|
|
|
2008-10-26 11:04:20 +01:00
|
|
|
|
2008-01-24 01:53:19 +01:00
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2008-02-03 23:11:39 +01:00
|
|
|
|
2008-02-26 23:30:02 +01:00
|
|
|
|
2008-02-03 23:11:39 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
2007-11-07 01:12:51 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-27 15:33:34 +02:00
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
|
|
|
|
|
2008-02-03 23:09:50 +01:00
|
|
|
|
|
|
|
|
|
2008-10-26 11:04:20 +01:00
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
firewire: fw-sbp2: set single-phase retry_limit
Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT
register. Per the 1394-1995 specification, the retry_limt portion of the
register should be set to 0x0 initially, and set on the target by a logged in
initiator (i.e., a Linux host w/firewire controller(s)).
Well, as it turns out, lots of devices these days have actually moved on to
starting to implement SBP-3 compliance, which says that retry_limit should
default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops).
Prior to this change, the firewire driver stack didn't touch retry_limit, and
any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable
to retransmit when the host returned an ack_busy_X, which resulted in stalled
out I/O, eventually causing the SCSI layer to give up and offline the device.
The simple fix is for us to set retry_limit to 0xf in the register for all
devices (which actually matches what the old ieee1394 stack did).
Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip
would routinely encounter buffer I/O errors and wind up offlined by the SCSI
layer. With this change, I've encountered zero I/O failures moving tens of GB
of data around.
Signed-off-by: Jarod Wilson <jwilson@redhat.com>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-03-07 01:43:01 -05:00
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2014-03-07 10:19:57 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2008-02-03 23:10:47 +01:00
|
|
|
|
2008-02-26 23:30:02 +01:00
|
|
|
|
2008-02-03 23:10:47 +01:00
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
2011-08-27 15:33:34 +02:00
|
|
|
|
|
|
|
|
|
2008-02-03 23:10:47 +01:00
|
|
|
|
|
|
|
|
|
2008-02-03 23:04:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-03 23:09:50 +01:00
|
|
|
|
2008-02-26 23:30:02 +01:00
|
|
|
|
2008-02-15 21:29:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-26 17:43:23 +01:00
|
|
|
|
2008-02-15 21:29:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-19 09:05:49 +01:00
|
|
|
|
2008-02-15 21:29:02 +01:00
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2008-02-15 21:29:02 +01:00
|
|
|
|
|
|
|
|
|
2008-02-26 23:30:02 +01:00
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2011-08-27 15:33:34 +02:00
|
|
|
|
|
|
|
|
|
2008-02-15 21:29:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-07 10:19:57 -05:00
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
2014-03-07 10:19:57 -05:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-07 10:19:57 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-02-26 23:30:02 +01:00
|
|
|
|
|
|
|
|
|
2008-10-24 15:26:20 -04:00
|
|
|
|
2008-02-26 23:30:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
firewire: fw-sbp2: (try to) avoid 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.
This avoids I/O errors during reconnect in many but alas not in all
cases. There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset. In these cases, all management ORBs
time out after mgt_orb_timeout. The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
2008-02-16 16:37:28 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2014-03-07 10:19:57 -05:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 19:23:07 -04:00
|
|
|
|
2012-02-15 14:59:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-26 01:44:10 +01:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-26 01:44:10 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-25 23:31:12 -05:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:39:31 +02:00
|
|
|
|
2008-01-25 23:31:12 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-15 14:59:08 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2008-06-24 19:11:13 -07:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-08 00:39:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
2009-10-08 00:39:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-26 17:42:45 +01:00
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
|
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2009-06-06 18:35:27 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-15 14:59:09 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-14 21:47:21 +02:00
|
|
|
|
2013-03-24 17:31:38 +01:00
|
|
|
|
|
|
|
|
|
2008-08-14 21:47:21 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-30 14:43:31 -07:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2008-03-24 20:54:28 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-30 20:27:59 +02:00
|
|
|
|
|
|
|
|
|
2012-05-18 18:39:39 +02:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2011-08-27 15:35:23 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2009-10-08 00:39:31 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-19 00:20:48 +02:00
|
|
|
|
|
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2007-11-07 01:12:51 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2008-10-22 00:28:36 +02:00
|
|
|
|
2011-08-27 15:33:34 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-09 19:23:07 -04:00
|
|
|
|
2011-08-27 15:35:23 +02:00
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2009-04-30 14:43:31 -07:00
|
|
|
|
2011-08-22 21:38:38 +01:00
|
|
|
|
|
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
2011-08-27 15:33:34 +02:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2011-08-27 15:35:23 +02:00
|
|
|
|
|
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-27 19:14:44 +01:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
2011-08-27 15:35:23 +02:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-06 14:49:34 -05:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-15 23:12:34 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2009-02-15 23:12:34 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-01-21 20:45:32 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-18 22:01:14 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2013-06-09 18:15:00 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-28 01:03:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-18 18:40:19 +02:00
|
|
|
|
2009-01-28 01:03:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2012-02-15 14:59:10 +00:00
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2012-02-15 14:59:10 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2012-02-15 14:59:10 +00:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2012-02-15 14:59:10 +00:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-06-27 16:04:33 -04:00
|
|
|
|
|
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2014-03-03 23:23:51 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 19:23:14 -04:00
|
|
|
|
2009-01-28 01:03:34 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-04-10 18:11:18 -04:00
|
|
|
|
2011-04-22 12:21:44 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-08-14 21:47:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-18 18:40:19 +02:00
|
|
|
|
|
|
|
|
|
2007-05-09 19:23:08 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2008-08-14 21:47:21 +02:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-09 19:23:08 -04:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2008-08-14 21:47:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-07-02 22:07:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-25 19:44:49 -07:00
|
|
|
|
2007-07-02 22:07:34 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-07 20:33:32 -04:00
|
|
|
|
|
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-08-14 21:47:21 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-09 19:23:08 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-05-18 18:40:19 +02:00
|
|
|
|
2007-05-09 19:23:08 -04:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-04-22 12:21:44 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-08-09 20:22:17 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-05-09 19:23:14 -04:00
|
|
|
|
2013-03-24 17:32:00 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-04-10 18:11:20 -04:00
|
|
|
|
|
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
2011-04-22 12:21:44 +02:00
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2007-06-10 21:31:36 +02:00
|
|
|
|
2008-02-28 20:51:11 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2008-02-28 20:52:02 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-08-09 20:22:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2008-04-30 11:19:47 +03:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-07-02 21:04:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-28 01:03:34 +01:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2009-01-28 01:03:34 +01:00
|
|
|
|
2007-02-06 14:49:40 -05:00
|
|
|
|
2008-08-09 20:22:17 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-24 18:59:58 -04:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-01-23 21:20:08 +01:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-01-23 21:20:08 +01:00
|
|
|
|
2008-02-17 14:56:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-23 21:20:08 +01:00
|
|
|
|
|
|
|
|
|
2012-05-18 22:26:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-27 22:31:27 +01:00
|
|
|
|
2008-01-01 10:00:10 -06:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-01-23 21:20:08 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-01-23 21:20:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-01-23 21:20:08 +01:00
|
|
|
|
|
|
|
|
|
2008-05-11 00:36:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-23 21:20:08 +01:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2008-05-11 00:35:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2010-02-26 00:20:38 -05:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2011-12-20 21:34:12 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-27 13:18:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-12-14 21:47:04 +01:00
|
|
|
|
|
|
|
|
|
2007-05-27 13:18:27 +02:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-05-27 13:18:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-05-27 13:18:27 +02:00
|
|
|
|
2008-03-24 20:54:28 +01:00
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2007-05-27 13:18:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-02-18 22:01:14 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2007-01-23 21:20:08 +01:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-01-21 20:50:11 +01:00
|
|
|
|
2007-05-27 13:18:27 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-05-05 23:17:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
