From owner-freebsd-current Sat Sep 19 21:49:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA22547 for freebsd-current-outgoing; Sat, 19 Sep 1998 21:49:42 -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 VAA22541 for ; Sat, 19 Sep 1998 21:49:39 -0700 (PDT) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id WAA06694; Sat, 19 Sep 1998 22:42:38 -0600 (MDT) Date: Sat, 19 Sep 1998 22:42:38 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199809200442.WAA06694@narnia.plutotech.com> To: KATO Takenori cc: current@FreeBSD.ORG Subject: Re: [CAM] Broken tagged queuing drive? Newsgroups: pluto.freebsd.current In-Reply-To: <19980920111101H.kato@gneiss.eps.nagoya-u.ac.jp> 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 <19980920111101H.kato@gneiss.eps.nagoya-u.ac.jp> you wrote: > My PC-98 box with AHA-2940UW + > > da2 at ahc0 bus 0 target 2 lun 0 > da2: Fixed Direct Access SCSI2 device > da2: 10.0MB/s transfers (10.0MHz, offset 15) > da2: 2059MB (4218750 512 byte sectors: 8H 32S/T 16478C) > > dies with following message: > > (da2:ahc0:0:2:0) tagged openings now 32 > (da2:ahc0:0:2:0): SCB 0xe - timed out while idle, LASTPHASE == 0x1, SCSISIGI == 0x0 > SEQADDR == 0x9 > SSTAT1 == 0xa > (da2:ahc0:0:2:0): Queuing a BDR SCB > (da2:ahc0:0:2:0): Bus Device Reset Message Sent > (da2:ahc0:0:2:0): no longer in timeout, status = 34c > ahc_intr: AWAITING_MSG for an SCB that does not have a waiting messagepanic:: SCB = 14, SCB Control = 0, MSG_OUT = ff SCB flags = 0 > Debugger("panic") I believe I've found the cause of this panic. I would appreciate it if you could test to see if the next revision of aic7xxx.c survives the timeout. > Does the SAMSUNG WN321010S drive have broken tagged queuing? I > applied following patch and it seems to work for me: My guess is that the SAMSUNG blows away other pending transactions when it sends a queue full message. You may want to try setting maxtags to a value that will avoid the queue full response (perhaps 32 or 31). -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message