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

Jens Axboe
2004-08-09T11:54:20Z

On Mon, Aug 09 2004, Joerg Schilling wrote:
> >From James.Bottomley@SteelEye.com 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