2019-05-27 08:55:05 +02:00
|
|
|
|
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:04:38 +01:00
|
|
|
|
2006-12-19 19:58:40 -05: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-03 23:12:17 +01:00
|
|
|
|
2009-06-04 21:09:38 +02:00
|
|
|
|
|
|
|
|
|
2008-02-03 23:12:17 +01: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
|
|
|
|
|
|
|
|
|
scsi: sd: Differentiate system and runtime start/stop management
The underlying device and driver of a SCSI disk may have different
system and runtime power mode control requirements. This is because
runtime power management affects only the SCSI disk, while system level
power management affects all devices, including the controller for the
SCSI disk.
For instance, issuing a START STOP UNIT command when a SCSI disk is
runtime suspended and resumed is fine: the command is translated to a
STANDBY IMMEDIATE command to spin down the ATA disk and to a VERIFY
command to wake it up. The SCSI disk runtime operations have no effect
on the ata port device used to connect the ATA disk. However, for
system suspend/resume operations, the ATA port used to connect the
device will also be suspended and resumed, with the resume operation
requiring re-validating the device link and the device itself. In this
case, issuing a VERIFY command to spinup the disk must be done before
starting to revalidate the device, when the ata port is being resumed.
In such case, we must not allow the SCSI disk driver to issue START STOP
UNIT commands.
Allow a low level driver to refine the SCSI disk start/stop management
by differentiating system and runtime cases with two new SCSI device
flags: manage_system_start_stop and manage_runtime_start_stop. These new
flags replace the current manage_start_stop flag. Drivers setting the
manage_start_stop are modifed to set both new flags, thus preserving the
existing start/stop management behavior. For backward compatibility, the
old manage_start_stop sysfs device attribute is kept as a read-only
attribute showing a value of 1 for devices enabling both new flags and 0
otherwise.
Fixes: 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-09-15 10:02:41 +09: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
|
|
|
|
2022-04-09 13:12:42 +09: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
|
|
|
|
2022-04-09 13:12:42 +09:00
|
|
|
|
2007-05-07 20:33:35 -04:00
|
|
|
|
2022-04-09 13:12:42 +09: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
|
|
|
|
2022-04-09 13:12:42 +09: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08: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
|
|
|
|
2008-02-03 23:08:58 +01:00
|
|
|
|
2008-07-20 14:20:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-12 20:29:07 +02:00
|
|
|
|
2008-02-03 23:08:58 +01: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
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08: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
|
|
|
|
2007-02-06 14:49:34 -05: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2007-08-25 14:05:28 +02: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
|
|
|
|
|
|
|
|
|
2007-08-25 14:05:28 +02: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-12-26 01:44:10 +01: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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-25 14:05:28 +02: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-24 19:41:46 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
2007-08-13 17:48:25 +02:00
|
|
|
|
2007-08-25 14:05:28 +02: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
|
|
|
|
|
|
|
|
|
2023-03-22 12:54:00 -07: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
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2009-06-06 18:35:27 +02:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2012-02-15 14:59:09 +00: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-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
|
|
|
|
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-06-30 20:27:59 +02:00
|
|
|
|
|
|
|
|
|
2012-05-18 18:39:39 +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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-30 14:43:31 -07:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2009-06-06 18:35:27 +02: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-08-25 14:05:28 +02:00
|
|
|
|
2007-11-07 01:12:51 +01:00
|
|
|
|
2007-08-25 14:05:28 +02:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
2013-06-09 18:15:00 +02: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-27 15:35:23 +02:00
|
|
|
|
2011-08-27 15:34:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-06-09 18:15:00 +02: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2021-10-07 13:27:59 -07: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
|
|
|
|
|
|
|
|
|
2006-12-19 19:58:40 -05: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-15 13:03:41 -08: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
|
|
|
|
2026-01-15 13:03:41 -08:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
2026-01-15 13:03:41 -08:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08: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
|
|
|
|
2006-12-19 19:58: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
|
|
|
|
|
|
|
|
|
2024-10-22 11:07:53 -07: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
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-22 11:07:54 -07: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
|
|
|
|
|
|
|
|
|
scsi: sd: Differentiate system and runtime start/stop management
The underlying device and driver of a SCSI disk may have different
system and runtime power mode control requirements. This is because
runtime power management affects only the SCSI disk, while system level
power management affects all devices, including the controller for the
SCSI disk.
For instance, issuing a START STOP UNIT command when a SCSI disk is
runtime suspended and resumed is fine: the command is translated to a
STANDBY IMMEDIATE command to spin down the ATA disk and to a VERIFY
command to wake it up. The SCSI disk runtime operations have no effect
on the ata port device used to connect the ATA disk. However, for
system suspend/resume operations, the ATA port used to connect the
device will also be suspended and resumed, with the resume operation
requiring re-validating the device link and the device itself. In this
case, issuing a VERIFY command to spinup the disk must be done before
starting to revalidate the device, when the ata port is being resumed.
In such case, we must not allow the SCSI disk driver to issue START STOP
UNIT commands.
Allow a low level driver to refine the SCSI disk start/stop management
by differentiating system and runtime cases with two new SCSI device
flags: manage_system_start_stop and manage_runtime_start_stop. These new
flags replace the current manage_start_stop flag. Drivers setting the
manage_start_stop are modifed to set both new flags, thus preserving the
existing start/stop management behavior. For backward compatibility, the
old manage_start_stop sysfs device attribute is kept as a read-only
attribute showing a value of 1 for devices enabling both new flags and 0
otherwise.
Fixes: 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-09-15 10:02:41 +09:00
|
|
|
|
2023-11-21 07:56:30 +09:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
scsi: sd: Differentiate system and runtime start/stop management
The underlying device and driver of a SCSI disk may have different
system and runtime power mode control requirements. This is because
runtime power management affects only the SCSI disk, while system level
power management affects all devices, including the controller for the
SCSI disk.
For instance, issuing a START STOP UNIT command when a SCSI disk is
runtime suspended and resumed is fine: the command is translated to a
STANDBY IMMEDIATE command to spin down the ATA disk and to a VERIFY
command to wake it up. The SCSI disk runtime operations have no effect
on the ata port device used to connect the ATA disk. However, for
system suspend/resume operations, the ATA port used to connect the
device will also be suspended and resumed, with the resume operation
requiring re-validating the device link and the device itself. In this
case, issuing a VERIFY command to spinup the disk must be done before
starting to revalidate the device, when the ata port is being resumed.
In such case, we must not allow the SCSI disk driver to issue START STOP
UNIT commands.
Allow a low level driver to refine the SCSI disk start/stop management
by differentiating system and runtime cases with two new SCSI device
flags: manage_system_start_stop and manage_runtime_start_stop. These new
flags replace the current manage_start_stop flag. Drivers setting the
manage_start_stop are modifed to set both new flags, thus preserving the
existing start/stop management behavior. For backward compatibility, the
old manage_start_stop sysfs device attribute is kept as a read-only
attribute showing a value of 1 for devices enabling both new flags and 0
otherwise.
Fixes: 0a8589055936 ("ata,scsi: do not issue START STOP UNIT on resume")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
2023-09-15 10:02:41 +09: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
|
|
|
|
2024-04-09 16:37:38 +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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 16:35:15 -07:00
|
|
|
|
|
|
|
|
|
2007-05-27 13:18:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-12 16:35:15 -07:00
|
|
|
|
|
|
|
|
|
2023-03-22 12:54:00 -07: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
|
|
|
|
2024-10-22 11:07:53 -07:00
|
|
|
|
2024-10-22 11:07:54 -07:00
|
|
|
|
2006-12-19 19:58:40 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-16 17:12:15 +01:00
|
|
|
|
2007-01-21 20:50:11 +01:00
|
|
|
|
2021-10-12 16:35:15 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
