Re: [ECOS] Scheduler/DSR

[Nick Garnett <nickg at ecoscentric dot com>]

Andy Atkinson <andya@hydrix.com> writes:

> 548    MUTEX_LOCK          2       34912   0xDED58       0x0
> 549    MUTEX_LOCKED        2       34935   0xDED58       0x0
> 550    SCHED_ZERO_LOCK     2       34973   0x0           0x0
> 551    SCHED_INC_LOCK      2       36139   0x1           0x0
> 552    SCHED_ZERO_LOCK     2       36227   0x0           0x0
> 553    SCHED_INC_LOCK      2       36284   0x1           0x0
> 554    SCHED_ZERO_LOCK     2       36358   0x0           0x0
> 555    SCHED_LOCK_VSR      2       36995   0x1           0x0
> 556    INTR_RAISE          2       37087   0x1A          0x0
> 557    USER_11             2       37174   0x70FF34F2    0xAAAAAAAA
> 558    CLOCK_ISR           2       37196   0x0           0x0
> 559    INTR_ACK            2       45      0x1A          0x0
> 560    INTR_END            2       196     0x1A          0x3
> 561    INTR_POST_DSR       2       255     0x1A          0x0
> 562    USER_13             2       450     0x70FF36E5    0xBBBBBBBB
> 563    USER_12             2       476     0x1           0xBBBBBBBB
> 564    CLOCK_TICK_START    2       576     0xC76B        0x0
> 565    USER_14             2       625     0xCCCCCCCC    0xCCCCCCCC
> 566    SCHED_INC_LOCK      2       22874   0x3           0x0
> 567    SCHED_SET_LOCK      2       23562   0x2           0x2
> 568    SCHED_INC_LOCK      2       24503   0x3           0x0

Line 566 is where is all goes wrong. There the scheduler lock jumps to
3, following which it never zeroes again, and so DSRs never get to
run. The last instrumented increment of the lock was at line 555 which
set it to 1. So something has set the lock to 2 at some point between
these points. It wasn't a call to the proper API, since that would
have been logged here. Perhaps it was something called from the DSR?

I suspect that there was some sort of memory corruption. The most
likely cause of this is a stack overflow. Alternatively, maybe JFFS2
is misbehaving in some way.

Possible ways of finding out what is going on are to try increasing the
thread stack sizes, or the heap size. Reducing them might also help,
by making the problem occur earlier. Use nm and objdump, or get a
linker allocation map, to look at the layout of program data and see
if there is anything close to the the scheduler lock that might
overflow.

-- 
Nick Garnett                                          eCos Kernel Architect
http://www.ecoscentric.com                     The eCos and RedBoot experts
Besuchen Sie uns vom 22.-24.02.05 auf der Embedded World 2005, Stand 11-124
Visit us at Embedded World 2005, NÃrnberg, Germany, 22-24 Feb, Stand 11-124


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