From owner-freebsd-bugs Fri Mar 31 12:20: 7 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 7F5A237B842 for ; Fri, 31 Mar 2000 12:20:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA00756; Fri, 31 Mar 2000 12:20:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from grey.cloud.rain.com (c1029014-a.bvrtn1.or.home.com [24.12.160.67]) by hub.freebsd.org (Postfix) with ESMTP id EAD7837BE71 for ; Fri, 31 Mar 2000 12:13:09 -0800 (PST) (envelope-from trost@cloud.rain.com) Received: (qmail 82280 invoked by uid 236); 31 Mar 2000 20:13:07 -0000 Message-Id: <20000331201307.82279.qmail@grey.cloud.rain.com> Date: 31 Mar 2000 20:13:07 -0000 From: trost@cloud.rain.com Reply-To: trost@cloud.rain.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/17714: possible priority inversion with use of idprio Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 17714 >Category: kern >Synopsis: possible priority inversion with use of idprio >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Mar 31 12:20:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Bill Trost >Release: FreeBSD 4.0-20000208-CURRENT i386 >Organization: Trost Computing >Environment: Uhh...single 400 MHz Pentium, single IDE drive...not sure what else would matter. >Description: I have a startup script that starts setiathome at an idprio of 31 and then starts up gf_client (a distributed gamma ray flux project) at an idprio of 30. After startup, I noticed that "ps" had an "L" flag in the "STAT" column for setiathome (the lowest priority process). The next command, "man ps", hung; then, "date" (or, more likely, the shell) hung in another window. At this point, I interrupted gf_client, and everything started working again. I presume that the problem was cause by a priority inversion where the setiathome client had somehow locked a page, but could not do whatever needed to be done with the page because gf_client was taking all available CPU cycles. >How-To-Repeat: Hah! Good luck! I have no idea how to make a process keep pages locked in core long enough to cause the problem. >Fix: I would guess that locking a page in core should cause an increase in the process's priority, but I know nothing of the details. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message