From owner-freebsd-arch Wed Jan 29 17:11: 4 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D4D437B401 for ; Wed, 29 Jan 2003 17:11:02 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDC2A43E4A for ; Wed, 29 Jan 2003 17:11:01 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h0U195J75576; Wed, 29 Jan 2003 20:09:05 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Wed, 29 Jan 2003 20:09:05 -0500 (EST) From: Jeff Roberson To: Matthew Dillon Cc: Kris Kennaway , Julian Elischer , Subject: Re: Found another SCHED_ULE bug. In-Reply-To: <200301300040.h0U0eJQe070153@apollo.backplane.com> Message-ID: <20030129200528.Y31308-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 29 Jan 2003, Matthew Dillon wrote: > I think the problem has to do with how KEF_NEEDRESCHED is > set in sched_wakeup(). Specifically, in sched_wakeup() > you only set KEF_NEEDRESCHED on curthread, missing the fact > that the KSE may have been added to a different cpu's queue. > Setting KEF_NEEDRESCHED on curthread for the current cpu will > not necessarily reschedule the thread being woken up on the > target cpu. It looks like this isn't terribly important for anything other than interrupt handlers or maybe 'real-time' threads. The solution for interrupt handlers is simple. If we can preempt we can force it to run on the cpu that the interrupt fired on. I have this in my local tree but it needs to be implemented in a more general way. I will produce a patch in the next few days. If we want to solve it for things other than interrupt handlers we'll have to peak at the currently executing thread on the cpu that we're inserting the thread onto. This is sort of gross. > > I'm not sure how to solve the problem in ULE. I tried calling > forward_signal() on the target cpu's curthread, but it > panic'd with 'thread not TDS_RUNNING' or something like that. > You may have to force the interrupt thread to be scheduled on > the current cpu in order to properly reschedule it. Thanks for the bug report! Cheers, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message