From owner-freebsd-current Thu Sep 17 13:00:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13667 for freebsd-current-outgoing; Thu, 17 Sep 1998 13:00:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13606 for ; Thu, 17 Sep 1998 13:00:01 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id NAA08138; Thu, 17 Sep 1998 13:53:11 -0600 (MDT) Date: Thu, 17 Sep 1998 13:53:11 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809171953.NAA08138@narnia.plutotech.com> To: Tony Maher cc: current@FreeBSD.ORG Subject: Re: CAM this and that Newsgroups: pluto.freebsd.current In-Reply-To: <199809171204.WAA26692@morgan.angis.su.OZ.AU> User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <199809171204.WAA26692@morgan.angis.su.OZ.AU> you wrote: > Hello, > > installed CAM last nite (and apart from some operator stupidity concerning > creation of all appropriate devices) and it went well. > > A few things: > > 1. Ignoring all warnings I decided to play with camcontrol. > Tape unit was initially off - switched on, ran camcontrol rescan - > magic... tape drive visible. > Switch tape drive off, ran camcontrol rescan. > Oops cant see tape drive - hmmm lets lock up - time to press the reset > switch (is that why they warn against using camcontrol for novice users > ;-) I shouldn't lock up. What kind of tape device do you have? Were there any console messages leading up to the hang? > So why doesn't my main (and newest disk) do Tagged Queueing? > Reading disk pamphlet and Seagate web site didn't turn up much apart from > using one of the utilities under Netware to send command to turn > taggged queueing on. > Sounds like a a job for camcontrol! > > camcontrol modepage -m 0x0a -u 1 -P 3 -e > > change > Queue Algorithm Modifier: 0 -> 1 Don't even think about doing this. If your other disks have this turned on, you are begging for problems. Setting the Q.A.M to 1 allows the drive to re-order transactions without regard to any write integrity (i.e. write data to LBA X, read data to LBA X, read is serviced before write and you get stale data). > DQue: 1 -> 0 Having DQue as 1 will prevent us from attempting tagged queuing. You would have to save this change and reboot for the system to notice this particular change. Performing a simple camcontrol based rescan might also work, but I'd have to go verify that in the code. > 4. Soon after booting see > (da2:ahc0:0:2:0): tagged openings now 16 > Some limit on this disk set to only 16? The disk only has space for 16 transactions. > 5. This is an old disk and often get (esp. in first 20 mins of > booting) messages like: > > (da2:ahc0:0:2:0): SCB 0x9 - timed out in dataout phase, SCSISIGI == 0x4 > SEQADDR == 0x10e > SSTAT1 == 0x2 > (da2:ahc0:0:2:0): BDR message in message buffer > (da2:ahc0:0:2:0): SCB 0x9 - timed out in dataout phase, SCSISIGI == 0x14 > SEQADDR == 0x10e > SSTAT1 == 0x2 > (da2:ahc0:0:2:0): no longer in timeout, status = 34b > ahc0: Issued Channel A Bus Reset. 17 SCBs aborted > > But system recovers fine! That really looks like a bogus cable or termination. The fact that the problem seems to get better after boot (i.e the device warms up) also points to a setup/connector problem. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message