Sebastian Huber | 1 Jun 2010 08:57
Picon
Favicon

Re: RTEMS PowerPC progress (Not).

On 05/31/2010 09:42 PM, Joel Sherrill wrote:
[...]
> It would be worth backporting the 4.9 timer server code
> and supporting directives.  It may even be worth backporting
> the version on the head.

I would not use the 4.9 timer server code.

http://www.rtems.com/pipermail/rtems-users/2009-November/006248.html

> 
> It would be better to upgrade but you have eliminated that
> option. :)
[...]

Yes.

--

-- 
Sebastian Huber, embedded brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : +49 89 18 90 80 79-6
Fax     : +49 89 18 90 80 79-9
E-Mail  : sebastian.huber@...
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
rtems-users mailing list
rtems-users@...
(Continue reading)

Nick Thomas | 1 Jun 2010 11:23

RE: RTEMS PowerPC progress (Not).

> On 05/31/2010 09:42 PM, Joel Sherrill wrote:
> [...]
> > It would be worth backporting the 4.9 timer server code
> > and supporting directives.  It may even be worth backporting
> > the version on the head.
> 
> I would not use the 4.9 timer server code.
> 
> http://www.rtems.com/pipermail/rtems-users/2009-November/006248.html
> 

I applied the one-line patch mentioned in the mailing list threads.
But, alas, that change gave me a "0x1200 (Inst TLB miss)".

I guess that change isn't as harmless as it looks.

I was thinking of changing my calls to use the POSIX interface. But, does
the POSIX timers call down into the current implementation - and leave me
with the same issue?

Regards

Nick

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

(Continue reading)

Wolfram Wadepohl | 1 Jun 2010 13:52

assertion from heap

Hi,
got >>assertion "_Heap_Is_prev_used( next_block )" failed: file 
"../../../../../../rtems-4.6.99.2<<
Any ideas how to debug?

-- 
Schöne Grüße aus Reutlingen

Wolfram Wadepohl
Forschung & Entwicklung

E&K AUTOMATION GMBH
Werk Reutlingen

Siemensstraße 3
72766 Reutlingen
Deutschland

Tel.  +49 7121 514-289
Fax   +49 7121 514-299

eMail Wolfram.Wadepohl@...
      W.Wadepohl@...
WWW   http://www.ek-automation.com

Diese Nachricht ist keine geschäftliche Mitteilung i. S. des EHUG.

Bitte senden Sie mir keine Word- oder PowerPoint- (tm Microsoft) oder OOXML Anhänge.
Senden Sie mir einfachen Text, HTML oder PDF(ISO/IEC 32000). 
Siehe http://www.gnu.org/philosophy/no-word-attachments.de.html
(Continue reading)

Nick Thomas | 1 Jun 2010 14:29

RE: RTEMS PowerPC progress (Not).


I have been looking into rtems_timer_server_fire_after() function.

Have added some counting flags to check how far it's getting through that
func before doing something weird.

And, I notice that somewhere in the call to _Watchdog_Insert, something
happens. And, it looks like an interrupt has been taken.

It can't be though, because this is within an _ISR_Disable( level ); section
of code.

Unless something else is responsible.
But, it looks like an interrupt is happening, which eventually runs
_Thread_Enable_dispatch() (which sets the _Thread_Dispatch_disable_level to
zero.

And when we return to our rtems_timer_server_fire_after() function, we
shortly afterwards call _Thread_Enable_dispatch() again, and this sets
_Thread_Dispatch_disable_level to -1.

So, my problems could be caused by interrupts happening within an area of
code where they shouldn't!

Regards

Nick

_______________________________________________
rtems-users mailing list
(Continue reading)

Joel Sherrill | 1 Jun 2010 14:55
Gravatar

Re: assertion from heap

On 06/01/2010 06:52 AM, Wolfram Wadepohl wrote:
> Hi,
> got>>assertion "_Heap_Is_prev_used( next_block )" failed: file
> "../../../../../../rtems-4.6.99.2<<
> Any ideas how to debug?
>
>    
That tends to indicate that you have written
outside an allocated area.  The challenge is
that you need to know what is using the member
immediately before that address in the heap.

Is this easily reproducible?

--

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Joel Sherrill | 1 Jun 2010 14:58
Gravatar

Re: RTEMS PowerPC progress (Not).

On 06/01/2010 07:29 AM, Nick Thomas wrote:
> I have been looking into rtems_timer_server_fire_after() function.
>
> Have added some counting flags to check how far it's getting through that
> func before doing something weird.
>
> And, I notice that somewhere in the call to _Watchdog_Insert, something
> happens. And, it looks like an interrupt has been taken.
>
> It can't be though, because this is within an _ISR_Disable( level ); section
> of code.
>
> Unless something else is responsible.
> But, it looks like an interrupt is happening, which eventually runs
> _Thread_Enable_dispatch() (which sets the _Thread_Dispatch_disable_level to
> zero.
>
> And when we return to our rtems_timer_server_fire_after() function, we
> shortly afterwards call _Thread_Enable_dispatch() again, and this sets
> _Thread_Dispatch_disable_level to -1.
>
> So, my problems could be caused by interrupts happening within an area of
> code where they shouldn't!
>
>    
That is possible but please compare the
Timer Server code in 4.9 against that
in 4.7.  Or at least peruse the CVS history
on it.  I definitely recall some serious bugs
in there.
(Continue reading)

Joel Sherrill | 1 Jun 2010 15:09
Gravatar

Re: RTEMS PowerPC progress (Not).

On 06/01/2010 01:57 AM, Sebastian Huber wrote:
> On 05/31/2010 09:42 PM, Joel Sherrill wrote:
> [...]
>    
>> It would be worth backporting the 4.9 timer server code
>> and supporting directives.  It may even be worth backporting
>> the version on the head.
>>      
> I would not use the 4.9 timer server code.
>
> http://www.rtems.com/pipermail/rtems-users/2009-November/006248.html
>
>    
Wasn't all that resolved on the end of the 4.9 branch?
>> It would be better to upgrade but you have eliminated that
>> option. :)
>>      
> [...]
>
> Yes.
>
>    

--

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

_______________________________________________
(Continue reading)

Nick Thomas | 1 Jun 2010 17:29

RTEMS API calls from ISR.

Hi,

Is it safe to call any of these calls from inside an ISR?

rtems_task_is_suspended
rtems_task_resume
rtems_task_wake_if_delayed

I have some code which tries to wake up a task, but this code is run in an
ISR.

So, is it OK to do this?

Regards

Nick

-----------------------------
Nick Thomas
Email: nick.thomas@... 

_______________________________________________
rtems-users mailing list
rtems-users@...
http://www.rtems.org/mailman/listinfo/rtems-users

Needell Gerald | 1 Jun 2010 21:47
Favicon

Re: RTEMS API calls from ISR.

I have used the first 2 calls from ISRS on a SPARC/LEON3 BSP. I have never tried the 3rd. Note, that for the
SPARC, no RTEMS system calls may be made from a Non-Maskable Interrupt (NMI) Service Routine.
I hope that helps - Jerry
On Jun 1, 2010, at 11:29 AM, Nick Thomas wrote:

> Hi,
> 
> Is it safe to call any of these calls from inside an ISR?
> 
> rtems_task_is_suspended
> rtems_task_resume
> rtems_task_wake_if_delayed
> 
> I have some code which tries to wake up a task, but this code is run in an
> ISR.
> 
> So, is it OK to do this?
> 
> 
> Regards
> 
> Nick
> 
> -----------------------------
> Nick Thomas
> Email: nick.thomas@... 
> 
> 
> _______________________________________________
> rtems-users mailing list
(Continue reading)

Joel Sherrill | 1 Jun 2010 21:49
Gravatar

Re: RTEMS API calls from ISR.

On 06/01/2010 02:47 PM, Needell Gerald wrote:
> I have used the first 2 calls from ISRS on a SPARC/LEON3 BSP. I have never tried the 3rd. Note, that for the
SPARC, no RTEMS system calls may be made from a Non-Maskable Interrupt (NMI) Service Routine.
> I hope that helps - Jerry
> On Jun 1, 2010, at 11:29 AM, Nick Thomas wrote:
>
>    
>> Hi,
>>
>> Is it safe to call any of these calls from inside an ISR?
>>
>> rtems_task_is_suspended
>> rtems_task_resume
>> rtems_task_wake_if_delayed
>>
>>      
What is this last call?  I don't know it.

--joel
>> I have some code which tries to wake up a task, but this code is run in an
>> ISR.
>>
>> So, is it OK to do this?
>>
>>
>> Regards
>>
>> Nick
>>
>> -----------------------------
(Continue reading)


Gmane