Which way to go? QNX or Solaris?

QNX Newsgroups (Archives) qdn.public.qnxrtp.advocacy
21

InterruptAttachEvent() will tell kernel to queue and event (usually
pulse or signal) instead of calling interrupt handler function. You
receive that event using MsgReceive().

Oh, I see. I just can’t figure out how does it work with shared
interrupt lines.

Advantage is, there is no interrupt handler anymore, you only deal with
regular threads. They don’t run in kernel mode, which means better
protection. And they are schedulable according to OS priorities rather
than ‘hardware priorities’ of interrupt handlers.

That seems to be safe enough. But it delays interrupt response, doesn’t it?
Especially if your waiting-for-interrupt thread is not of the highest
priority.

Disadvantage is, danger of overloading kernel event queue. If you have a
runaway process at higher priority, queue won’t be drained, your devices
stop working and eventually you get into ‘Out of interrupt events’ mode.

But the microkernel should automatically unmask that interrupt whenever
it sends an event to the thread (because it doesn’t know how to clear it).
If the thread goes astray, it probably won’t unmask the interrupt.
The device surely will stop working (so will some other which share
the same interrupt) but at least OS won’t crash.

Wishful thinking. You can’t tell which ones are spurious. The
non-spurious ones become ‘spurious’ if you stop draining the queue.
Besides, you can’t block them even if you could tell because then your
hardware stops working.

Again, at least OS won’t crash.

Actually you don’t even have to understand OS too much > :wink:

I’ve seen horrible things done by people who think they don’t have to
understand the OS when writing drivers.

I didn’t say that understanding OS doesn’t help :wink:
Seriously, QNX is great on explaining QNX architecture.

SPARC Station 2 is like your grandma’s 20Mhz 386-SX or something of that
sort. I don’t think 1ms is bad for that hardware.

What about Ultra 1-167? They give 0.15ms for that one.

It sure is ! During the QNX-Russia-2002 Momentics IDE glitched a lot,
so we didn’t have a chance to see multithreaded debugging and such
things.
BTW, why on earth they decided to use java for Momentics IDE?

Because that was their only chance to get something workable sooner than
the return of the Christ.

Presumably working :wink:

PE is not really more expensive than development seat of Solaris when
you use Sun’s development tools (but of course, PE still uses GNU
toolchain, unlike Sun’s compiler which is much better than GCC).

It would help if you told what your project is. Since you talk about
DiskOnChip you sound like it is something embedded and perhaps resource
constrained. Solaris is not really goot fit for such hardware.

No, it’s not too resource constrained. DiskOnChips are quite large.
Mine is 32M, there are bigger.
In the current project (it’s in QNX4.25) i have single boarded
computer with P-III 500MHz and 128M RAM
We don’t use HDD because the system is supposed to be reliable
and robust.

22

“Dmitri Ivanov” <ivdal@yahoo.com> wrote in message
news:ane53a$l4j$1@inn.qnx.com…

But the microkernel should automatically unmask that interrupt whenever
it sends an event to the thread (because it doesn’t know how to clear it).
If the thread goes astray, it probably won’t unmask the interrupt.
The device surely will stop working (so will some other which share
the same interrupt) but at least OS won’t crash.

Maybe you should tell QSSL what microkernel should do :wink:

Wishful thinking. You can’t tell which ones are spurious. The
non-spurious ones become ‘spurious’ if you stop draining the queue.
Besides, you can’t block them even if you could tell because then your
hardware stops working.

Again, at least OS won’t crash.

I told you what happens. I did not make it up, it actually happens. Trouble
is, by the time you figure out that something is wrong with interrupts, it
is too late to do anything about it. Kernel is already choked and you can’t
disable interrupts anymore, because your code does not get to run anymore.
Kernel runs all the time and all it does is prints ‘Out of interrupt events’
message on the screen.

It could perhaps help if there was a way to set a ‘runtime limit’ on how
many events can be queued per process. There is no such thing currently.

What about Ultra 1-167? They give 0.15ms for that one.

So? You think Ultra-1/167 is very fast? :wink:
AFAIK, context switch on the SPARC is expensive. You can’t really compare
numbers directly between x86 and SPARC. In the end, Solaris will probably be
slower than QNX. So what? It has a lot more sophisticated kernel, that does
not come for free. Solaris does a very good job on latencies (compared to
other Unixes or Linux), given the level of complexity in the SVR4 Unix
kernel. Whether or not you need that sophistication is your decision.

No, it’s not too resource constrained. DiskOnChips are quite large.
Mine is 32M, there are bigger.
In the current project (it’s in QNX4.25) i have single boarded
computer with P-III 500MHz and 128M RAM
We don’t use HDD because the system is supposed to be reliable
and robust.

Using Solaris on a system without real hard drive is generally a bad idea.
It does not matter if your DiskOnChip is big, it is still a flash device,
with finite number of write cycles. Solaris will waste them on paging. There
is no way to disable paging completely in Solaris, you can only affect
probability of it by fine tuning kernel parameters. It is not really
designed for this kind of operation.

You will have hard time trying to even install it on a 32Mb drive. You will
need custom/manual installation and figuring minimal set of packages to
bring system up will be royal PITA. There are no tools or documentation to
support this task on X86. In my experience minimal size you can get by just
cutting off packages will be about 50Mb. Going below that will require more
serious surgery.

I think I have said enough on this subject :wink:
– igor

23

Kris Warkentin wrote:

Igor, I hope that you don’t go away, as your last note implies, because I
think a lot of people would miss having you around. You’re a valuable
resource both to the general public AND us qnx staff.

Yeah, I’d miss the old curmudgeon; although, I too, must admit a tiny
amount of wicked pleasure in his flaming :wink:

That’s my one and only statement on this thread.

24

Igor Kovalenko <kovalenko@attbi.com> wrote:

Disadvantage is, danger of overloading kernel event queue. If you have a
runaway process at higher priority, queue won’t be drained, your devices
stop working and eventually you get into ‘Out of interrupt events’ mode.

No, as the InterruptAttachEvent() docs say:

“To prevent infinite interrupt recursion, the kernel automatically
does an InterruptMask() for intr when delivering the event.”

Thus no further events will be generated until the thread that is
handling the event gets to run, and re-enables the the interrupt
by calling InterruptUnmask().

Although you like to sound like an authority on Solaris and QNX
driver development, it’s looking like you have little real driver
development experience, due to the lack of basic understanding that
you exhibit.

Your apparent expertise sounds particularly lame to someone who
has spent 2 years writing Solaris drivers for Sun Microsystems (I
wrote the elxl driver) and 4.5 years writing drivers for QSSL.

Perhaps you should post on slashdot instead: what you post does not
need to be accurate, but you’ll get the advantages of reaching a wider
audience, while not distracting QSSL staff.

Dave

25

On 3 Oct 2002 14:56:05 GMT, David Donohoe <ddonohoe@qnx.com> wrote:

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

Disadvantage is, danger of overloading kernel event queue. If you have a
runaway process at higher priority, queue won’t be drained, your devices
stop working and eventually you get into ‘Out of interrupt events’ mode.

No, as the InterruptAttachEvent() docs say:

“To prevent infinite interrupt recursion, the kernel automatically
does an InterruptMask() for intr when delivering the event.”

Thus no further events will be generated until the thread that is
handling the event gets to run, and re-enables the the interrupt
by calling InterruptUnmask().

Although you like to sound like an authority on Solaris and QNX
driver development, it’s looking like you have little real driver
development experience, due to the lack of basic understanding that
you exhibit.

Your apparent expertise sounds particularly lame to someone who
has spent 2 years writing Solaris drivers for Sun Microsystems (I
wrote the elxl driver) and 4.5 years writing drivers for QSSL.

Perhaps you should post on slashdot instead: what you post does not
need to be accurate, but you’ll get the advantages of reaching a wider
audience, while not distracting QSSL staff.

Dave

C’mon Dave, play the ball not the man…

26

“David Donohoe” <ddonohoe@qnx.com> wrote in message
news:anhlq5$nd4$1@nntp.qnx.com…

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

Disadvantage is, danger of overloading kernel event queue. If you have a
runaway process at higher priority, queue won’t be drained, your devices
stop working and eventually you get into ‘Out of interrupt events’ mode.

No, as the InterruptAttachEvent() docs say:

“To prevent infinite interrupt recursion, the kernel automatically
does an InterruptMask() for intr when delivering the event.”

Thus no further events will be generated until the thread that is
handling the event gets to run, and re-enables the the interrupt
by calling InterruptUnmask().

Guess I have been Donohoe’d. Someone, send me a T-shirt…

Although you like to sound like an authority on Solaris and QNX
driver development, it’s looking like you have little real driver
development experience, due to the lack of basic understanding that
you exhibit.

Where exactly did I say that I have ANY experience with Solaris driver
development? Dare ya to quote me. I do have application development
experience on Solaris and I did lot of work on custom installations. I do
have all kinds of experiences with QNX. Now, I did make a wrong assumption
about the InterruptAttachEvent(), based on the things I have seen. That will
teach me.

Your apparent expertise sounds particularly lame to someone who
has spent 2 years writing Solaris drivers for Sun Microsystems (I
wrote the elxl driver) and 4.5 years writing drivers for QSSL.

As someone with such extensive background in both systems you should have
been the first one talking in this thread. So far however your contribution
is limited mostly to explaining everyone my lameness. It is very easy to sit
and watch someone talking, waiting until one makes a mistake. Then our hero
comes out and strikes. Everyone applauds… the hero goes back to watch.

Perhaps you should post on slashdot instead: what you post does not
need to be accurate, but you’ll get the advantages of reaching a wider
audience, while not distracting QSSL staff.

I am so sorry for distracting you. That won’t happen again.

– igor

27

“Igor Kovalenko” <kovalenko@attbi.com> wrote in message
news:ani48a$l00$1@inn.qnx.com…

“David Donohoe” <> ddonohoe@qnx.com> > wrote in message
Perhaps you should post on slashdot instead: what you post does not
need to be accurate, but you’ll get the advantages of reaching a wider
audience, while not distracting QSSL staff.


I am so sorry for distracting you. That won’t happen again.

Lord knows I’m a fool for getting in the middle of this but I think that
it’s unfair to characterize Igor as the type of person who tries to appear
knowledgeable just to hear himself talk. While he’s sometimes abrasive, (I
admit a certain guilty pleasure in seeing him get flamed :wink: I believe that
his posts are generally accurate to the best of his ability and that he’s
generally trying to contribute and help. He may have been mistaken this
time but I’m willing to bet that it doesn’t happen that often.

Igor, I hope that you don’t go away, as your last note implies, because I
think a lot of people would miss having you around. You’re a valuable
resource both to the general public AND us qnx staff.

cheers,

Kris

28

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:ani637$du8$1@nntp.qnx.com…

“Igor Kovalenko” <> kovalenko@attbi.com> > wrote in message
news:ani48a$l00$> 1@inn.qnx.com> …
“David Donohoe” <> ddonohoe@qnx.com> > wrote in message
Perhaps you should post on slashdot instead: what you post does not
need to be accurate, but you’ll get the advantages of reaching a wider
audience, while not distracting QSSL staff.


I am so sorry for distracting you. That won’t happen again.

Lord knows I’m a fool for getting in the middle of this but I think that
it’s unfair to characterize Igor as the type of person who tries to appear
knowledgeable just to hear himself talk. While he’s sometimes abrasive,
(I
admit a certain guilty pleasure in seeing him get flamed > :wink: > I believe
that
his posts are generally accurate to the best of his ability and that he’s
generally trying to contribute and help. He may have been mistaken this
time but I’m willing to bet that it doesn’t happen that often.

Igor, I hope that you don’t go away, as your last note implies, because I
think a lot of people would miss having you around. You’re a valuable
resource both to the general public AND us qnx staff.

Eh, thank you Kris.
On a second thought, this is .advocacy group after all. Perhaps we don’t
have to care here if QNX staff is distracted :wink:

29

Igor Kovalenko <kovalenko@attbi.com> wrote:
: “David Donohoe” <ddonohoe@qnx.com> wrote in message
: news:anhlq5$nd4$1@nntp.qnx.com…
:> Igor Kovalenko <kovalenko@attbi.com> wrote:
:>
:> > Disadvantage is, danger of overloading kernel event queue. If you have a
:> > runaway process at higher priority, queue won’t be drained, your devices
:> > stop working and eventually you get into ‘Out of interrupt events’ mode.
:>
:> No, as the InterruptAttachEvent() docs say:
:>
:> “To prevent infinite interrupt recursion, the kernel automatically
:> does an InterruptMask() for intr when delivering the event.”
:>
:> Thus no further events will be generated until the thread that is
:> handling the event gets to run, and re-enables the the interrupt
:> by calling InterruptUnmask().

: Guess I have been Donohoe’d. Someone, send me a T-shirt…

:sunglasses: sweet :sunglasses:

…

: As someone with such extensive background in both systems you should have
: been the first one talking in this thread. So far however your contribution
: is limited mostly to explaining everyone my lameness. It is very easy to sit
: and watch someone talking, waiting until one makes a mistake. Then our hero
: comes out and strikes. Everyone applauds… the hero goes back to watch.

:> Perhaps you should post on slashdot instead: what you post does not
:> need to be accurate, but you’ll get the advantages of reaching a wider
:> audience, while not distracting QSSL staff.
:>

: I am so sorry for distracting you. That won’t happen again.

Hello! This is an advocacy group :sunglasses:

30

Eh, thank you Kris.
On a second thought, this is .advocacy group after all. Perhaps we don’t
have to care here if QNX staff is distracted > :wink:

That is what I was going to say. This is the area where the gloves
come off. Check your feelings at the door. :wink:

chris

\

Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

31

Hey! Igor seems to be the only one who was helpful on the subject!
He gave me a good overview, so what if some details were wrong?
I can always look up in the docs. After all, who can remember
every detail on every platform? (except OS developers, maybe).
Many thanks, Igor. I really appreciate your following.

Although you like to sound like an authority on Solaris and QNX
driver development, it’s looking like you have little real driver
development experience, due to the lack of basic understanding that
you exhibit.

Your apparent expertise sounds particularly lame to someone who
has spent 2 years writing Solaris drivers for Sun Microsystems (I
wrote the elxl driver) and 4.5 years writing drivers for QSSL.

Perhaps you should post on slashdot instead: what you post does not
need to be accurate, but you’ll get the advantages of reaching a wider
audience, while not distracting QSSL staff.

Dave

32

“Chris McKillop” <cdm@qnx.com> wrote in message
news:anikb4$lv$1@nntp.qnx.com…

Eh, thank you Kris.
On a second thought, this is .advocacy group after all. Perhaps we don’t
have to care here if QNX staff is distracted > :wink:


That is what I was going to say. This is the area where the gloves
come off. Check your feelings at the door. > :wink:

I agree 125%. Personnaly I view this group as the only were we can
speak our mind. Obviously QNX staffer don’t have total freedom in
that regard because they represent QSS. Plus there is ALWAYS
more then meets the eyes. I tend to beleive coins have more then
2 sides (making reference to the “other side of the coin” expression)
That being said I welcome David’s post on the ground that he said
it like he felt it, that’s good. Same for Igor.

However unlike Chris I would say don’t leave your feeling at the door, bring
them in, make yourself vulnerable. There is so much to learn.

Curiously it seems humans grow/evolve the fastest when pain and suffering is
involved ;-|



chris

\

Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

33

Chris McKillop wrote:

Igor Levko <> spama@nihrena.net> > wrote:

Let’s get back to the source. Igor’s original statement was
“That manifests itself as system not doing anything except for spitting ‘Out
of interrupt events’ on the
screen continuously. The end result is, you have to reset it. It is as good
as a crash.”



As far as I can tell, this is only going to happen when you use
InterruptAttach() and your ISR does not call InterruptMask() before returning
the the event to the thread. In this case the ISR will continue to fire,
and depending on timings, the handling thread may never get to run. This is
a bug in the driver. And just shows that igor’s original statement, that when
you touch hardware there is no “crash proof”, to be true. Just happens that
QNX is 10x better at managing the cases where the hardware isn’t screwed up
(null pointer reference).

QNX (at least QNX4) seems to just be better at protection, even when
comparing process to process (i.e. not even considering the in-kernel
driver case). At the last company I worked at, a developer wrote and
“debugged” a program on his NT workstation, that I was to incorporate
into a controller with no MMU. His code had a test scaffold built-in,
and, as per our SOP, I compiled and ran it on QNX4, just before
incorporating it into the controller (for FDA doc purposes). It
SIGSEGV’d immediately. The same code executed without error on NT.

I quickly re-ran it inside the debugger, and sure enough there an
invalid (not null) pointer de-reference (which, incidentally, was in the
test scaffold and not any of the code to be incorporated into the
controller).

There are probably many reasons that NT didn’t catch it (some of which
could be simple luck-of-the-draw - i.e. the value of the invalid
reference), but I have never had the opposite situation occur (i.e. NT
catch a bug in QNX code, that wasn’t caught by QNX). I suspect that NT
provides a lot more “slack” backed VM to a process than QNX does.

34

Let’s get back to the source. Igor’s original statement was
“That manifests itself as system not doing anything except for spitting ‘Out
of interrupt events’ on the
screen continuously. The end result is, you have to reset it. It is as good
as a crash.”

As far as I can see now igor’s explanation of the origin of this problem
was not correct.
Obviously Donohoe’s intention was not to explain it but rather tell us how
cool he is
and give some analysis of igor’s personality. That was really lame.

Anyway, can anybody care to explain it, or at least point to some docs ?

cheers,
Igor

“Kris Warkentin” <kewarken@qnx.com> wrote in message
news:ani637$du8$1@nntp.qnx.com…

“Igor Kovalenko” <> kovalenko@attbi.com> > wrote in message
news:ani48a$l00$> 1@inn.qnx.com> …
“David Donohoe” <> ddonohoe@qnx.com> > wrote in message
Perhaps you should post on slashdot instead: what you post does not
need to be accurate, but you’ll get the advantages of reaching a wider
audience, while not distracting QSSL staff.


I am so sorry for distracting you. That won’t happen again.

Lord knows I’m a fool for getting in the middle of this but I think that
it’s unfair to characterize Igor as the type of person who tries to appear
knowledgeable just to hear himself talk. While he’s sometimes abrasive,
(I
admit a certain guilty pleasure in seeing him get flamed > :wink: > I believe
that
his posts are generally accurate to the best of his ability and that he’s
generally trying to contribute and help. He may have been mistaken this
time but I’m willing to bet that it doesn’t happen that often.

Igor, I hope that you don’t go away, as your last note implies, because I
think a lot of people would miss having you around. You’re a valuable
resource both to the general public AND us qnx staff.

cheers,

Kris

35

Igor Levko <spama@nihrena.net> wrote:

Let’s get back to the source. Igor’s original statement was
“That manifests itself as system not doing anything except for spitting ‘Out
of interrupt events’ on the
screen continuously. The end result is, you have to reset it. It is as good
as a crash.”

As far as I can tell, this is only going to happen when you use
InterruptAttach() and your ISR does not call InterruptMask() before returning
the the event to the thread. In this case the ISR will continue to fire,
and depending on timings, the handling thread may never get to run. This is
a bug in the driver. And just shows that igor’s original statement, that when
you touch hardware there is no “crash proof”, to be true. Just happens that
QNX is 10x better at managing the cases where the hardware isn’t screwed up
(null pointer reference).

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

36

I believe our case was different. All the drivers normally worked fine.
However occasional bugs in some drivers caused them to crash (SEGV).
That’s where the ‘out of interrupt events’ came up, because there
apparently is a window for a driver to crash when the interrupt is not
masked (sorry, I am speculating again).

This whole story makes me wonder if the kernel could not mask the
interrupt before killing a SEGVed process that has interrupt handler
attached… Could it? Good opportunity for the heroes to strike! :slight_smile:

– igor

Chris McKillop wrote:

Igor Levko <> spama@nihrena.net> > wrote:

Let’s get back to the source. Igor’s original statement was
“That manifests itself as system not doing anything except for spitting ‘Out
of interrupt events’ on the
screen continuously. The end result is, you have to reset it. It is as good
as a crash.”



As far as I can tell, this is only going to happen when you use
InterruptAttach() and your ISR does not call InterruptMask() before returning
the the event to the thread. In this case the ISR will continue to fire,
and depending on timings, the handling thread may never get to run. This is
a bug in the driver. And just shows that igor’s original statement, that when
you touch hardware there is no “crash proof”, to be true. Just happens that
QNX is 10x better at managing the cases where the hardware isn’t screwed up
(null pointer reference).

chris

37

All of our drivers should be using the proper flag values to have the
mask/unmask states track by the kernel. I know all the ones I have worked
on have done so. Have you actually seen this recently igor or was it with
an older procnto?

chris


Igor Kovalenko <kovalenko@attbi.com> wrote:

I believe our case was different. All the drivers normally worked fine.
However occasional bugs in some drivers caused them to crash (SEGV).
That’s where the ‘out of interrupt events’ came up, because there
apparently is a window for a driver to crash when the interrupt is not
masked (sorry, I am speculating again).

This whole story makes me wonder if the kernel could not mask the
interrupt before killing a SEGVed process that has interrupt handler
attached… Could it? Good opportunity for the heroes to strike! > :slight_smile:

– igor

Chris McKillop wrote:
Igor Levko <> spama@nihrena.net> > wrote:

Let’s get back to the source. Igor’s original statement was
“That manifests itself as system not doing anything except for spitting ‘Out
of interrupt events’ on the
screen continuously. The end result is, you have to reset it. It is as good
as a crash.”



As far as I can tell, this is only going to happen when you use
InterruptAttach() and your ISR does not call InterruptMask() before returning
the the event to the thread. In this case the ISR will continue to fire,
and depending on timings, the handling thread may never get to run. This is
a bug in the driver. And just shows that igor’s original statement, that when
you touch hardware there is no “crash proof”, to be true. Just happens that
QNX is 10x better at managing the cases where the hardware isn’t screwed up
(null pointer reference).

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

38

The most recent case I believe was few month back. We are not talking
about your drivers only, there are 3rd party drivers involved (T1/E1
communication, DSPs, etc). They could not be using proper flags…

What are those proper flags anyway? The _NTO_INTR_FLAGS_TRK_MSK has
somewhat vague description. It is not clear that it will do what you
seem to imply - it talks about what happens when a shared interrupt is
detached. I am not sure driver dying is the same as interrupt detaching,
is it? And we’re not talking about shared interrupts …

– igor

Chris McKillop wrote:

All of our drivers should be using the proper flag values to have the
mask/unmask states track by the kernel. I know all the ones I have worked
on have done so. Have you actually seen this recently igor or was it with
an older procnto?

chris


Igor Kovalenko <> kovalenko@attbi.com> > wrote:

I believe our case was different. All the drivers normally worked fine.
However occasional bugs in some drivers caused them to crash (SEGV).
That’s where the ‘out of interrupt events’ came up, because there
apparently is a window for a driver to crash when the interrupt is not
masked (sorry, I am speculating again).

This whole story makes me wonder if the kernel could not mask the
interrupt before killing a SEGVed process that has interrupt handler
attached… Could it? Good opportunity for the heroes to strike! > :slight_smile:

– igor

Chris McKillop wrote:

Igor Levko <> spama@nihrena.net> > wrote:


Let’s get back to the source. Igor’s original statement was
“That manifests itself as system not doing anything except for spitting ‘Out
of interrupt events’ on the
screen continuously. The end result is, you have to reset it. It is as good
as a crash.”



As far as I can tell, this is only going to happen when you use
InterruptAttach() and your ISR does not call InterruptMask() before returning
the the event to the thread. In this case the ISR will continue to fire,
and depending on timings, the handling thread may never get to run. This is
a bug in the driver. And just shows that igor’s original statement, that when
you touch hardware there is no “crash proof”, to be true. Just happens that
QNX is 10x better at managing the cases where the hardware isn’t screwed up
(null pointer reference).

chris

39

Igor Kovalenko <kovalenko@attbi.com> wrote:

The most recent case I believe was few month back. We are not talking
about your drivers only, there are 3rd party drivers involved (T1/E1
communication, DSPs, etc). They could not be using proper flags…

Or they could be assuming the interrupt is masked for them. Are they
using InterruptAttach() or InterruptAttachEvent()?

What are those proper flags anyway? The _NTO_INTR_FLAGS_TRK_MSK has
somewhat vague description. It is not clear that it will do what you
seem to imply - it talks about what happens when a shared interrupt is
detached. I am not sure driver dying is the same as interrupt detaching,
is it? And we’re not talking about shared interrupts …

My understanding is if you use that flag it will do reference counts for
masking and unmasking. If you don’t use it then the kernel assumes you know
what you are doing and does what you ask. Might not be possible to get into
the state you are talking about with/without this flag, but I am always
warry of things not doing things right.

chris

–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/

40

They are using InterruptAttach().

I’d appreciate a definitive answer whether or not using
_NTO_INTR_FLAGS_TRK_MSK will prevent ‘out of interrupt’ events if such a
driver dies before masking interrupt (whether shared or not).

– igor

Chris McKillop wrote:

Igor Kovalenko <> kovalenko@attbi.com> > wrote:

The most recent case I believe was few month back. We are not talking
about your drivers only, there are 3rd party drivers involved (T1/E1
communication, DSPs, etc). They could not be using proper flags…



Or they could be assuming the interrupt is masked for them. Are they
using InterruptAttach() or InterruptAttachEvent()?


What are those proper flags anyway? The _NTO_INTR_FLAGS_TRK_MSK has
somewhat vague description. It is not clear that it will do what you
seem to imply - it talks about what happens when a shared interrupt is
detached. I am not sure driver dying is the same as interrupt detaching,
is it? And we’re not talking about shared interrupts …



My understanding is if you use that flag it will do reference counts for
masking and unmasking. If you don’t use it then the kernel assumes you know
what you are doing and does what you ask. Might not be possible to get into
the state you are talking about with/without this flag, but I am always
warry of things not doing things right.

chris