Subject: sd3: not queued (using ccd) Do I have problems?
To: None <port-sparc@NetBSD.ORG>
From: Marshall Midden <m4@unet.umn.edu>
List: port-sparc
Date: 02/21/1996 08:34:24
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?