On Tue, 2008-02-19 at 10:44 -0800, Darrick J. Wong wrote: > If we send an ABORT_TASK ascb that doesn't return within the timeout period, > we should not free that ascb because the sequencer is still holding onto it. > Hopefully it will fix what James Bottomley describes below: > > On Tue, Feb 19, 2008 at 10:22:20AM -0600, James Bottomley wrote: > > > Unfortunately, there's a bug in TMF timeout handling in the driver, it > > leaves the sequencer entry pending, but frees the ascb. If the > > sequencer ever picks this up it will get very confused, as it does a > > while down in the trace: > > > > > aic94xx: BUG:sequencer:dl:no ascb?! > > > aic94xx: BUG:sequencer:dl:no ascb?! > > > > That's where the sequencer adds an ascb to the done list that we've > > already freed. From this point on confusion reigns and the error > > handler eventually offlines the device. > > > > I'll see if I can come up with patches to fix this ... or at least > > mitigate the problems it causes. > > Signed-off-by: Darrick J. Wong <[EMAIL PROTECTED]>
Actually, unfortunately, this is only a tiny part of it. The message that triggered all of this is > sas: sas_scsi_find_task: aborting task 0xffff81033c3d3d80 > aic94xx: tmf timed out > aic94xx: tmf came back That's caused by a timeout at asd_enqueue_internal() further up in the code base. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
