From owner-freebsd-scsi Wed Oct 6 14:36:59 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from front4.grolier.fr (front4.grolier.fr [194.158.96.54]) by hub.freebsd.org (Postfix) with ESMTP id 96BF014EA4 for ; Wed, 6 Oct 1999 14:36:14 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from localhost (ppp-112-249.villette.club-internet.fr [194.158.112.249]) by front4.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with SMTP id XAA03888; Wed, 6 Oct 1999 23:35:40 +0200 (MET DST) Date: Wed, 6 Oct 1999 23:57:07 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Matthew Jacob Cc: "Justin T. Gibbs" , Vadim Belman , scsi@FreeBSD.ORG Subject: Re: 'Unexpected busfree' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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