There are 2 levels of interrupt service routine. The first is the actual
interrupt service routine that must turn off the reason for the interrupt.
This routine then calls interrupt_queue to queue the interrupt to io-pkt.
io-pkt then calls your second level interrupt service routine which handles
the interrupt processing eg. receive a message. This routine must then
return a positive value to io-pkt to indicate that the interrupt has been
handled.


On 11-03-01 6:18 PM, "John Pruitt" <community-noreply@qnx.com> wrote:

> I have an ethernet driver for a new arm Cortex A8 part and without the
> interrupts, the driver works pretty well. I added a callout function to "poll"
> for the received buffers. With this, I can use qconn to download and debug a
> program, turn on kernel instrumentation and upload the data etc. It seems to
> work like it is supposed to.
> 
> If I turn on interrupts, I lose everything. The serial port completely locks
> up and I have to reboot the system. I am assuming the interrupt handler is
> doing something it is not supposed but it is just a guess.
> 
> I modeled my driver after the source for a devnp driver for a different part.
> I tried to keep the qnx things the same but I probably missed something.
> 
> The interrupt driver does not do much but I am wondering what the significance
> of all the entries in nicinfo_t are. Is this explained in any documentation?
> In particular, what is the use of io_windows and mem_windows? The driver I
> used as a template used io_windows but did not use mem_windows. Maybe I need
> to but a manual would be nice.
> 
> Is there any documentation for the calls like interrupt_queue?
> 
> Thanks.
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post83667
> 
> 

-- 
Hugh Brown                      (613) 591-0931 ext. 2209 (voice)
QNX Software Systems Ltd.        (613) 591-3579           (fax)
175 Terence Matthews Cres.       email:  hsbrown@qnx.com
Kanata, Ontario, Canada.
K2M 1W8