From doconnor@cain.gsoft.com.au Tue Sep 28 23:32:35 1999
Return-Path: <doconnor@cain.gsoft.com.au>
Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161])
	by hub.freebsd.org (Postfix) with ESMTP id 229CA14F06
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 28 Sep 1999 23:32:31 -0700 (PDT)
	(envelope-from doconnor@cain.gsoft.com.au)
Received: (from doconnor@localhost)
	by cain.gsoft.com.au (8.8.8/8.8.8) id QAA26462;
	Wed, 29 Sep 1999 16:02:30 +0930 (CST)
	(envelope-from doconnor)
Message-Id: <199909290632.QAA26462@cain.gsoft.com.au>
Date: Wed, 29 Sep 1999 16:02:30 +0930 (CST)
From: "Daniel O'Connor" <doconnor@gsoft.com.au>
Sender: doconnor@cain.gsoft.com.au
Reply-To: doconnor@gsoft.com.au
To: FreeBSD-gnats-submit@freebsd.org
Subject: Data acq process gets stuck in vmopar
X-Send-Pr-Version: 3.2

>Number:         14033
>Category:       kern
>Synopsis:       Data acq process gets stuck in vmopar
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Sep 28 23:40:01 PDT 1999
>Closed-Date:    Tue Jun 5 17:15:26 PDT 2001
>Last-Modified:  Tue Jun 05 17:17:12 PDT 2001
>Originator:     Daniel O'Connor
>Release:        FreeBSD 3.3-RELEASE i386
>Organization:
Genesis Software
>Environment:

3.2, 3.3-RC, 3.3-REL, and 3.3-STABLE. PII-350, 128meg of RAM.

>Description:

We have a PCI data acquisition card which effectivly maps a FIFO into memory
and the kernel reads it during interrupt, and passes the data off to a userland
process in read().

Occasionally (happens much more often when the system is loaded, ie buildworld,
and doing networking) the process reading from the card gets stuck in vmopar. 

I looked in the archives and there was a suggestion that it was NFS related so
I umount'd the NFS partitions but no joy.

This problem does not occur in 2.2.8, and the driver code is almost identical,
(except poll) so I suspect the OS, but I do not know where to start looking.

>How-To-Repeat:

Rather complicated :(

>Fix:
	
Go back to 2.2.8+CAM (blerg)


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Tue Jun 5 13:40:59 PDT 2001 
State-Changed-Why:  

Is this still a problem with recent releases? The most common case 
of processes getting stuck in 'vmopar' was fixed before 4.2-RELEASE 
(nfs_subs.c rev 1.96 + related changes). 


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14033 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Tue Jun 5 17:15:26 PDT 2001 
State-Changed-Why:  

Submitter confirms that this is no longer a problem. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=14033 
>Unformatted:
