Date: Wed, 6 Oct 1999 23:57:07 +0200 (MET DST) From: Gerard Roudier <groudier@club-internet.fr> To: Matthew Jacob <mjacob@feral.com> Cc: "Justin T. Gibbs" <gibbs@narnia.plutotech.com>, Vadim Belman <voland@plab.ku.dk>, scsi@FreeBSD.ORG Subject: Re: 'Unexpected busfree' Message-ID: <Pine.LNX.3.95.991006231903.499A-100000@localhost> In-Reply-To: <Pine.LNX.4.04.9910061311030.1525-100000@feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Oct 1999, Matthew Jacob wrote: > > In article <85k8p2vvmt.fsf@eagle.plab.ku.dk> you wrote: > > > =09I wonder if someone can tell me: what kind of error is the > > > =09following? > > >=20 > > > Unexpected busfree. LASTPHASE =3D=3D 0x0 > > > SEQADDR =3D=3D 0x5e > > >=20 > > > =09And what do I do with it? > >=20 > > This means that the bus appeared to go free during the middle of a > > transaction. In this case, it happened during a DATAOUT phase. > > Essentially the target hung up without saying good bye first. > >=20 > > These kinds of problems can be caused by bad cabling setups. Perhaps > > the REQ/ACK offset counters got out of sync (initiator did not see a > > REQ pulse) so the target timedout and ended the connection. It's hard > > to say without an analyzer. Be sure to use forced perfect terminators, > > high quality cables, and don't exceed 3m in cable length. >=20 > Also, for some older peripherals I've found that if they detect a parity > error when receiving data they just drop off the bus rather than go to th= e > bother of completing the command first. The behaviour of those old peripherals does not look that bad to me, even if some better one may be possible. Since SCSI parity bit mostly protects against single bit error, a SCSI BUS that experiences oftently SCSI parity errors has some non negligible probability to lead to undetected data corruptions. So, dropping the BUS is such a situation is quite acceptable and warn user about possible BUS problem, provided that the unexpected bus free condition is loudly reported to him by the system.=20 The SCSI device may elect to try to recover by restoring the saved=20 pointers. This may look more user-friendly but will increase the risk of silent data corruption as seen by user. May-be the most clever device decision should be to try asap to complete the command with appropriate sense data, but just dropping the BUS seems to me a more safe device behaviour than trying to recover from a SCSI parity error.=20 G=E9rard. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.3.95.991006231903.499A-100000>