Opened on Dec 7, 2004 at 5:07:46 PM

Closed on Sep 1, 2005 at 12:44:00 PM

Last modified on Dec 3, 2006 at 1:31:13 PM

#732 closed defect (fixed)

RTEMS 4.5.0 Statistically Corrupted Thread After Full Message Queue Write

Reported by: k.reiche Owned by: Joel Sherrill
Priority: normal Milestone: 2
Component: score Version: unknown
Severity: major Keywords:
Cc: bugs@… Blocked By:
Blocking:

Description

Excessively writing to a full FIFO (RTEMS Message) plus a high IRQ rate (about once per 16000 clocks) statistically results in a CPU crash (user thread re-scheduled with completely wrong registers).
RTEMS 4.6.1 does not show this effect.
Revision history seems not to mention this fix.

Release:
001

Environment:
LEON-II, 16 MHz, 4 MB, RTEMS 4.5.0

How-To-Repeat:
Thread 1:
Continously write to a FIFO (RTEMS Message). After it is full (size doesn't matter) just repeat writing.
Sample:
while (1) rtems_message_queue_write (...);
In parallel an interrupt source with a interrupt frequency > 1 kHz (on a 16 MHz LEON-II system), i. e. INT period <= 16000 clocks, is needed. No INT service function needed, except to release the INT line if necessary.

Change History (2)

comment:1 Changed on Dec 7, 2004 at 6:23:29 PM by Joel Sherrill

Status: assigned → waiting

comment:2 Changed on Sep 1, 2005 at 12:44:00 PM by Joel Sherrill

Status: waiting → closed

State-Changed-From-To: feedback->closed
State-Changed-Why: No feedback received. It is assumed that the PR referred to
in an earlier comment was indeed the issue. If this applies
to newer RTEMS versions, this PR will need to be reopened.

Note: See TracTickets for help on using tickets.