Re: AAC vs AMR vs getblk [Re: Processes blocked on getblk or ufs]

Robin P. Blanchard wrote:
>>I'm finally catching up on this thread after a busy couple of 
>>weeks where I wasn't reading much list email.  There seems to 
>>be two problem areas in the thread, AAC and AMR.  For the AAC 
>>problems, I've put a work-around in place until I find the 
>>root cause.  The work-around appears to work well; I can no 
>>longer reproduce the problem where I could eadily reproduce 
>>it before, at the cost of reducing the command pool from 512 
>>to 504.  Not a big hit overall, and I'll hopefully find the 
>>real fix this weekend.
>>
>>Since I can't always read list email in detail, please please 
>>please email me directly if you have problems that might be 
>>related to aac. You'll have a much higher chance of catching 
>>my attention if you do that.
>>
>>For AMR, it looks like there is indeed a real problem, but 
>>the driver is basically without a maintainer at this point.  
>>I don't have the time right now to learn it in enough detail 
>>to be useful.
> 
> 
> Thanks for the time and effort put into this! My dual 2650 is no longer
> exhibiting any getblk issues. I would definitely encourage this being
> back-ported to 5.2-rel or 5.2.1-rel.
> 

Would you mind testing the attached patch under either 5.2 or 5.2.1-RC?

Thanks,

Scott

Index: aac.c
===================================================================
RCS file: /usr/ncvs/src/sys/dev/aac/aac.c,v
retrieving revision 1.81
diff -u -r1.81 aac.c
--- aac.c	9 Nov 2003 09:17:20 -0000	1.81
+++ aac.c	9 Feb 2004 06:41:57 -0000
_at__at_ -1290,8 +1290,10 _at__at_
 	cm->cm_flags |= AAC_CMD_MAPPED;
 
 	/* put the FIB on the outbound queue */
-	if (aac_enqueue_fib(sc, cm->cm_queue, cm) == EBUSY)
+	if (aac_enqueue_fib(sc, cm->cm_queue, cm) == EBUSY) {
+		aac_unmap_command(cm);
 		aac_requeue_ready(cm);
+	}
 
 	return;
 }