Messages in this thread |  | | Date | Mon, 9 Aug 2004 13:53:49 +0200 | | From | Jens Axboe <> | | Subject | Re: PATCH: cdrecord: avoiding scsi device numbering for ide devices |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |