Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 7 Apr 1997 15:41:37 -0400 (EDT)
From:      Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
To:        ponds!fee.vutbr.cz!lampa, ponds!idi.ntnu.no!Tor.Egge
Cc:        ponds!freefall.freebsd.org!freebsd-bugs
Subject:   Re: i386/3195: ahc panic
Message-ID:  <199704071941.PAA03532@lakes.water.net>

next in thread | raw e-mail | index | archive | help
> 
> 
> >  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 -




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