From owner-freebsd-mobile Thu Jan 21 11:31:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA16254 for freebsd-mobile-outgoing; Thu, 21 Jan 1999 11:31:58 -0800 (PST) (envelope-from owner-freebsd-mobile@FreeBSD.ORG) Received: from dingo.cdrom.com (castles236.castles.com [208.214.165.236]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA16248 for ; Thu, 21 Jan 1999 11:31:56 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id LAA10433; Thu, 21 Jan 1999 11:28:19 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901211928.LAA10433@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Bill Trost cc: mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? In-reply-to: Your message of "Thu, 21 Jan 1999 09:14:49 PST." <74221.916938889@grey.cloud.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Jan 1999 11:28:18 -0800 From: Mike Smith Sender: owner-freebsd-mobile@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > [Oops, sent this to Brian instead of -mobile like I had intended] > > brian@worldcontrol.com writes: > You'll also note the "no f*cking way" theoretical response I > attribute to those "people in power". Why are the "people in power" > so angry all the time? > > ... > > > Crap. Submit the patches, fix them when they break other peoples' > > hardware, and they'll get committed. > > OK, everyone, time to put our corks back in our spleens and stop spewing > around the four-letter words. > > Brian, I am surprised your suggestion to switch to polling exclusively > was ignored. Your idea to switch to polling is a good one. In fact, > Nate Williams posted a message (see > http://www.freebsd.org/cgi/mid.cgi?db=irt&id=199809241705.LAA05726@mt.sri.com) > endorsing the idea. Here is a simple scenario which you are required to handle before polling can be considered a viable solution: A driver for a card is attached to the card. The driver has an interrupt handler. The card in question has an interrupt status register in which bits are set to indicate that the card requires service. The preemptive removal of the card is interpreted by the PCIC as an interrupt coming from the card. Once the card is gone, all of the registers in the mapped space read all-1s. Some solutions worth shooting down before they're suggested: - Polling for the card's presence every iteration of the interrupt handler loop. This is absurdly expensive. Don't suggest polling once on interrupt entry, unless you can guarantee the card won't be pulled during the interrupt handler's execution. - Polling off a clock interrupt - clock interrupts can be masked. - Hacking every interrupt handler to check for consequential evidence of the card being pulled. This is what the PAO folks do, but it's not acceptable simply because it makes assumptions about the card/ pcic that can't be justified, as well as being gross beyond belief. If you can surmount these technical issues without requiring asynchronous notification of card removal, then you'll have created something truly worthwhile. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message