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>