Date: Wed, 29 Sep 1999 16:02:30 +0930 (CST) From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/14033: Data acq process gets stuck in vmopar Message-ID: <199909290632.QAA26462@cain.gsoft.com.au>
next in thread | raw e-mail | index | archive | help
>Number: 14033 >Category: kern >Synopsis: Data acq process gets stuck in vmopar >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Sep 28 23:40:01 PDT 1999 >Closed-Date: >Last-Modified: >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: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909290632.QAA26462>