Better still …
// Method One would go something like this:
//===========================================
ThreadCtl(_NTO_TCTL_IO, 0);
prioritystageone = sched_get_priority_max(); // After ThreadCtl to ensure
// top priority.
InterruptAttachEvent( SIGEV_INTR );
while()
{
set_thread_priority( prioritystageone );
unmask_device(); // Must be inside the top priority stage to prevent
// an extended IRQ masking.
do {
InterruptWait();
} until( device_pending() ); // Don’t do anything if it wasn’t my device,
// some other driver will do the IRQ unmask.
mask_device();
InterruptUnmask();
set_thread_priority( prioritystagetwo ); // Preferred priority of the
// handler.
do_the_device_level_work();
}
InterruptDetach();
//===========================================
The time waster here is the required number of context switches to run through all the drivers (Not likely to be more than three luckily) triggered by the one event. Each driver, in turn, checking it’s device and either doing nothing more or lowering it’s priority. Both options letting the next driver have a look.
Best case scenario is if there is only one driver on the IRQ and it’s lowered priority is still the top one ready at the time - making for no further context switch?
Evan
Crap. I just noticed that method is flawed too but I can’t see any better way. 
If two devices are needing service then the first driver to unmask the IRQ will immediately cause a second event because the second device is still holding the interrupt line active.
The result is a second round of checks get triggered even though the devices in question will be masked and in-the-pipe for processing. This doesn’t cause lost data just more CPU usage and an even longer response time.
Evan
Okay, using an ISR does the job correctly so the driver could have a parameter for specifying from the command line which variant to use. Something a bit like the following:
NOTE: If there is no thread that IAE()'s an IRQ then the kernel never masks that IRQ.
//=======================================================
ISR_Handler() // Only used if sharing is specified to be used.
{
if( device_pending() )
{
mask_device();
return( SIGEV_INTR );
}
return( NULL );
}
Interrupt_Handler_Thread()
{
ThreadCtl(_NTO_TCTL_IO, 0);
if( optionsharing == TRUE ) InterruptAttach( &ISR_handler );
else InterruptAttachEvent( SIGEV_INTR );
unmask_device();
InterruptUnmask();
while()
{
if( optionsharing == TRUE ) unmask_device();
else InterruptUnmask();
InterruptWait();
do_the_device_level_work();
}
mask_device();
InterruptDetach();
}
//=======================================================
Cheers,
Evan
And the rocket nozzles we’ll make out of wood because nobody will read this
far anyway.
– igor
“Evan Hillas” <evanh@clear.net.nz> wrote in message
news:d97d2n$83k$1@inn.qnx.com…
Okay, using an ISR does the job correctly so the driver could have a
parameter for specifying from the command line which variant to use.
Something a bit like the following:
NOTE: If there is no thread that IAE()'s an IRQ then the kernel never
masks that IRQ.
//=======================================================
ISR_Handler() // Only used if sharing is specified to be used.
{
if( device_pending() )
{
mask_device();
return( SIGEV_INTR );
}
return( NULL );
}
Interrupt_Handler_Thread()
{
ThreadCtl(_NTO_TCTL_IO, 0);
if( optionsharing == TRUE ) InterruptAttach( &ISR_handler );
else InterruptAttachEvent( SIGEV_INTR );
unmask_device();
InterruptUnmask();
while()
{
if( optionsharing == TRUE ) unmask_device();
else InterruptUnmask();
InterruptWait();
do_the_device_level_work();
}
mask_device();
InterruptDetach();
}
//=======================================================
Cheers,
Evan
Igor Kovalenko wrote:
And the rocket nozzles we’ll make out of wood because nobody will read this
far anyway.
I think I’d be a tad bit offended if the dudes that go to work on PR 25810 don’t have a look. And I’m not keen on posting a separate summary either.
Evan
“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:d913u4$j1m$1@inn.qnx.com…
Wojtek Lerch wrote:
“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:d8u5ka$cqf$> 1@inn.qnx.com> …
[ clip …]
So you’re basically saying that it’s wrong for a realtime OS to allow
you to decide that there’s something in your system that needs to be
done so urgently, and can be done so quickly, that you want to let it
pre-empt the handling of a carefully chosen set of interrupts? And the
only reason you think it should be forbidden is becasue it allows you to
mess up your system by assigning the priorities incorrectly?
The problem is that there are absolutely no guidlines for assigning the
priorities!
Guidelines are good if you can’t, or don’t want to, have full knowledge or
full control of all that’s going on in your system. For instance, when
other people write software that you want to be able to just drop into your
system and trust that it’ll set up the priorities of its threads more or
less correctly, without you having to tweak its parameters
by hand. This is important in a desktop system.
In an embeded realtime system, I imagine it’s more common that you want to
analyze the timing requirements of all the pieces and assign all the
priorities by hand. In such cases, you care less about guidelines and more
about knowing about the various requierements and being able to adjust
priorities the way you decide is best.
“Priorities of application threads should not be higher than the lowest
priority assigned to an interrupt thread” … could one of theses
Guidlines.
It’s OK for some devices and some drivers to be pre-empted by application
threads. Isn’t it common for some ancient hardware to have a status bit
that you have to check continuously in a busy loop until it tells you that
the device is ready to talk to you? Wouldn’t it be reasonable to run the
busy loop at the priority of the application using the device, even in the
busy loop is part of interrupt handling?
Evan Hillas wrote:
Igor Kovalenko wrote:
And the rocket nozzles we’ll make out of wood because nobody will read
this far anyway.
> I think I’d be a tad bit offended if the dudes that go to work on PR
25810 don’t have a look. And I’m not keen on posting a separate summary
either.
I mean the idea of reducing the IRQ masking duration of the network drivers without properly supporting sharing is kind of pointless. They may as well not bother and just declare QNX as not supporting IRQ sharing unless you write your own drivers.
Evan
Wojtek Lerch wrote:
“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:d913u4$j1m$> 1@inn.qnx.com> …
Wojtek Lerch wrote:
“Armin Steinhoff” <> a-steinhoff@web.de> > wrote in message
news:d8u5ka$cqf$> 1@inn.qnx.com> …
[ clip …]
So you’re basically saying that it’s wrong for a realtime OS to allow
you to decide that there’s something in your system that needs to be
done so urgently, and can be done so quickly, that you want to let it
pre-empt the handling of a carefully chosen set of interrupts? And the
only reason you think it should be forbidden is becasue it allows you to
mess up your system by assigning the priorities incorrectly?
The problem is that there are absolutely no guidlines for assigning the
priorities!
Guidelines are good if you can’t, or don’t want to, have full knowledge or
full control of all that’s going on in your system. For instance, when
other people write software that you want to be able to just drop into your
system and trust that it’ll set up the priorities of its threads more or
less correctly, without you having to tweak its parameters
by hand. This is important in a desktop system.
I don’t believe that you understand the value of such a guidline.
Other operating systems have such …
In an embeded realtime system, I imagine it’s more common that you want to
analyze the timing requirements of all the pieces and assign all the
priorities by hand. In such cases, you care less about guidelines and more
about knowing about the various requierements and being able to adjust
priorities the way you decide is best.
“Priorities of application threads should not be higher than the lowest
priority assigned to an interrupt thread” … could one of theses
Guidlines.
It’s OK for some devices and some drivers to be pre-empted by application
threads. Isn’t it common for some ancient hardware to have a status bit
that you have to check continuously in a busy loop until it tells you that
the device is ready to talk to you?
No … that’s absolutely not common! Such hardware interfaces are realy
crappy.
Wouldn’t it be reasonable to run the
busy loop at the priority of the application using the device, even in the
busy loop is part of interrupt handling?
That’s realy weired … a busy loop as part of interrupt handling ???
–Armin
Evan Hillas wrote:
Igor Kovalenko wrote:
And the rocket nozzles we’ll make out of wood because nobody will read
this far anyway.
> I think I’d be a tad bit offended if the dudes that go to work on PR
25810 don’t have a look. And I’m not keen on posting a separate summary
either.
Evan
The PR has been updated with both your and Rennie’s suggestions. (Worst
case it’ll be wet mahogany intead of dry birch! )
Out of curiosity, which network driver(s) are you using? I might be
able to prioritize which ones we look at first…
Robert.
Robert Craig wrote:
The PR has been updated with both your and Rennie’s suggestions. (Worst
case it’ll be wet mahogany intead of dry birch! > > )
Thanks heaps.
Out of curiosity, which network driver(s) are you using? I might be
able to prioritize which ones we look at first…
None. In fact network drivers weren’t my personal biggest concern since any network support would be a bonus to our future designs - maybe providing stats for management. This is not directly/immediately for my benefit. I’m a NC user only atm and lucky to have very little hardware active on this box.
To me, it’s less about careful hardware choice and configuration and more about just getting it going. I’d love to be able to use what’s available locally hardware wise and I don’t want to have to purchase the source code for a driver and add modifications just so it won’t conflict with an unrelated neighbouring driver. Then, the next time the hardware is rearranged, oh damn it’s a different set conflicting this time.
And what was that about planning for inevitable future supply changes?
Evan
“Armin Steinhoff” <a-steinhoff@web.de> wrote in message
news:d996em$im7$1@inn.qnx.com…
Wojtek Lerch wrote:
Guidelines are good if you can’t, or don’t want to, have full knowledge
or full control of all that’s going on in your system. For instance,
when other people write software that you want to be able to just drop
into your system and trust that it’ll set up the priorities of its
threads more or less correctly, without you having to tweak its
parameters
by hand. This is important in a desktop system.
I don’t believe that you understand the value of such a guidline.
That’s quite possible.
“Priorities of application threads should not be higher than the lowest
priority assigned to an interrupt thread” … could one of theses
Guidlines.
It’s OK for some devices and some drivers to be pre-empted by application
threads. Isn’t it common for some ancient hardware to have a status bit
that you have to check continuously in a busy loop until it tells you
that the device is ready to talk to you?
No … that’s absolutely not common! Such hardware interfaces are realy
crappy.
I didn’t say they aren’t crappy. Isn’t it common for ancient hardware to be
crappy?
The first two ancient disk controller designs I’ve found some docs on (the
floppy and ATA) have bits like that that you have to check, for instance
while programming a write command into the controller. When you’re writing
multiple sectors from a cache, you’ll need to issue a new write command when
an interrupt tells you that the previous one has completed. Assuming it’s
done in a thread rather than in an ISR, would you call the thread an
“interrupt thread” or an “application thread”?
Wouldn’t it be reasonable to run the
busy loop at the priority of the application using the device, even in
the busy loop is part of interrupt handling?
That’s realy weired … a busy loop as part of interrupt handling ???
Sure, if the device guarantees to let you out of the loop within a
reasonable amount of time, that should be fine, shouldn’t it?
Besides, InterruptLock() has a busy loop in it, too, and it’s meant to be
used with interrupts.
Evan Hillas wrote:
Robert Craig wrote:
Out of curiosity, which network driver(s) are you using? I might be
able to prioritize which ones we look at first…
This PC is using a RT8139A, it’s nice and common so I’m not worried. Thanks for the offer though.
And what was that about planning for inevitable future supply changes?
Re-reading it, that could have been worded better. It wasn’t meant as a question, rather a reminder of common design sense.
Evan
Robert Craig wrote:
Out of curiosity, which network driver(s) are you using? I might be
able to prioritize which ones we look at first…
We use devn-i82544.so and devn-speedo.so on cPCI Pentium 3 / Pentium 4 /
Pentium M PC cards.
Each card has 2 network adapters (and sometimes we have to use 3 of
them) in addition to our custum-made device cards: sharing IRQs with
network drivers is not avoidable, and networking (both tcp/ip and qnet)
is hardly used in our application.
Davide
–
/* Ancri Davide - */
“Evan Hillas” <evanh@clear.net.nz> wrote in message
news:d992cm$fn8$1@inn.qnx.com…
Evan Hillas wrote:
Igor Kovalenko wrote:
And the rocket nozzles we’ll make out of wood because nobody will read
this far anyway.
> I think I’d be a tad bit offended if the dudes that go to work on PR
25810 don’t have a look. And I’m not keen on posting a separate summary
either.
I mean the idea of reducing the IRQ masking duration of the network
drivers without properly supporting sharing is kind of pointless. They
may as well not bother and just declare QNX as not supporting IRQ sharing
unless you write your own drivers.
They may as well not bother and declare QNX not supporting PCI spec
properly. Because it really does not.
Anyway, who cares about ethernet on QNX… as a packet router Linux will
beat it easily even though it isn’t quite realtime.
– igor
Igor Kovalenko <kovalenko@comcast.net> wrote:
Anyway, who cares about ethernet on QNX… as a packet router Linux will
beat it easily even though it isn’t quite realtime.
– igor
That’s not quite fair. We actually do quite well in forwarding
benchmarks. Granted seeing all the potential means twidling
some defaults but this is changing.
See http://www.qnx.com/download/feature.html?programid=8082
-seanb
“Sean Boudreau” <seanb@qnx.com> wrote in message
news:d9fl0b$ern$1@inn.qnx.com…
Igor Kovalenko <> kovalenko@comcast.net> > wrote:
Anyway, who cares about ethernet on QNX… as a packet router Linux will
beat it easily even though it isn’t quite realtime.
– igor
That’s not quite fair. We actually do quite well in forwarding
benchmarks. Granted seeing all the potential means twidling
some defaults but this is changing.
See > http://www.qnx.com/download/feature.html?programid=8082
Let me know when you think things have changed enough. I can do another test
– igor
Robert Craig wrote:
Out of curiosity, which network driver(s) are you using? I might be
able to prioritize which ones we look at first…
Hi all…
Any good news about InterruptAttachEvent() issues on hardly-used network
drivers?
Davide
–
/* Ancri Davide - */
Davide Ancri wrote:
Any good news about InterruptAttachEvent() issues on hardly-used network
drivers?
I’d think any global changes will be some years away. It’s a design flaw rather than a bug so evaluation will be while. Individually hacking each driver is the fix for the time being.
Evan
Evan Hillas wrote:
I’d think any global changes will be some years away. It’s a design
flaw rather than a bug so evaluation will be while. Individually
hacking each driver is the fix for the time being.
My question wants to say something like “Hey QNX guys! Some good news
about abandoning InterruptAttachEvent() into ethernet Gigabit/100Mb
Intel drivers for x86?”
Davide
–
/* Ancri Davide - */