[pok-devel] RE: [GSOC] POK+RTEMS interrupt status

["Rempel, Cynthia" <cynt6007@xxxxxxxxxxxxxxxxxx>]

Hi Philipp Eppelt,

Could you put that information on the wiki page for your project, so the next student that works on the project will know where to start?

Thanks,
Cindy
________________________________________
From: rtems-devel-bounces@xxxxxxxxx [rtems-devel-bounces@xxxxxxxxx] on behalf of Philipp Eppelt [philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx]
Sent: Monday, September 16, 2013 6:41 AM
To: rtems-devel@xxxxxxxxx; pok-devel@xxxxxxxxxxxxxxxxxxx
Subject: [GSOC] POK+RTEMS interrupt status

Hi,

it's suggested pencils down today and I have still trouble with the
interrupt handling.


I have this functionality:
- enable/disable interrupts for a partition
- register a handler for a partition
- partition needs to acknowledge the interrupt before more a send

The kernel handler sends the EOI signal to the pic, but interrupts are
not opened before either the user space handler is called (iret) or the
interrupt handler returns(sti).

The transition from kernel to user space is the hacky part. I copy the
interrupted context from the kernel to the user stack. Unfortunately,
stack offset for the data isn't constant so I insert a magic value to
find the beginning of the data.
Then I modify the eip to point to the user space handler.

The user space handler recovers the vector number and executes the RTEMS
interrupt dispatch routine. Afterwards it sends a system call
POK_SYSCALL_IRQ_PARTITION_ACK to signal the kernel, to send further
clock interrupts. Then it restores the interrupted context and returns
to the point of interruption.

Well, it doesn't work. When I enable interrupts through the EFLAGS
register and return to the user land, the handler isn't executing.
Instead another clock interrupt occurs and we are back in the kernel.
Although this interrupt should be very fast (no user handler as there
was no ack), it still fires and fires and fires and fires ....
So the user space handler isn't making any progress.

I acknowledge the clock irq (0x0) during the kernel handler, because
clock ticks invoke pok_sched() and a descheduling of the current task
will result in an unacknowledged interrupt.


If I leave the interrupts disabled after the iret the RTEMS
C_dispatch_isr is called which doesn't result in a missing handler
error, so I think my clock driver works.


I am out of ideas by now.
Looks this reoccurring interrupt behaviour familiar to someone? Any
ideas where it comes from? How to fix it?


Cheers,
Philipp
_______________________________________________
rtems-devel mailing list
rtems-devel@xxxxxxxxx
http://www.rtems.org/mailman/listinfo/rtems-devel