RE: [ECOS] IRQs and Scheduler Lock

[sams at myself dot com]

Sorry my mistake, ISR/DSR works fine.

After taking latest CVS code, I checked that cyg_interrupt_mask()/unmask() mask correctly the PIC,
and cyg_interrupt_enable()/disable() change correctly CPU flags then I added more traces and found my problem....
It was due to the fact keyboard send me two IRQs when I press one key. First ISR is processed immediately, then when scheduler unlock() the DSR run, acking the 8042 kbd controller which then send the second IRQ.
As I was making a diff of time between before scheduler_lock() and call (latest) to ISR I was then 
measuring 5 Sec :)

OK still have to work on my gets() problem, unfortunately I don't think I will be able to make a driver 
for it, at least for now....

Thanks,
Sam.

-----Original Message-----
From: ecos-discuss-owner@sources.redhat.com [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Jonathan Larmour
Sent: Thursday, January 03, 2002 6:19 PM
To: 'Sam Sortais'
Cc: 'ecos-discuss@sources.redhat.com'
Subject: Re: [ECOS] IRQs and Scheduler Lock

Sam Sortais wrote:
>
> I did a small test to catch keyboard interrupts
> from PC, in order to test ISR and DSR mechanism, and measure latency.
> It worked fine, then I added code which locked the scheduler for 5 Sec to see what happen. When I press a key during this interval, no ISR was called... only when scheduler_unlock() is called, then ISR is called followed immediately by DSR.
> My understanding was that the ISR/DSR system was done so that IRQs can be processed even if scheduler is locked and DSRs get called when scheduler is unlocked.

Your understanding is correct. You should easily be able to see for
yourself if interrupts have been disabled in the CPU flags register, or
masked in the PIC to find out what's gone wrong. Certainly this normally
works.

> I found another problem related to keyboard when using gets().
> I read in previous messages, support for keyboard works by doing polling, but I do not explain why when gets() is called by one thread, all other threads stop running...

I don't think it should be all threads. But it probably will be all threads
of lower priority - the fact it polls means it is in a busy loop, so lower
priority threads can't run. A proper interrupt driven driver needs to be
written for that.

Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine