This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Scheduler/DSR
- From: Nick Garnett <nickg at ecoscentric dot com>
- To: Andy Atkinson <andya at hydrix dot com>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: 16 Feb 2005 11:34:32 +0000
- Subject: Re: [ECOS] Scheduler/DSR
- References: <1108526180.3687.62.camel@monty.private.hydrix.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