> On Nov 11, 2015, at 11:51 PM, Michael Zimmermann <[email protected]> > wrote: > > I've started investigating in the timer event problem and I think I have > some weird problem with my platform drivers(I hope, so it's not a EDK2 bug). > > If I create a timer that runs every 100ms which does nothing but a > stall(1), the thread mode code stops after some random time(usually in edk2 > shell so I guess it's a race condition which needs some cpu load). >
Michael, Watch out as Stall() is Microseconds, and SetTimer() is 100ns I've seen bugs like that before in code. > When threadmode code is stopped the timer continues getting called and even > if I stop the timer afterwards(with CloseEvent) it keeps being stopped. > > Is there a way to get the threadmode context from inside a timer callback? > This way I could read the PC to check what's going on. > There are no threads. EFI is an event model. If your code is running you are blocking every one else's forward progress. Only code running at a higher TPL can preempt. So when your event is running it is blocking the main flow and any event trying to run at <= TPL of your event from making forward progress. gBS->Stall() does not yield, it is no different than running code. So there is only one context, you can print it out any time you want. Thanks, Andrew Fish PS When folks yell at us for not having threads in EFI we point them at: https://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf > Michael > > On Wed, Nov 11, 2015 at 8:10 PM, Kinney, Michael D < > [email protected]> wrote: > >> Michael, >> >> A periodic event timer at 30 times a second should not cause pauses >> forever, unless the action you are performing in the event notification >> function takes more than 1/30 of a second to complete. You should be able >> to just add a periodic event handler that does nothing, so you can measure >> what the overhead is. >> >> Another option is to use the performance counter in the TimerLib each time >> a Blt() is called (GetPerformanceCounterProperties() and >> GetPerformanceCounter()). When Blt() is called frequently, the amount of >> time since last vsync will have elapsed, and you can go the vsync action >> within the Blt() call. If you also set a one shot timer event, so if the >> last call to Blt() did not do a vsync and there are no more Blt() calls, >> 1/30th of a second later, the vsync action can be done. Every time Blt() >> is called, the one shot timer can be re-armed. This way, the one shot >> timer event is not actually executed very often. >> >> Mike >> >>> -----Original Message----- >>> From: edk2-devel [mailto:[email protected]] On Behalf Of >> Michael Zimmermann >>> Sent: Wednesday, November 11, 2015 12:32 AM >>> To: [email protected] >>> Subject: [edk2] EFI GOP with manual vsync trigger >>> >>> Hi, >>> >>> my Graphics HW uses a manual vsync trigger. That means that after drawing >>> to the framebuffer I need to manually trigger vsync(you can compare it to >>> switching between double buffers). >>> >>> The problem is that UEFI's GraphicsOutputProtocol(GOP) doesn't take care >> of >>> HW that needs a flush. >>> While issuing the trigger after every Blt Operation works, this obviously >>> causes extremely slow rendering for applications like the Shell which call >>> Blt very often(like for every character). >>> >>> Also I can't use a timer to set the trigger(like 30times a second) because >>> it takes too much time and the Timer Interrupt ends up consuming too much >>> time and the "normal" code gets paused forever. >>> >>> Do you have any other ideas how to handle this? >>> >>> Thx >>> Michael >>> _______________________________________________ >>> edk2-devel mailing list >>> [email protected] >>> https://lists.01.org/mailman/listinfo/edk2-devel >> > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
