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

[Philipp Eppelt <philipp.eppelt@xxxxxxxxxxxxxxxxxxxxx>]

Hi Cindy,

yes, that's the next thing on my list.

Cheers
Philipp

On 09/16/2013 06:39 PM, Rempel, Cynthia wrote:
> 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
>