>> I really have no idea what the changes to the driver actually do, but
>> there were other things besides the change from MAX_TAGS to DFLT_TAGS that
>> looked like they might make a difference. And with the driver from 1.2, I
>> had to turn off tags completely to avoid assertion failures. After seeing
>> how FreeBSD's driver performed so much better, I tried recompiling my
>> kernel with the NetBSD 1.2 driver, but with tags turned back on, and I
>> didn't see any improvement at all. So, I suspect that it's not the tags...
>>
>> Also, from what I understand, tagged command queuing lets you send a bunch
>> of requests to the drive, and the drive responds to them in whatever order
>> would be fastest, right? It doesn't seem like that'd affect a sequential
>> read from the drive very much.
>
> Hmm, that sounds more logical than my heedless assumption that it would.
I > don't use dd for drive performance measurements myself, I take a little
> program that measures normal file transfers through the file system and
feed > it very large files.  I find that exposes a broader variety of
problems more > quickly.

I just checked to make sure, and I've been running the NetBSD 1.2 driver (in
the BETA release) for quite some weeks now, with tags enabled, and I haven't
had any problems *at all* with my SCSI subsystem.

Nor have I seen any other complaints about that recently.  In the past,
people who had other problems with a drive on the NCR driver were turning
off tags until the *real* problem got fixed...


--Jim Howard
  jiho@mail.c-zone.net