[475] in linux-scsi channel archive
No subject found in mail header
daemon@ATHENA.MIT.EDU (Richard Waltham)
Fri Aug 4 04:23:23 1995
Date: Thu, 3 Aug 1995 21:28:53 +0100
From: Richard Waltham <dormouse@farsrobt.demon.co.uk>
To: submit-linux-dev-scsi@ratatosk.yggdrasil.com
Newsgroups: linux.dev.scsi
Path: dormouse
From: dormouse@farsrobt.demon.co.uk (Richard Waltham)
Subject: Re: scsi.c bug?
X-Newsreader: TIN [version 1.2 PL2]
Organization: home
Message-ID: <DCr4w4.44@farsrobt.demon.co.uk>
References: <m0sc5Sp-000SmpC@ringo>
Date: Thu, 3 Aug 1995 20:28:51 GMT
Michael Morrison (mike@ringo.reno.nv.us) wrote:
: Hi all,
: I was looking through scsi.c and noticed that a bus reset is issued
: when a RESERVATION CONFLICT is detected. Is this the correct behavior?
: Assume that you have two linux boxes connected to the same target
: on some exotic piece of scsi hardware via the generic scsi driver.
: You then have 1 scsi bus with 2 initiators and 1 target. There is an
: application running on each box that talks to this exotic scsi device.
: If the app on linux-box 1 needs to issue a series of scsi commands that
: need to be atomic on the target. It would have to issue a reserve command,
: do the series of commands, then issue a release command. linux-box 2
: would get a RESERVATION_CONFLICT if it tried to access the exotic device
: while reserved by linux-box 1. The result would be a bus reset which may
: or may not hose linux-box 1. The correct behavior (IMHO) would be to
: probagate the error up and let the higher level code decide what to do
: (which in this case would be to wait awhile and reissue the command).
: Any comments?
: mike
: mike@ringo.reno.nv.us
RESERVATION_CONFLICT implies the target is being used by another
initiator so issuing a bus reset should be the last thing to try!
Retry the command causing the RESERVATION_CONFLICT, after all its
effectively saying the target is busy, but with a different initiator,
rather than busy and unable to receive the command from the current one
where the normal behaviour would be a command retry after some delay.
--
Richard Waltham | dormouse@farsrobt.demon.co.uk
Linux Dummy! | Compuserve 100421.1276
Southampton UK | GTPN 050/066 The Board Room +44 (0) 1703 760099
--
