Marvin, Thanks for the reply, that clears a few things up in my mind. Now I understand the symptoms better. Unfortunately, I do not know of a more elegant solution. Maybe someone at FSM Labs can explain the intended method for handling this and/or the observed behavior. regards, Rich -----Original Message----- From: Marvin Germain [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 01, 2001 11:00 AM To: [EMAIL PROTECTED] Subject: [rtl] Re: RE: keyboard freeze with one percent CPU load Hi, Rich. I calculated the CPU load by timing the ISR (50 us, not ms), and comparing this with the time between interrupts. The computations are actually commented out for now, so all the second module is doing is pthread_suspend_np(). The operating system is definately not frozen, because I can regain control by pulling the plug on the external data clock, thereby stopping the interrupts. I think the problem is with the scheduler, based on the results in my follow-up post. To re- iterate, I put a call to rtl_schedule() in a periodic task, which seemed to fix the problem. This implies that user-space tasks are simply not being scheduled when the interrupts arrive once every five mill-seconds. Marvin - ********************************************* * Dr. Marvin E. Germain * * Zygo Corporation - Tucson AZ * * [EMAIL PROTECTED] * ********************************************* ----- End of forwarded message from [EMAIL PROTECTED] ----- -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/ ----- End of forwarded message from [EMAIL PROTECTED] ----- -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
