From owner-freebsd-bugs  Mon Apr  7 13:20:51 1997
Return-Path: <owner-bugs>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id NAA08532
          for bugs-outgoing; Mon, 7 Apr 1997 13:20:51 -0700 (PDT)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id NAA08521
          for <freebsd-bugs@freefall.freebsd.org>; Mon, 7 Apr 1997 13:20:36 -0700 (PDT)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA03331; Mon, 7 Apr 1997 16:20:04 -0400
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon,  7 Apr 1997 16:20 EDT
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id PAA26463; Mon, 7 Apr 1997 15:35:30 -0400 (EDT)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id PAA03532; Mon, 7 Apr 1997 15:41:37 -0400 (EDT)
Date: Mon, 7 Apr 1997 15:41:37 -0400 (EDT)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199704071941.PAA03532@lakes.water.net>
To: ponds!fee.vutbr.cz!lampa, ponds!idi.ntnu.no!Tor.Egge
Subject: Re: i386/3195: ahc panic
Cc: ponds!freefall.freebsd.org!freebsd-bugs
Content-Type: text
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> 
> 
> >  Still the same problems, after some time error:
> >  
> >  ahc1:A:1: no active SCB for reconnecting target - issuing ABORT
> >  SAVED_TCL == 0x10
> >  ahc1:A:1: Target did not send an IDENTIFY message
> >  LASTPHAS = 0x0, SAVED_TCL = 0x10
> >  
> >  and systems loops in ahc driver, everytime I hit kernel debugger, stack is:
> >  
> >  ahc_scsi_cmd
> >  scsi_scsi_cmd
> >  sdstart
> >  free_xs
> >  scsi_done
> >  ahc_done
> >  ahc_run_done_queue
> >  ahc_reset_channel
> >  
> 
> I see the same problem with FreeBSD 3.0-current.
> 
> (kgdb) where
	
 nice traceback deleted...

> 
> When scsi_scsi_cmd calls ahc_scsi_cmd, ahc_scsi_cmd detects that
> ahc->in_reset is nonzero, and returns COMPLETE; with xs->error set to
> XS_BUSY
> 
> scsi_scsi_cmd then calls sc_err1. sc_err1 performs a DELAY(1000),
> before returning SCSIRET_DO_RETRY. This causes scsi_scsi_cmd to
> go to the retry label, causing an infinite loop.
> 
> Due to this infinite loop being initiated from a timeout, 
> further timeouts are blocked, and ahc->in_reset is never cleared.
> 
> Perhaps free_xs should know when to NOT queue a new request onto the
> device ?
> 
> - Tor Egge
> 

 Hmmm... I'm seeing something *very* similar to this with the aha1542
driver and 2.1.7.1 - see my mail on "Some insights into the dup alloc...".
At least, I'm examining exactly the same area...

 	- Dave Rivers -