Erik says:
> 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
> (packrat!).

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
into syslog.

/a