Date: Sat, 4 Jan 2003 13:45:29 +0100 (CET) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@free.fr> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: Nate Lawson <nate@root.org>, Chuck McCrobie <mccrobie2000@yahoo.com>, <freebsd-scsi@FreeBSD.ORG> Subject: Re: SCSI Problems with sym and Western Digital on FreeBSD 4.7-stable Message-ID: <20030104124808.C5252-100000@localhost.my.domain> In-Reply-To: <87850000.1041286441@aslan.btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Dec 2002, Justin T. Gibbs wrote: > > On Fri, 27 Dec 2002, Chuck McCrobie wrote: > >> I am having SCSI problems with the sym driver and a > >> Western Digital hard disk. Under the -stable kernel > >> built on 'Dec 1', the drive show up fine with 16-bit > >> wide transfers at 40 MHz. Under the most recent > >> -stable kernel built on 'Dec 17', the Western Digital > >> gets some type of very weird error message. The > >> Western Digital is "da1". > > > >> (probe2:sym0:0:2:0): ODD transfer in DATA IN phase. > >> (probe2:sym0:0:2:0): COMMAND FAILED (87 0 10). > >> (probe2:sym0:0:2:0): ODD transfer in DATA IN phase. > >> (probe2:sym0:0:2:0): COMMAND FAILED (87 0 10). > >> (probe2:sym0:0:2:0): ODD transfer in DATA IN phase. > >> (probe2:sym0:0:2:0): COMMAND FAILED (87 0 10). > >> (probe2:sym0:0:2:0): ODD transfer in DATA IN phase. > >> (probe2:sym0:0:2:0): COMMAND FAILED (87 0 10). > >> (probe2:sym0:0:2:0): ODD transfer in DATA IN phase. > >> (probe2:sym0:0:2:0): COMMAND FAILED (87 0 10). > > > > These appear to be the problem. Since nothing has changed in sym(4) fo= r a > > long time, this has to be elsewhere, perhaps in dma system. > > My guess is that the WD guys didn't set their additional inquiry > length correctly and/or the length is correct, but they fail to > issue an ignore wide residue for the last transfer. The problem > only shows up now because we properly calculate the extra inquiry > length. Perhaps we should do what Gerard suggested and round up > to an even transfer size. Let this suggestion be suggestion #1. :) Another way (suggestion #2) could be to return success from SIM with a negative residual (-1 in this case) and leave upper layer handle the situation as it wants. As seen from the sym driver there is no semantic difference as it would be just a different way to report the problem. Is this an acceptable behaviour as expected by CAM? But what about situation where there is more than 1 extra byte returned or when a single extra-byte is returned in 8 bit mode, for example ? IMO, the CAM_DATA_RUN_ERR status may well be the way to go here. (Btw, for now, the sym driver returns CAM status CAM_DATA_RUN_ERR but the residual value returned is already -1). Note that if the IO buffer for inquiry is rounded up to an even size (suggestion #1), the upper layer can also catch the situation from the residual (will be zero when expected to be at least 1). There is no information loss here too (additionnaly, there is no needed change in sym). As suggestion #3, we might consider that CAM status CAM_DATA_RUN_ERR refers to data overrun conditions detected as caused by real hardware errors. Then, when a device returns more data than expected without real hardware error having been detected, SIM will just return CAM_REQ_CMP but supply a negative residual for the IO. No information less in the report here too. For my part, I do prefer #1 or #3 over #2. 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?20030104124808.C5252-100000>