From owner-freebsd-alpha Tue Jan 2 11:43:14 2001 From owner-freebsd-alpha@FreeBSD.ORG Tue Jan 2 11:43:11 2001 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 80DE537B400 for ; Tue, 2 Jan 2001 11:43:11 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f02JgbG01278; Tue, 2 Jan 2001 11:42:37 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 02 Jan 2001 11:43:01 -0800 (PST) From: John Baldwin To: Doug Rabson Subject: RE: Interrupt threads Cc: alpha@FreeBSD.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 28-Dec-00 Doug Rabson wrote: > I started trying to work on changing the interrupt system so that the > ithread runs with i/o interrupts disabled, which would allow us to remove > the ugly code which tries to disable the interrupt sources. > > Unfortunately I immediately came up against a brick wall - the very first > interrupt interrupted a proc which owned Giant and the ithread also wanted > Giant. It tried to block, which switched back to the Giant owner with > interrupts enabled, causing the interrupt to fire again. > > I'm not sure what the right approach to solving this is. Possibly we could > 'lend' the mutex holder the IPL of the blocking thread in a similar way to > priority propagation. Another idea is to link thread IPL directly to its > priority so that when the ithread lends its priority, the mutex owner will > automagically run with raised IPL. I detailed what I think is a way of using IPL to do this in a pair of e-mails to Drew that Matt was copied on. I'll go dig them up and forward them to here. However, tying IPL to a process or a mutex is a mistake I think. You can't tie it to Giant because Giant is going away eventually. You can't tie it to a process because the first context switch that doesn't switch into the ithread will cause the interrupt to fire again. Instead, you basically have to futz with the trapframe in the interrupt handler so it doesn't lower IPL upon returning from teh interrupt, and don't lower the IPL again until the interrupt handler completes and the ithread finishes. Interacting properly with ast() on this makes it a bit more tricky. Let me go dig up my e-mails and forward them to the list. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message