From owner-freebsd-hackers  Fri Apr 28  6:34:26 2000
Delivered-To: freebsd-hackers@freebsd.org
Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0B82837B5CA; Fri, 28 Apr 2000 06:34:23 -0700 (PDT)
	(envelope-from luoqi@watermarkgroup.com)
Received: (from luoqi@localhost)
	by lor.watermarkgroup.com (8.10.1/8.10.1) id e3SDXmd18152;
	Fri, 28 Apr 2000 09:33:48 -0400 (EDT)
Date: Fri, 28 Apr 2000 09:33:48 -0400 (EDT)
From: Luoqi Chen <luoqi@watermarkgroup.com>
Message-Id: <200004281333.e3SDXmd18152@lor.watermarkgroup.com>
To: dick@seaman.org, green@FreeBSD.ORG
Subject: Re: lock-ups due to the scheduler
Cc: hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> There may be additional issues with the scheduler, though they may not
> be related to the issue you have.  Check www.freebsd.org/~dick/sched.descr
> I was under the impression that Peter Dufault had re-assumed this matter,
> but not much has happened on most of the issues.
> 
Could you add the this problem to your list: p_rqindex does not encode
which queue a process is on? Consider this scenario, we are lowering a
process' priority from realtime to normal. This process is in runnable
state on one of the run queues while another process is changing its
p_rtprio, after it's done, a clock intr comes and the scheduler decides
the process should go to another run queue, so it tries to remove process
on the p_rqindex'th normal priority run queue and results in data corruption.

When changing a process from one scheduling class to another, we should also
move it to the apprioriate run queue (if it's in runnable state). When that's
done, we will start getting reports about corrupted run queues...

-lq


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message