If it were based on the PCI wiring, then presumably changing the slot =
into
which the card is plugged should change the interrupt priority;
experimentation on one motherboard indicated that this did not occur. =
The
board always appeared to have the same interrupt level no matter what =
slot
it was plugged into. The PCI BIOS and/or Windows always seemed to =
assign
the same priority value. Alas, it was a realtime board with tight
constraints on interrupt latency, and they never could get it to work =
right.
My own observation was that since (as they had told me) the engineer =
based
the design on his ability to reprogram the APIC on a bare (well, MS-DOS)
x86, he had erroneously assumed that this was going to be universally
possible on all machine architectures, for all operating systems. The
problem was solved by a board redesign with an onboard FIFO, but I =
didn’t
hear about this for a couple more years. That’s why I was curious as =
to
whether there really was any method available to reassign interrupt
priorities. =20
I have found far too many hardware designers assume that what they can =
do on
a bare or MS-DOS x86 is used as their guideline for doing minimum-cost
design, letting “the software” (whatever THAT means!) solve the rest of =
the
problems. The design I just described is only one of several that I =
have
seen over the last decade or so that suffered from this particular =
disease
of hardware designers. Ed Dekker has even more frightening stories =
about
hardware designers. I’m sure many of the other participants in this =
group
do, also.
This is not a new phenomenon; I saw the same problems on the PDP-11. I
remember having to open “priority windows” in the middle of one device
driver so the (lower-priority, real-time) tape controller could detect =
the
BOT mark and stop the reels before the tape spun off. Of course, this =
meant
I could get recursive interrupts. ARGH! (Funny, hardware designers in =
2009
seem to make the same design errors that were made in 1975…doesn’t =
anyone
LEARN? Doesn’t anyone TEACH principles of Bad Hardware Design?)
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, July 29, 2009 5:00 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Question abuot masking interrupt
Only that just hasn’t been true for a long time for device interrupt
levels, which are just more or less arbitrarily assigned based on pci
wiring on the board and not on any importance of a device that happens
to be plugged into one slot or another.
Mark Roddy
On Wed, Jul 29, 2009 at 12:01 PM, Joseph M.
Newcomer wrote:
> Generally, the idea is that the reason the interrupt is at a =
=93higher
> priority=94 is because it is more important than the lower-priority
> interrupts.=A0 The consequence of allowing lower-priority interrupts =
is that
> an unimportant device that is interrupting frequently can consume all =
the
> CPU cycles, thus delaying the response to the more important device.
>
>
>
> This is a variant of what is called the =93priority inversion=94 =
problem,
where
> a low-priority thread sets a lock, then is preempted by higher =
priority
> threads, but then a high-priority thread tries to acquire the lock, =
and
ends
> up being blocked for an indeterminate and perhaps indefinitely long =
time
by
> the lower-priority thread. =A0The result of this is that the =
high-priority
> thread effectively gets cycles only when the lower-priority thread =
runs,
> thus effectively making it a low-priority thread (hence the term =
=93priority
> inversion=94).
>
>
>
> I have encountered several situations in which the priority assigned =
by
the
> system BIOS was inappropriate for the device. =A0Changing priorities =
is a
> difficult, or perhaps impossible, task.
>
>
>
> Note that on a multiprocessor, in general if an interrupt is blocked =
on
CPUn
> because CPUn is running at a certain DIRQL level, the interrupt is
rerouted
> by the hardware to interrupt CPUm for m !=3D n, if it is =
interruptible. =A0So
it
> is possible to have as many interrupts running as CPUs in a
fully-symmetric
> multiprocessor system (the world changes in Vista, which supports
asymmetric
> device connections that might interrupt only a subset of the CPUs, as
> specified by the =93affinity mask=94 that specifies the CPUs that are =
allowed
> to/able to handle the interrupt).
>
>
>
> For PCI, interrupts are level-triggered, so as long as the device =
holds
the
> interrupt line low, the interrupt is held pending.=A0 There is some
analogous
> mechanism for handling message-based interrupts (only Vista and beyond
have
> support for message-based interrupts).=A0 It is not clear that there =
was
ever
> a situation in which edge-triggered interrupts could be lost =
(certainly
not
> when I was doing MS-DOS device drivers for ISA cards! =A0I had to =
quite
often
> deal with arbitrarily-long-delayed edge-triggered interrupts!) =A0It =
is
> unlikely that something that worked back in the days of ISA would be =
lost
in
> modern architectures when such a failure could be disastrous.
>
>
>
> Note also that in order to prevent running a given ISR concurrently or
> sequentially-before-it-has-completed, a combination of CPU masking of
> this-or-lower interrupts combined with the interrupt spin lock in the
> KINTERRUPT object is used.
>
>
>
> Personally, I would be interested if someone knows how to change =
interrupt
> priorities on a given device.
>
> =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
joe
>
>
>
>
>
>
>
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Skywing
> Sent: Friday, July 24, 2009 12:06 PM
>
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Question abuot masking interrupt
>
>
>
> That is the intention of the word “masked” in this particular =
instance.
>
> - S
>
>
>
>
> From: sivakumar thulasimani
> Sent: Friday, July 24, 2009 01:55
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Question abuot masking interrupt
>
> Being in any (X) IRQL does not mask any interrupts that are handled at =
a
> lower (Y)=A0IRQL. All the system does is it makes sure that your code =
which
is
> running at X IRQL will continue to run till it finished its function =
or
till
> it receives another interrupt which is handled by=A0at even higher =
IRQL. The
> interrupts for any lower (Y) IRQL are still “regisiterd” ( dont know =
the
> exact technical word here, so am using my own) and will be handled =
when
the
> IRQL is reduced to the appropriate level. Hope that clears your doubt
>
>
>
> rtshiva
>
> 2009/7/24
>
> I found this on wiki, seems answer my previous question:
> However, it is fairly easy for an edge triggered interrupt to be =
missed -
> for example if interrupts have to be masked for a period - and unless
there
> is some type of hardware latch that records the event it is impossible =
to
> recover. Such problems caused many “lockups” in early computer =
hardware
> because the processor did not know it was expected to do something. =
More
> modern hardware often has one or more interrupt status registers that
latch
> the interrupt requests; well written edge-driven interrupt software =
often
> checks such registers to ensure events are not missed.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@viatech.com.cn
> Sent: Friday, July 24, 2009 4:05 PM
> To: Windows System Software Devs Interest List
>
> Subject: RE: [ntdev] Question abuot masking interrupt
>
> Another question:
> If we mask the interrupt at and less than the interrupt currently
servicing,
> Is there any possibility that EDGE triggered lower prioprity interrupt
> LOST? (seems level trigged interrupt will not be lost).
>
> Thanks.
> HW
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@viatech.com.cn
> Sent: Friday, July 24, 2009 3:52 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Question abuot masking interrupt
>
> Hello everyone.
> I am a newbie in windows kernel and is now reading “windows internals” =
by
> Mark E. Russinovich, David A. Solomon.
> I have a question about masking interrupt.
> In chapter 3:
> The books saids:
> /*Quote begin
> interrupts from a source with an IRQL above the current level =
interrupt
the
> processor, whereas interrupts from sources with IRQLs equal to or =
below
the
> current level are masked until an executing thread lowers the IRQL.
> Quote end */
>
> Here is my question:
> Why bother masking the interrupts whose priority is lower than current
> interrupt level?
> The lower priority interrupt can’t preempt high priority interrupt per =
se.
> Does masking make any difference?
>
> Can anyone help me on this question? Thanks!
>
> Best regards,
> HW
>
> Email secured by Check Point at OSR.COM
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=3DListServer
>
>
> Email secured by Check Point at OSR.COM
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=3DListServer
>
>
> Email secured by Check Point at OSR.COM
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=3DListServer
>
>
> Email secured by Check Point at OSR.COM
>
> =3D — NTDEV is sponsored by OSR For our schedule of WDF, WDM, =
debugging
and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, =
visit
the
> List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=3DListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=3DListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=3DListServer
> –
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:=20
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=3DListServer
–=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.