lkml.org 
[lkml]   [1998]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ncr53c8xx 3.0i + Alpha UDB

On Tue, 13 Oct 1998, Steven N. Hirsch wrote:

> Gerard,
>
> In your last message you requested that I try running with tagged queueing
> disabled, in an effort at diagnosing the chronic device timeouts on my
> Alpha.
>
> You guessed correctly! When I boot with "ncr53c8xx=tags:0", it works
> reliably. I have been pounding on it for two days, and have yet to see a
> timeout or error message. This is two days longer than it has ever stayed
> up before <g>.
>
> However, I note that it is slightly slower (perhaps 15% or so) than the
> 2.5f driver with queue depth of 4. Now that the problem area has been
> isolated, is there any way that reliable tagged queueing can be achieved?

Reliable tagged queueing is achieved on my systems using 8 different SCSI
disks and probably on most systems using the driver (based on the fiew
problem reports I received).

The 3.0x drivers uses a different tag numbering.

- On 2.5f tags are numbered for 1 to maxtags and the scsi command contexts
are walked linearly by the controller on reselection.
- On 3.0x driver, tags are offsets (multiple of 8 for < 32 tags and
multiple of 4 for 32..64 tags) in a jump table that is jumped
indirectly on reselection.

I couldn't decently provide a sequentially walked contexts list for 64
tags support.

In my opinion, it is this new tag numbering scheme that makes problems.
SCSI compliant devices shall support tag number from 0 to 255, so the
values used by driver 3.0x are correct, but your drive seem not to have
been designed for such a tag numbering.

Using 1..maxtag is possible but needs to apply some changes to the driver
and to shift left 3 times the tag value from SCRIPTS on reselection in
order to calculate the jump offset (latency cost: about 2 micro-seconds).

I have planned to prepare such a change and to send you it for testing,
but I donnot have had time enough for now. Anyway, if you have the
problem, other users will probably have the same problem and I probably
cannot avoid to provide this workaround.

Will see what I can do over the week-end.

Regards,
Gerard.




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

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.073 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site