Concern has arisen due to messages of the following nature:
	sd3: not queued
(Via dmesg, the "d" at the end of queued does not show up -- is in messages.)

NetBSD-current, January 16th, 1996 @ 7am "sup".
Q#1: Do I lose data when the above messages occur?
Q#2: Anyone got a pointer on how to actually use the "ccd" driver for:
     a) disk striping (cdc wren 6's, 53 sec/trk, 15 trks/cyl, 1628 cyl)
     b) concatenation
     c) mirroring
     d) is the "8" in the pseudo-device for the number of /dev/ccd's, or
	anyhow related to the number of entries on a specific ccd config?
	(I'd guess just the /dev/ccd, but ...)
     Explained ccd.conf files would do wonderfully in the man page!  Something
     that explains how much extra space to leave for the ccd0 disklabel, etc.
     I.e. do I need to allocate a track on each disk drive in a striped
     configuration, and then another track within the ccd0 disklabel?  Playing
     got me frustrated, but finally got something that works hopefully very
     well (see Q#1).
P.S. before anyone asks, I did have to get new good scsi cables for the six
external disks running on an ELC.  I'd be using scsi 4 for a tape drive, but as
other people have pointed out, there is something massively wrong with the st
code -- getting a tape error is rather neat!
---------------
/etc/fstab:
  /dev/sd1a / ffs rw 1 1
  /dev/sd1b none swap sw 0 0
  /dev/sd1g /usr ffs rw 1 2
  /dev/sd1h /usr/src ffs rw 1 2
  /dev/ccd0g /mnt ffs rw 1 3
  /dev/sd5h /mnt1 ffs rw 1 3
  /dev/sd6c /wabe ffs rw 1 3
---------------
/etc/ccd.config
  ccd0	16	none	/dev/sd2g /dev/sd3g /dev/sd0g /dev/sd1d
---------------
Configuration file relevance:
...
   sd0	at scsibus? target 3 lun ?
   sd1	at scsibus? target 1 lun ?
   sd2	at scsibus? target 2 lun ?
   sd3	at scsibus? target 0 lun ?
   sd4	at scsibus? target 4 lun ?
   sd5	at scsibus? target 5 lun ?
   sd6	at scsibus? target 6 lun ?
   sd*	at scsibus? target ? lun ?
...
   pseudo-device ccd  8
...
---------------
A grep through kernel sources shows:
sd.c:
		if (scsi_scsi_cmd(sc_link, cmdp, cmdlen,
                    (u_char *)bp->b_data, bp->b_bcount,
                    SDRETRIES, 10000, bp, SCSI_NOSLEEP |
                    ((bp->b_flags & B_READ) ? SCSI_DATA_IN : SCSI_DATA_OUT)))
                        printf("%s: not queued", sd->sc_dev.dv_xname);
---------------
scsi_base.c:
/* ask the scsi driver to perform a command for us.  tell it where to read/write
  the data, and how long the data is supposed to be. If we have a buf to
  associate with the transfer, we need that too. */
int scsi_scsi_cmd(sc_link, scsi_cmd, cmdlen, data_addr, datalen, retries,
	timeout, bp, flags)
  struct scsi_link *sc_link; struct scsi_generic *scsi_cmd; int cmdlen;
  u_char *data_addr; int datalen; int retries; int timeout; struct buf *bp;
  int flags;
{
	struct scsi_xfer *xs;
        int error;

        SC_DEBUG(sc_link, SDEV_DB2, ("scsi_cmd\n"));
        if ((xs = scsi_make_xs(sc_link, scsi_cmd, cmdlen, data_addr, datalen,
            retries, timeout, bp, flags)) == NULL)
                return ENOMEM;
        if ((error = scsi_execute_xs(xs)) == EJUSTRETURN)
                return 0;
	/* we have finished with the xfer stuct, free it and
           check if anyone else needs to be started up.  */
        scsi_free_xs(xs, flags);
        return error;
}
---------------
I do not wish to continue looking, does anyone know if I have anything to
worry about?