Subject: Re: SCSI oddiments in PR#3815
To: None <tech-kern@NetBSD.ORG>
From: Alexis Rosen <firstname.lastname@example.org>
Date: 08/04/1997 14:49:50
> The trivial changes in PR#3815 have been committed.
> As for always reporting the sync SCSI transfer rate, that currently appears
> in the device drivers, not in the MI code, and there's not currently a way
> to pass that up to the MI SCSI code. To make it consistent right now, we'd
> have to change each SCSI driver that supports sync transfer.
> The question is - should we bother with either change? I wanted the sync
> transfer rate just for my own information (it's useful to see what a SCSI
> device will claim about itself) so I was happy to see it show up on the
> sparc when I compiled with DEBUG (it's in dev/ic/ncr53c9x.c), but I'm not
> sure it's worth adding the information to a structure someplace to pass it
> up from the low SCSI to high SCSI just for reporting. I have this notion
> that the information might be useful at some later date for scheduling disk
> transfers across the SCSI busses, but that's just a handwave and me not
> wanting to dispense with any information that might be useful later
This sort of info can be very useful when trying to debug some disk problems.
If your cabling is marginal, you may negotiate a lower-speed sync xfer rate,
or even async. (I'm assuming that the drivers are smart enough to do that; I
haven't looked, but they are on several other OSes.) Knowing this can tell
you you have a problem, and suggest a way to fix it (ie, get better cables,
or isolate your non-standard SCSI device on its own controller).
In fact if the driver renegotiates SCSI speed with a device, it should go