#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 12/07/04 at 18:23:29 by Joel Sherrill

Status: assignedwaiting

comment:2 Changed on 09/01/05 at 12:44:00 by Joel Sherrill

Status: waitingclosed

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.