Linux-2.1.54 + 2940AU: Unexpected bus free report.

[Doug Ledford]

--------
> Hi,
> 
> I have a problem playing audio CDs that seems to tickle a bug in the 
> aic7xxx reset/abort code that occurs when skipping to the next track.
> 
> This is using linux 2.1.54 with Doug's Sept-5 abort patch.

You do know that several portions of this patch are going to shortly become 
very redundant in the 2.1.x scsi code?  What I mean is, in this patch I'm 
handling the QUEUE_FULL and BUSY conditions internally, where as in the 
upcoming SCSI code those will be taken care of at the mid-level layer, so 
they really shouldn't be in the low level driver.  In any case, for the time 
being it should work, but expect it to at best be redundant, at worst break, 
in later 2.1.x kernels.

> 
> My hardware is a Supermicro P6DNE with a single 200Mhz PPro, AHA-2940AU, 
> Seagate ST3500N (id:0) and a Pioneer DR-124X CDROM (id:6).
> 
> The ST3500N has small partition with linux on for testing new SCSI 
> software before subjecting my 'real' filesystems. Swap is also to the 
> ST3500N.
> 
> The 2940 has BIOS v1.21 and has the default settings apart from having 
> SCAM enabled.
> 
> aic7xxx_verbose is set to 5.

Yikes!!  You're getting the logging info!! :)

> 
> Scenario:
> 
> Boot linux, start workbone, use skip-to-next-track or skip-to-previous-track
> keys.
> 
> Symptoms:
> 
> I always get TARGET_BUSY warnings each time I skip a track. After several 
> skips I start getting the reset messages.
> 
> Logs follow: 

[ snipped the logs ]

I've got those and I'm going to look into the exact code path, but in 
general I do see a few things that could be touched up there that might make 
a difference.

> -----------------------------------------------
> 
> BTW Doug, The abort patch is a great step in the right direction, thanks.
> The behaviour of stock 2.1.54 with the above tests results in tens of
> target busy messages followed by a bus reset and then a kernel panic 
> (NULL pointer defererence) ! 
> 
> Also in 2.1.54 + patch there is one remaining use of the NUMBER() macro
> that still has <= in a for() loop, search for NUMBER(aic7xxx_boards). This
> doesn't look right to me. Should it be < rather than <= ?

I just checked Dan, and he's right.  It's the very first for() loop in 
aic7xxx_detect still uses <= NUMBER(aic7xxx_boards) for an array index, so 
it will write beyond the last element of the array.  I've updated this in my 
patch already, and after I've looked through the logs in more detail and had 
a chance to trace the execution path, I'll probably end up doing another 
patch.  So, hold on to that test for me Simon, I'll have you use it again 
fairly soon :)

-- 
*****************************************************************************
* Doug Ledford                      *   Unix, Novell, Dos, Windows 3.x,     *
* dledford at dialnet.net    873-DIAL  *     WfW, Windows 95 & NT Technician   *
*   PPP access $14.95/month         *****************************************
*   Springfield, MO and surrounding * Usenet news, e-mail and shell account.*
*   communities.  Sign-up online at * Web page creation and hosting, other  *
*   873-9000 V.34                   * services available, call for info.    *
*****************************************************************************