Problems with interrupts on a PPC

[John]

Working on LynxOS 4.0 on a PPC.

My device driver ISR is being hit as soon as I start an I/O even
though the I/O did not complete (nothing connected to the device).

I initialize the ISR during driver initialization

next_interrupt_vector = drm_register_isr(handle, MyISR, context);

In MyIsr I do,

int MyISR (void *context)
{
process_interrupt();
kkprintf("MyISR\n");
ioint_link(next_interrupt_vector);
kkprintf("Leaving MyISR\n");
return 0;
}

the value of next_interrupt_vector is a zero when printed. Should I
check for that before calling ioint_link()?
When I start an output, for example, my print statements in MyISR are
constantly being displayed.
Why is my interrupt service being called by the system?
Am I not initializing my ISR correctly?

[John]

I have more information.

MyISR performs an ssignal to wake up a thread to process the interrupt
The thread will acknowledge the interrupt once it starts. I think
(newbie here) the problem is that since the interrupt has not been
acknowledge the system generates another interrupt. The thread never
awakes because the OS is busy generating the interrupt that I have not
processed.

Does this sound like what might be happening. MyISR is constantly
being call because the interrupt is still be generated by the device.
should I acknowledge the interrupt in the interrupt context?

[Steve Watt]

In article <8lvp645i0a507051m...@4ax.com>,

John <jvas...@cox.net> wrote:
>On Thu, 03 Jul 2008 08:17:24 -0700, John <jvas...@cox.net> wrote:
>
>>Working on LynxOS 4.0 on a PPC.
>>
>>My device driver ISR is being hit as soon as I start an I/O even
>>though the I/O did not complete (nothing connected to the device).
>>
>>I initialize the ISR during driver initialization
>>
>>next_interrupt_vector = drm_register_isr(handle, MyISR, context);
>>
>>In MyIsr I do,
>>
>>int MyISR (void *context)
>>{
>> process_interrupt();
>> kkprintf("MyISR\n");
>> ioint_link(next_interrupt_vector);
>> kkprintf("Leaving MyISR\n");
>> return 0;
>>}
>>
>>the value of next_interrupt_vector is a zero when printed. Should I
>>check for that before calling ioint_link()?
>>When I start an output, for example, my print statements in MyISR are
>>constantly being displayed.
>>Why is my interrupt service being called by the system?
>>Am I not initializing my ISR correctly?

Remember that other device drivers may share the interrupt vector
with yours. Inside your ISR, you need to check to make sure the
interrupt came from your device before you take action.

>MyISR performs an ssignal to wake up a thread to process the interrupt
>The thread will acknowledge the interrupt once it starts. I think
>(newbie here) the problem is that since the interrupt has not been
>acknowledge the system generates another interrupt. The thread never
>awakes because the OS is busy generating the interrupt that I have not
>processed.
>
>Does this sound like what might be happening. MyISR is constantly
>being call because the interrupt is still be generated by the device.
>should I acknowledge the interrupt in the interrupt context?

Yes, you need to either acknowledge or disable the interrupt in
interrupt context. Which one to do depends on your device.
--
Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.5" / 37N 20' 15.3"
Internet: steve @ Watt.COM Whois: SW32-ARIN
Free time? There's no such thing. It just comes in varying prices...

[John]

Thanks for the reply.

I got the interrupts working. I had to read the interrupt value from
the hardware interrupt vector register. When I did this, it
acknowledges the interrupt which, in turn allows me to wake up the
interrupt thread. The only thing I had to do was create a queue to
hold the interrupt vector because it was possible to have two
interrupts back to back (Read/Write). The stored interrupt vector is
then processed by the sleeping thread.

Do you have any ideas how long it takes for an interrupt thread to be
woken-up from a non-signal state?
When I try to cancel an output, for example, I'm waiting 250ms using
usec_wait(). then I check the output status to determine if the output
was cancelled. It's not. Eventually it is. I can see in the print
statements. Maybe these debug print statement are messing thing up.
Got to check on that.

[Cyril Novikov]

John wrote:
> On Thu, 03 Jul 2008 08:17:24 -0700, John <jvas...@cox.net> wrote:
>
>> Working on LynxOS 4.0 on a PPC.
>>
>> My device driver ISR is being hit as soon as I start an I/O even
>> though the I/O did not complete (nothing connected to the device).

Then why do you start an I/O, if nothing is connected? You're not telling us
some important information here.

>> I initialize the ISR during driver initialization
>>
>> next_interrupt_vector = drm_register_isr(handle, MyISR, context);
>>
>> In MyIsr I do,
>>
>> int MyISR (void *context)
>> {
>> process_interrupt();
>> kkprintf("MyISR\n");
>> ioint_link(next_interrupt_vector);
>> kkprintf("Leaving MyISR\n");
>> return 0;
>> }

You *must not* call ioint_link(), if you register the handler with
drm_register_isr(). DRM calls ioint_link() for you, if necessary.

>>
>> the value of next_interrupt_vector is a zero when printed. Should I
>> check for that before calling ioint_link()?
>> When I start an output, for example, my print statements in MyISR are
>> constantly being displayed.
>> Why is my interrupt service being called by the system?
>> Am I not initializing my ISR correctly?
>
> I have more information.
>
> MyISR performs an ssignal to wake up a thread to process the interrupt
> The thread will acknowledge the interrupt once it starts. I think
> (newbie here) the problem is that since the interrupt has not been
> acknowledge the system generates another interrupt. The thread never
> awakes because the OS is busy generating the interrupt that I have not
> processed.

This can happen with some devices. In such a case it's better to ack the
interrupt in the handler and defer processing to the thread.

> Does this sound like what might be happening. MyISR is constantly
> being call because the interrupt is still be generated by the device.
> should I acknowledge the interrupt in the interrupt context?

Yes, you should at least try that and see what happens.

[Steve Watt]

In article <ucgq649brm3bkfdmk...@4ax.com>,

John <jvas...@cox.net> wrote:
>Do you have any ideas how long it takes for an interrupt thread to be
>woken-up from a non-signal state?

Depends on what higher-priority tasks are running. If there aren't
any, it should be in a few tens of microseconds. LynuxWorks used
to publish that number, but I've managed to forget what we called it
back then (hey, it's been 8 years, I figure I'm entitled).

>When I try to cancel an output, for example, I'm waiting 250ms using
>usec_wait(). then I check the output status to determine if the output
>was cancelled. It's not. Eventually it is. I can see in the print
>statements. Maybe these debug print statement are messing thing up.
>Got to check on that.

Debug prints take a huge amount of time, and can screw up critical
timing. If you have important timing, log little bits into a memory
area and dump it out from something else.

[John]

On Thu, 03 Jul 2008 14:24:07 -0700, Cyril Novikov
<cnov...@mail.remove.this.ru> wrote:

>John wrote:
>> On Thu, 03 Jul 2008 08:17:24 -0700, John <jvas...@cox.net> wrote:
>>
>>> Working on LynxOS 4.0 on a PPC.
>>>
>>> My device driver ISR is being hit as soon as I start an I/O even
>>> though the I/O did not complete (nothing connected to the device).
>
>Then why do you start an I/O, if nothing is connected? You're not telling us
>some important information here.

I was just trying to start an I/O operation and then cancel it to
check on interrupts.

>
>>> I initialize the ISR during driver initialization
>>>
>>> next_interrupt_vector = drm_register_isr(handle, MyISR, context);
>>>
>>> In MyIsr I do,
>>>
>>> int MyISR (void *context)
>>> {
>>> process_interrupt();
>>> kkprintf("MyISR\n");
>>> ioint_link(next_interrupt_vector);
>>> kkprintf("Leaving MyISR\n");
>>> return 0;
>>> }
>
>You *must not* call ioint_link(), if you register the handler with
>drm_register_isr(). DRM calls ioint_link() for you, if necessary.
>

Thanks.

>>>
>>> the value of next_interrupt_vector is a zero when printed. Should I
>>> check for that before calling ioint_link()?
>>> When I start an output, for example, my print statements in MyISR are
>>> constantly being displayed.
>>> Why is my interrupt service being called by the system?
>>> Am I not initializing my ISR correctly?
>>
>> I have more information.
>>
>> MyISR performs an ssignal to wake up a thread to process the interrupt
>> The thread will acknowledge the interrupt once it starts. I think
>> (newbie here) the problem is that since the interrupt has not been
>> acknowledge the system generates another interrupt. The thread never
>> awakes because the OS is busy generating the interrupt that I have not
>> processed.
>
>This can happen with some devices. In such a case it's better to ack the
>interrupt in the handler and defer processing to the thread.
>
>> Does this sound like what might be happening. MyISR is constantly
>> being call because the interrupt is still be generated by the device.
>> should I acknowledge the interrupt in the interrupt context?
>
>Yes, you should at least try that and see what happens.

I got my interrupt working. I had to create a small queue that will
contain the interrupt to process. The Interrupt Thread, when woken up,
will then check the queue and process the interrupt.