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-boun...@rtems.org [rtems-devel-boun...@rtems.org] on behalf > of Philipp Eppelt [philipp.epp...@mailbox.tu-dresden.de] > Sent: Monday, September 16, 2013 6:41 AM > To: rtems-devel@rtems.org; pok-de...@lists.tuxfamily.org > 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@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
