Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Jan 1999 11:28:18 -0800
From:      Mike Smith <mike@smith.net.au>
To:        Bill Trost <trost@cloud.rain.com>
Cc:        mobile@FreeBSD.ORG
Subject:   Re: Reclaiming irqs for unsupported PCI hardware? 
Message-ID:  <199901211928.LAA10433@dingo.cdrom.com>
In-Reply-To: Your message of "Thu, 21 Jan 1999 09:14:49 PST." <74221.916938889@grey.cloud.rain.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> [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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901211928.LAA10433>