From owner-cvs-all Fri May 7 8:59: 3 1999 Delivered-To: cvs-all@freebsd.org Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125]) by hub.freebsd.org (Postfix) with ESMTP id 514C214A09; Fri, 7 May 1999 08:58:57 -0700 (PDT) (envelope-from ken@panzer.plutotech.com) Received: (from ken@localhost) by panzer.plutotech.com (8.9.3/8.8.5) id JAA52377; Fri, 7 May 1999 09:58:57 -0600 (MDT) From: "Kenneth D. Merry" Message-Id: <199905071558.JAA52377@panzer.plutotech.com> 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 In-Reply-To: <19990507111745.A76212@bitbox.follo.net> from Eivind Eklund at "May 7, 1999 11:17:45 am" To: eivind@FreeBSD.org (Eivind Eklund) Date: Fri, 7 May 1999 09:58:57 -0600 (MDT) Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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 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: 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) at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 4 lun 0 (pass1,cd0) 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 at scbus0 target 0 lun 0 (pass0,da0) at scbus1 target 0 lun 0 (pass1,da1) at scbus1 target 1 lun 0 (pass2,da2) at scbus1 target 3 lun 0 (pass3,cd0) 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