This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Re: ISR not causing an DSR in some rare conditions


There was a discussion on the developers list last week or the week before
about a subtle race condition that arose when an interrupt occurred at the
exact instant that a single thread called a blocking primitive and the
scheduler was busy transitioning to the idle thread.  See
http://ecos.sourceware.org/ml/ecos-devel/2006-01/msg00000.html for more
details.  Nick posted a patch, which I presume was applied to the CVS tree.
You could try applying his patch yourself or updating to the latest CVS tree
(and seeing if the tree does, in fact, include his patch).

hth...

--wpd

> -----Original Message-----
> From: Stefan Sommerfeld [mailto:sommerfeld@mikrom.de] 
> Sent: Thursday, January 12, 2006 11:58 AM
> To: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] Re: ISR not causing an DSR in some rare conditions
> 
> 
> Hi,
> 
> >>>> No. The interrupts will not be disabled at any time. The 
> interrupt 
> >>>> from
> >>>> this source will only be acknowledged in the isr function.
> >>>>
> >>>> The functionality is simple. A hardware unit will be started and
> >>>> reports the finish with an interrupt. I have made a counter on
> >>>> hardware unit start, isr and dsr. After this long-run 
> test, the dsr
> >>>> counter is one less than the other counters.
> >>>
> > [...]
> >>> Thus, you need to increment your test counter by the 
> value of 'count'
> >>> argument in the DSR handler, do you?
> >>
> >> No... you don't understand.
> >
> > Well, maybe, but that's how I read your:
> >
> >>>> No. The interrupts will not be disabled at any time. The 
> interrupt 
> >>>> from
> >>>> this source will only be acknowledged in the isr function.
> >
> > If interrupts are not disabled, and interrupt is acked in 
> isr function
> > as you wrote above, then more than one could happen while 
> no dsr is run
> > yet.
> >
> >> The dsr count of this particular irq cannot be other than 1.
> >
> > Well, seems I indeed misunderstand, but did you *actually* check it
> > isn't? Ah, well, from your other reply I see you didn't, though I'd
> > check anyway as "cannot" and "doesn't indeed happen" are 
> surprisingly
> > different, at least in my experience.
> 
> Maybe i was not clear in my descriptions. I'll try to go in 
> more detail. 
> The XScale is using a picture scaler in an FPGA (so outside of the 
> processor). It will setup the scaler and start it. The irq 
> tells the system 
> the scaling has finished. Now in the dsr function a new 
> scaler setup is 
> loaded and the scaler is restarted. That's way only one 
> irq,dsr will come. 
> You're right, that i did not check the dsr count, but there's no 
> possibility for multiple dsr's. What i see is that my scaling 
> stops after a 
> long time and from what i found out, it's the missing dsr, 
> because the 
> expected isr was there.
> 
> >> The hardware unit causes only one irq some time after it was
> >> started. If ecos does not call the dsr routine, the 
> hardware unit will
> >> not be started again and so no more irq's will be caused.
> >
> > Do you say that it's DSR that restarts the hardware unit? Seems so
> > though you didn't tell it to us before.
> 
> Sorry... i hope now it's more clear.
> >
> > After DSR is missed is the entire system operational? I 
> mean is the rest
> > of the system running OK (including ISRs/DSRs from other sources,
> > e.g., timer) after the DSR is missing? If so, then it looks 
> like some
> > race somewhere, either in your code or in the eCos, or entirely
> > independent bug that just happens to break this thing.
> 
> The entire system is working well. Other irqs/dsrs are working and 
> multithreading too. For me it looks like a race condition, 
> maybe not in 
> ecos itself, but in a platform/variant implementation. I had 
> the "feeling" 
> that the system sometimes "loses" dsrs before with the dma 
> channels, but 
> currently i'm using multiple dma channels at the same time, 
> so multiple 
> irqs will happen and if a dsrs is missing, another irq will 
> retry the dsr. 
> I plan to setup a test with a bit hardware support (FPGA 
> generate multiple 
> irqs in a short time)
> 
> > BTW, if it runs on ARM, do you use FIQ? I think I know at 
> least 2 bugs
> > in the ARM HAL, one of which is with FIQ handling (and 
> another one being
> > in the context switch), but chances are very low they show 
> themselves
> > the way you see.
> 
> No. From what i know the current pxa2x0 variant does not 
> support FIQ's, so 
> i don't use them. For my understanding, the IRQ's are okay only the 
> IRQ->DSR functionality isn't working.
> 
> For now i've implemented a watchdog to check for the missing 
> dsr, which 
> "fixes" the problem, but my company is starting a new project 
> and we are 
> not sure if we should continue using ecos. I like it, but the 
> DSR problems 
> are critical. I also had problems with very long delays 
> between ISR and 
> DSR, which maybe caused by the execution order.
> 
> Bye... 
> 
> 
> -- 
> Before posting, please read the FAQ: 
> http://ecos.sourceware.org/fom/ecos
> and search the list archive: 
> http://ecos.sourceware.org/ml/ecos-discuss
> 


Patrick Doyle
Manager, Digital Systems Group
(603) 546-2179

 

This communication is from DTC Communications, Inc. and is intended to be
confidential and solely for the use of the persons or entities addressed
above.  If you are not an intended recipient, be aware that the information
contained herein may be protected from unauthorized use by privilege or law,
and any copying, distribution, disclosure, or other use of this information
is prohibited.  If you have received this communication in error, please
contact the sender by return e-mail or telephone the above number
immediately and delete or destroy all copies.  Thank you for your
cooperation.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]