Date: Fri, 7 May 1999 09:58:57 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: eivind@FreeBSD.org (Eivind Eklund) Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sbin/camcontrol camcontrol.8 camcontrol.c src/sys/cam cam_ccb.h cam_sim.c cam_sim.h cam_xpt.c src/sys/cam/sc Message-ID: <199905071558.JAA52377@panzer.plutotech.com> In-Reply-To: <19990507111745.A76212@bitbox.follo.net> from Eivind Eklund at "May 7, 1999 11:17:45 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Eivind Eklund wrote...
> On Thu, May 06, 1999 at 05:43:48PM -0700, Kenneth Merry wrote:
> > ken 1999/05/06 17:43:48 PDT
> >
> > Modified files: (Branch: RELENG_3)
> [...]
> > NOTE: These changes will require recompilation of any userland
> > applications, like cdrecord, xmcd, etc., that use the CAM passthrough
> > interface. A make world is recommended.
>
> I thought we were not supposed to do this sort of thing to -stable.
>
> Requirement for 'make world' has been tolerated (barely), but this is
> the first time I've seen anything requiring re-compilation of ports...
This wasn't done without thought -- there was a reason. There were some
bug fixes that went in that required breaking binary compatibility. I
didn't really make that clear in the checkin message, so here's a rundown
of some of the things that were broken.
The first problem was that there was no way for a client of the CCB
interface to determine what the base transfer speed for a device is. For
instance:
{thunderdome:/usr/home/ken:5:0} camcontrol inquiry -n cd -u 0
<NEC CD-ROM DRIVE:500 1.0> Removable CD-ROM SCSI-2 device
Serial Number 0.0MB/s transfers
Note that the transfer speed is printed as 0.0MB/sec, but in the dmesg it's
printed as 3.3MB/sec:
cd0 at ahc0 bus 0 target 4 lun 0
cd0: <NEC CD-ROM DRIVE:500 1.0> Removable CD-ROM SCSI-2 device
cd0: 3.300MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present
There's another bug there, the "Serial Number" prefix is printed out.
(that's also fixed) In any case, in order to print out the transfer speed
when a device hasn't negotiated synchronously, it's necessary to know the
base transfer speed for the controller in question. It's different for
different controllers -- 3.3MB/sec for most parallel SCSI controllers,
100MB/sec for fibre channel, 93K/sec for the vpo driver and 700K/sec for
the umass driver.
The second problem was that we had no way of determining from the device
listing code whether or not a device is configured. For instance:
{thunderdome:/usr/home/ken:7:0} camcontrol devlist
< > at scbus-1 target -1 lun -1 (xpt0)
<QUANTUM XP39100S LYK8> at scbus0 target 0 lun 0 (pass0,da0)
<NEC CD-ROM DRIVE:500 1.0> at scbus0 target 4 lun 0 (pass1,cd0)
<SONY SDT-5000 3.02> at scbus0 target 5 lun 0 (pass2,sa0)
< > at scbus0 target -1 lun -1 ()
The transport layer pseudo-device shows up, as does the "sink" device that
Justin put in a while back. (before 3.1) So, I put an extra flag field
in the device listing output for device nodes that indicates whether the
device is unconfigured. So now, by default, unconfigured devices don't
show up:
# ./camcontrol devlist
<SEAGATE ST34371N 0484> at scbus0 target 0 lun 0 (pass0,da0)
<SEAGATE ST31230W 0510> at scbus1 target 0 lun 0 (pass1,da1)
<SEAGATE ST32155N 0318> at scbus1 target 1 lun 0 (pass2,da2)
<PLEXTOR CD-R PX-R412C 1.04> at scbus1 target 3 lun 0 (pass3,cd0)
<PLEXTOR CD-ROM PX-4XCS 1.04> at scbus1 target 6 lun 0 (pass4,cd1)
They now only show up with -v.
The third problem was that there was no way to figure out whether a given
CCB function code is immediate or non-immediate. Immediate commands are,
as their name implies, executed immediately by the transport layer or
controller driver and then are sent back. Non-immediate commands are
generally sent to the controller for execution, and therefore can take some
time to complete.
We figured the easiest way to solve the problem would be to add flag bits
to the function codes to indicate which ones were non-immediate.
The fourth problem was that there was no way to represent tag values over
255 in the getdev CCB. I think Justin said that the SCSI-3 spec doesn't
specifically set an upper limit on the number of tagged transactions that
can be outstanding, and I think fibre channel might be able to go over 255.
(I can't check these things out for sure right now because my SCSI-3 specs
were on a hard disk that died in a power failure last week.) So we changed
the 'mintags' and 'maxtags' in the getdev CCB from u_int8_t to int.
I would prefer to fix bugs in -stable rather than let them sit there and
annoy people or cause problems.
Ken
--
Kenneth Merry
ken@plutotech.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905071558.JAA52377>