Date: 26 Oct 1999 15:38:20 +0000 From: Randell Jesup <rjesup@wgate.com> To: nate@mt.sri.com (Nate Williams) Cc: Terry Lambert <tlambert@primenet.com>, imp@village.org, arch@freebsd.org Subject: Re: Racing interrupts Message-ID: <ybug0yyku8j.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> In-Reply-To: Nate Williams's message of "Tue, 26 Oct 1999 09:25:03 -0600" References: <199910260105.TAA16714@mt.sri.com> <199910260221.TAA26021@usr06.primenet.com> <199910260356.VAA17204@mt.sri.com> <ybuln8ql6gk.fsf@jesup.eng.tvol.net.jesup.eng.tvol.net> <199910261525.JAA18872@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Williams <nate@mt.sri.com> writes:
>> >The PCMCIA/PCCARD hardware/software specification did not take into
>> >account some very important design considerations.
>>
>> Such as? Of course, just because the MS spec says you should be
>> able to pop out the hardware at any time doesn't mean you can't make
>> software that says "you MUST shut down the driver before removing the card
>> or you may lose all your work", but the problem with that is that it breaks
>> the user's expectations, especially if all the other vendors handle it.
>> Not to mention that it's a bad idea from a CHI standpoint.
>
>You're missing the point. What happens if I'm in the middle of a ISR
>when the device is popped out? How do I recognize that it's gone, when
>I'm expecting the hardware to respond to some request I've sent it?
>What happens when I'm reading a piece of memory that no longer exists?
Ok, talking to the technical issues:
[This assumes there's a high-priority interrupt to notify us of
card removal, and the ISR for the interrupt merely sets a flag. It also
assumes that the hardware doesn't go away before the interrupt occurs,
but may be gone by the time the processor handles the interrupt, and that
all pccard ISR's are at a lower interrupt priority than the hardware-is-
gone int.]
First, if you're reading memory that may not exist, check a
flag (whatever) after a series of associated reads, and use that to
know if the reads may have been garbage or not.
After sending a request to the hardware (probably by writing to
a register), check said flag, and if the hardware is gone, abort the
transaction (to the caller) with an error.
When a card is removed, wake up all pccard drivers that are in
sleeps waiting on hardware, and let them notice that the hardware is
gone and appropriately error out requests.
If you're in the middle of an ISR: Check said flag (insertion
state) at appropriate points. In many cases, you merely need check once
or twice I suspect. (I assume writes to removed cards go into the ether,
and reads return something random, which you may need to watch out for -
but often only one check before commiting the results of the interrupt.)
Even if you have to check it a fair number of times, the overhead shouldn't
be large.
Have I missed something? Some aspect of Unix device drivers I'm
not familiar with?
>> >It's broken by design, and although I can minimize the problems in
>> >software, there are still going to be races inherent in the design.
>>
>> Then change the design.
>
>I can't. I don't control the hardware such that the software can be
>informed that the device is being removed *before* the hardware is
>removed.
Sorry, I should have been more specific (or the person I replied
to (you?) should have been): I meant the software/driver design.
>> >foolish. I worked hard (and got lost of good help from Bruce) to
>> >make the window small, but in the end realized that it it couldn't be
>> >fully eliminated, and to minimize it further required re-writing many of
>> >the existing drivers, which would potentialy reduce performance and
>> >increase complexity with very little 'gain'.
>>
>> Why can't it be fully eliminated?
>
>See above, plus previous emails sent on the topic. If that isn't
>enough, go read the specification and go think about the problem a
>little bit. And if this sounds harsh, it's not meant to, but trying to
>explain why it's a problem requires a little bit of experience trying to
>fix the problem plus some out of the box thinking about the problem.
>
>[
>And yes, I've thought about the problem, plus I've coded up the
>existing suspend/resume code in FreeBSD to minimize the race, but I've
>not eliminated it since I believe it can't be eliminated completely.
>]
Understood - note that I have programmed PCMCIA devices in the
(fairly far) past, along with many other hardware drivers, though not
under Unix.
>> When I pop a card out, it should _never_ crash. If there's no
>> way to avoid the chance of a crash (even 1%), you should not support
>> popping of (active) cards out at all.
>
>That's my point. You can claim to not support it (like Win98 does), but
>it doesn't stop people from doing it. If they do it it'll crash, so who
>looks bad, the OS or the person?
The OS/drivers, whether or not it's justified. There are ways
to browbeat users into not doing it, however. (Such as by screaming
bloody murder if they do, even when it doesn't crash.)
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
rjesup@wgate.com
CDA II has been passed and signed, sigh. The lawsuit has been filed. Please
support the organizations fighting it - ACLU, EFF, CDT, etc.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ybug0yyku8j.fsf>