Date: Fri, 22 Jan 1999 16:16:15 -0700 From: Nate Williams <nate@mt.sri.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Nate Williams <nate@mt.sri.com>, Mike Smith <mike@smith.net.au>, "Gary T. Corcoran" <garycor@home.com>, mobile@FreeBSD.ORG Subject: Re: Reclaiming irqs for unsupported PCI hardware? Message-ID: <199901222316.QAA23362@mt.sri.com> In-Reply-To: <5072.917040083@critter.freebsd.dk> References: <199901221950.MAA22394@mt.sri.com> <5072.917040083@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> >> > > > Sure it does. IRQ's are no longer generated on that piece of hardware, > >> > > > but it's possible that the IRQ routine was in the middle of processing > >> > > > the previous (valid) IRQ that was generated 'just prior' to the removal. > >> > > > >> > > Uh, it's also possible for the removal itself to generate an interrupt > >> > > - I had this 100% repeatable on the Sharp I used to use. > >> > > >> > Right, but this does not work reliably on all PCIC controllers. It > >> > works on mine, but I know a number of controllers it does not work on > >> > (for whatever reason). > >> > >> Sorry, you're missing my point - the removal causes a *card* interrupt, > >> not a PCIC interrupt. > > > >Ah, gotcha. FWIW, supposedly the PCIC interrupt supercedes the card > >interrupt in the current code. :) > > Yes, but that doesn't help you if the current context is a section of code > with interrupts masked/disabled... Exactly. This is why the current PCCARD code can still lockup if your in the middle of doing a SLIP/PPP download and you yank the card out. :( > Anyway, I belive that the "->gone" hack in sio.c is probably as > far as it pays to go down this path anyway. Totally agreed. Nate 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?199901222316.QAA23362>