Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices

[Jens Axboe]

On Mon, Aug 09 2004, Joerg Schilling wrote:
> >From James.Bottomley@xxxxxxxxxxxx  Sat Aug  7 17:01:00 2004
> 
> >On Thu, 2004-08-05 at 08:00, Jens Axboe wrote:
> >> On Thu, Aug 05 2004, Joerg Schilling wrote:
> >> > -	Parallel (50 bin) SCSI (unknown HBA) on Linux-2.6 does not work if
> >> > 	DMA size is not a multiple of 4. The data transferred from the SCSI
> >> > 	device is OK for the first part that is a multiple of 4.
> >> > 	The remainder of bytes arrive as binary zeroes.
> >> > 
> >> > 	This is a new bug (I received the related information this week).
> >> 
> >> Might be a hardware issue.
> 
> >Probably it is.  Lots of hardware FIFO chips are 4 or 8 bytes wide and
> >can't do partial transfers (because of the way the cycle the data off
> >the bus).  Usually they have logic that sends only partial fragments on
> >to the device for commands, but its not unknown for them to forget this
> >on actual data transfers
> 
> I did already prove that is is a driver bug. Writing again that it _may_
> be a hw bug does not help.

You proved absolutely nothing, you cannot prove anything without
evidence. That's how these things work. It could be a driver issue of
course, but so far there's been zero evidence one way or the other.

> >> That's bogus, the SCSI stack (as well as the block layer) is very well
> >> capable of reporting residual counts, and if the hardware can do it (we
> >> can't get it from some ide hardware :/), we will report residuals.
> >> 
> >> So if it doesn't work it's a bug, but not a design bug.
> 
> >Well...more likely a driver bug.  Residuals have to be reported by the
> >driver.  I thought all of the drivers that could were now doing this,
> >but I might have missed some...which driver is it?
> 
> For Adaptec HW

Ok, so Justins aic7xxx I'm thinking. scgcheck reports residual bug with
the sym driver as well, I'll take a look at it.

> >A selection timeout is reported as DID_NO_CONNECT.
> 
> >DID_TIME_OUT is for cards that can watchdog their commands in hw and is
> >what they return when the watchdog fires.
> 
> >If you actually want visibility into the SCSI mid layer timeout, that's
> >harder since it feeds directly into the error handler that tries to
> >ready the transport and device for action.  In general, a command that
> >times out this way is retried.  If you set the FASTFAIL flag, it will
> >come out with DRIVER_TIMEOUT set in its result area.
> 
> -	Retrying commands that have been send via Generic SCSI is wrong.

Agree

> -	A flag called "FASTFAI" does not exist :-( 

It's an internal flag and it does exist. I'll add the flag to block sg.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/