From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 1 20:47:32 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42A3F16A4CE for ; Tue, 1 Mar 2005 20:47:32 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8AE743D2F for ; Tue, 1 Mar 2005 20:47:31 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11716 invoked from network); 1 Mar 2005 20:47:31 -0000 Received: from server.baldwin.cx ([216.27.160.63]) (envelope-sender )AES256-SHA encrypted SMTP for ; 1 Mar 2005 20:47:31 -0000 Received: from [10.50.40.202] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.13.1/8.13.1) with ESMTP id j21KlPbW074756; Tue, 1 Mar 2005 15:47:25 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Tue, 1 Mar 2005 13:31:17 -0500 User-Agent: KMail/1.6.2 References: <4223A1D1.6000104@ngs.ru> <200502281606.50074.peter@wemm.org> In-Reply-To: <200502281606.50074.peter@wemm.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200503011331.17677.jhb@FreeBSD.org> X-Spam-Status: No, score=-102.8 required=4.2 tests=ALL_TRUSTED, USER_IN_WHITELIST autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on server.baldwin.cx cc: Denis Ustimenko Subject: Re: TDF_NEEDRESCHED when extending pcb on x86 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2005 20:47:32 -0000 On Monday 28 February 2005 07:06 pm, Peter Wemm wrote: > On Monday 28 February 2005 02:57 pm, Denis Ustimenko wrote: > > Hi, there! > > > > I've tried s3switch utility from ports on 5.2.1 and found that > > i386_set_ioperm syscall doesn't work properly. The next code illustrates > > the problem. It will get SIGBUS with very high probability. > > > > #include > > #include > > #include > > > > int main() > > { > > if ( i386_set_ioperm( 0x80, 1, 1)) { > > perror("XXX"); > > return 1; > > } > > inb( 0x80); > > return 0; > > } > > > > Now I have no 5.3 or CURRENT system but brief looking on code shows that > > it should give the same result on them. > > The problem occurs when we extend pcb and set TDF_NEEDRESCHED bit hoping > > that thread will be rescheduled and new TSS will be loaded. But > > sched_switch function skips cpu_switch when thread was not changed and > > ltr is not executed. > > I think it would be better to fix the semantics of TDF_NEEDRESCHED. I was > thinking that mi_switch could negate the cpu_switch optimization if > TDF_NEEDRESCHED was set. That would avoid duplicating the internal > knowledge of the pcb/tss/etc handling in this code. Forcing a context switch is a rather round-about way of getting ltr to be executed though. We already have intimate knowledge of TSS, etc. in this file anyway, so I wonder if just doing the ltr() directly is the better approach? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org