From owner-freebsd-scsi Tue Jul 6 15:38:13 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id E968914C32 for ; Tue, 6 Jul 1999 15:38:09 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id QAA86869; Tue, 6 Jul 1999 16:38:06 -0600 (MDT) (envelope-from ken) Message-Id: <199907062238.QAA86869@panzer.kdm.org> Subject: Re: Trouble on my DPT controller In-Reply-To: <19990706223212.B61AA9FAE@surf.iae.nl> from Willem Jan Withagen at "Jul 7, 1999 00:32:12 am" To: wjw@iae.nl Date: Tue, 6 Jul 1999 16:38:06 -0600 (MDT) Cc: scsi@freeBSD.org From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Willem Jan Withagen wrote... > You ( Kenneth D. Merry ) write: > => > Jul 6 02:41:30 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc764c - timed out > => > Jul 6 02:41:31 hobby /kernel: (da0:dpt0:0:1:0): CCB 0xc3bc76c8 - timed out > => > It has repeated itself during make worlds.... > => > > => > I'm running a relatively recently -stable (2 weeks old) > => > > => > Is this a hardware problem or a software problem? > => > => I suspect it's a hardware problem. The above message is from the DPT > => driver's timeout handler, and it is complaining about a particular disk or > => array you've got setup. > => > => The timeout for read and write operations from the DA driver is 60 seconds. > => So that means that da0 didn't complete a read or write in 60 seconds. > => > => What sort of disk is da0? There are some disks that are known to lock up > => under heavy I/O. > > It's been a long time since I looked at them, but probably they'll be > "wrong" (any Quantum sort of is, and that's why I have them at home, not at > work. :-) > > da1: Fixed Direct Access SCSI-2 device > da1: Tagged Queueing Enabled > da1: 2013MB (4124224 512 byte sectors: 255H 63S/T 256C) Heh, yeah, Quantum disks are almost always suspicious. :) I don't remember any problems with that drive specifically, although I certainly wouldn't rule out a firmware bug. You should probably look on Quantum's ftp site and see if there is any updated firmware for the drive. They released updated firmware for the Atlas II (LYK8) that fixed the hanging problem, and it's possible there may be newer firmware for that disk. > Is there any way to test the individual disks-defects "through" the DPT > controller? > [~wjw] root@hobby> scsi-defects /dev/rda1 Plist > SCIOCCOMMAND ioctl: Inappropriate ioctl for device > There are no defects (in this list). Well, that's an old script, written for the old SCSI layer's userland interface. Try 'camcontrol defects', like this: camcontrol defects -n da -u 0 -f phys -PG If you look at the camcontrol(8) man page or 'camcontrol help', you'll see more information about the defects command. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message