Subject: Re: Problems with ccd (960413)
To: Jukka Marin <jmarin@muikku.jmp.fi>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: current-users
Date: 05/13/1996 08:10:28
On Mon, 13 May 1996 10:48:26 +0300 (EET DST)
Jukka Marin <jmarin@muikku.jmp.fi> wrote:
> I use ccd to join three 4-gig disks. When doing newfs on the ccd disk,
> the syslog is flooded with
This isn't a problem with the ccd, per se. It's something in the leyers
below the ccd that's causing the problem...
C.f. the sd1 errors, they actually come from sys/scsi/sd.c:sdstart():
[ . . . ]
/* Instrumentation. */
disk_busy(&sd->sc_dk);
/*
* Call the routine that chats with the adapter.
* Note: we cannot sleep as we may be an interrupt
*/
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);
The implication is that your SCSI controller is failing to send the
command. It could also be that the SCSI subsystem is unable to malloc()
storage for a data structure (note the SCSI_NOSLEEP).
Now, the ccd sees the error on the underlying component, and has no
choice but to punt on the transfer. It's sort of like the equivalent of
a SCSI disk driver seeing a large chunk of bad sectors.
> May 13 10:46:11 news /netbsd: sd1: not queuedccd0: error 5 on component 0
> May 13 10:46:12 news last message repeated 25 times
>
> What's wrong? I'm running a 960413 kernel/binaries on a 486 with 64 MB
> RAM.
>
> Thanks in advance,
What kind of hardware are you using; i.e. disk controller and disks...I
notice that these are all on sd1 ... maybe a disk is flaking out?
----save the ancient forests - http://www.bayarea.net/~thorpej/forest/----
Jason R. Thorpe thorpej@nas.nasa.gov
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939