Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Jul 1999 16:38:06 -0600 (MDT)
From:      "Kenneth D. Merry" <ken@plutotech.com>
To:        wjw@iae.nl
Cc:        scsi@freeBSD.org
Subject:   Re: Trouble on my DPT controller
Message-ID:  <199907062238.QAA86869@panzer.kdm.org>
In-Reply-To: <19990706223212.B61AA9FAE@surf.iae.nl> from Willem Jan  Withagen at "Jul 7, 1999 00:32:12 am"

next in thread | previous in thread | raw e-mail | index | archive | help
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: <QUANTUM FIREBALL_TM2110S 300X> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907062238.QAA86869>