* [ECOS] Task switching problem
@ 2005-07-01 8:59 Yuriy Coureelo
2005-07-01 10:53 ` Andrew Lunn
0 siblings, 1 reply; 7+ messages in thread
From: Yuriy Coureelo @ 2005-07-01 8:59 UTC (permalink / raw)
To: ecos-discuss
Good Day!
eCos: v2.0-20030509-0835
Architecture: ARM, AT91
PROBLEM DESCRIPTION
There are 4 active threads: system idle thread, thread A working with
FIQ, thread B working with IRQ, high-priority thread C just blinking
a LED. Starting hardware I see blinking LED (good) and working threads
A and B (fine). System works from couple of seconds upto couple of
minutes, then LED stops blinking.
I tried to find out a reason lot of times, and had following common info:
01.FIQ incoming
02.ISR and DSR called, DSR posted flags for thread A
03.Scheduler takes a decision to switch from idle to thread A
04.IRQ incoming but scheduler works yet, so ISR called and DSR just
posted
05.Threads A start working but there is pending DSR (posted at step 04)
06.DSR called and posted flags for thread B
07.Scheduler takes a decision to switch from thread A to thread B
08.Thread B working and going to sleep
09.IRQ incoming but scheduler already works, so ISR called and DSR just
posted
10.Scheduler takes a decision to switch from thread B to thread A,
because thread B already sleeping, and IRQ (at step 09) posted DSR
a bit later than scheduler checks DSRs at its beginning
11.After switching scheduler checks for DSRs again and detects DSR,
posted at step 09:
if( Cyg_Interrupt::DSRs_pending() ) {
inc_sched_lock(); // reclaim the lock
continue; // go back to head of loop
}
12.DSR called and posted flags for thread B
13.Scheduler takes a decision to switch from thread A to thread B
(thread A didn't even continue)
14.Thread B working and going to sleep
15.Scheduler takes a decision to switch from thread B to thread A
16.Thread A working and going to sleep
17.Scheduler takes a decision to switch from thread A to idle
18.interrupt_end() at last exits,
Cyg_Scheduler::get_sched_lock() returns 0 (my checkpoint)
But idle thread isn't called.
When new interrupt comes, interrupt_end() exits because sched_lock
already equals 1, althoug no calls to inc_sched_lock() and
set_sched_lock().
No more interrupts come after that (i think cpu got somewhere away).
Stacks seems are OK (I have memory dump over JTAG).
I guess it is extremely hard to find a reason of the problem, but
would you point me where or what I should search, please.
Yuriy Coureelo
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [ECOS] Task switching problem
2005-07-01 8:59 [ECOS] Task switching problem Yuriy Coureelo
@ 2005-07-01 10:53 ` Andrew Lunn
2005-07-04 10:22 ` Re[2]: " Yuriy Coureelo
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Lunn @ 2005-07-01 10:53 UTC (permalink / raw)
To: Yuriy Coureelo; +Cc: ecos-discuss
On Fri, Jul 01, 2005 at 03:59:34PM +0600, Yuriy Coureelo wrote:
> Good Day!
>
> eCos: v2.0-20030509-0835
That is quite an old version of eCos. Have you tried with anoncvs?
> Architecture: ARM, AT91
>
> PROBLEM DESCRIPTION
> There are 4 active threads: system idle thread, thread A working with
> FIQ, thread B working with IRQ, high-priority thread C just blinking
> a LED. Starting hardware I see blinking LED (good) and working threads
> A and B (fine). System works from couple of seconds upto couple of
> minutes, then LED stops blinking.
>
> I tried to find out a reason lot of times, and had following common info:
>
> 01.FIQ incoming
> 02.ISR and DSR called, DSR posted flags for thread A
> 03.Scheduler takes a decision to switch from idle to thread A
> 04.IRQ incoming but scheduler works yet, so ISR called and DSR just
> posted
> 05.Threads A start working but there is pending DSR (posted at step 04)
> 06.DSR called and posted flags for thread B
> 07.Scheduler takes a decision to switch from thread A to thread B
> 08.Thread B working and going to sleep
> 09.IRQ incoming but scheduler already works, so ISR called and DSR just
> posted
> 10.Scheduler takes a decision to switch from thread B to thread A,
> because thread B already sleeping, and IRQ (at step 09) posted DSR
> a bit later than scheduler checks DSRs at its beginning
> 11.After switching scheduler checks for DSRs again and detects DSR,
> posted at step 09:
>
> if( Cyg_Interrupt::DSRs_pending() ) {
> inc_sched_lock(); // reclaim the lock
> continue; // go back to head of loop
> }
>
> 12.DSR called and posted flags for thread B
> 13.Scheduler takes a decision to switch from thread A to thread B
> (thread A didn't even continue)
> 14.Thread B working and going to sleep
> 15.Scheduler takes a decision to switch from thread B to thread A
> 16.Thread A working and going to sleep
> 17.Scheduler takes a decision to switch from thread A to idle
> 18.interrupt_end() at last exits,
> Cyg_Scheduler::get_sched_lock() returns 0 (my checkpoint)
>
> But idle thread isn't called.
> When new interrupt comes, interrupt_end() exits because sched_lock
> already equals 1, althoug no calls to inc_sched_lock() and
> set_sched_lock().
> No more interrupts come after that (i think cpu got somewhere away).
> Stacks seems are OK (I have memory dump over JTAG).
>
> I guess it is extremely hard to find a reason of the problem, but
> would you point me where or what I should search, please.
You could try enabling the kernel instramentation. Take a look at the
example in the documentation:
http://ecos.sourceware.org/docs-latest/user-guide/kernel-instrumentation.html
It might help you track down where the schedular lock count goes
funny.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread* Re[2]: [ECOS] Task switching problem
2005-07-01 10:53 ` Andrew Lunn
@ 2005-07-04 10:22 ` Yuriy Coureelo
2005-07-04 11:13 ` Andrew Lunn
0 siblings, 1 reply; 7+ messages in thread
From: Yuriy Coureelo @ 2005-07-04 10:22 UTC (permalink / raw)
To: ecos-discuss
[-- Attachment #1: Type: text/plain, Size: 391 bytes --]
Dear Sir!
AL> You could try enabling the kernel instramentation.
AL> Andrew
Attached file contains instrumentation info.
I translated every byte from memory dump to textual representation.
Would take a look there and maybe catch something wrong, please.
Sincerely yours
Yuriy Coureelo
------------------------
Engineer
Telecommunication Equipment Division
Micran Company
Tomsk, Russia
[-- Attachment #2: instr.txt --]
[-- Type: text/plain, Size: 9581 bytes --]
Num Thread Time Arg1 Arg2
001 01 0x1a66 INTR_RESTORE 0x00000012 0x00000000
002 01 0x1b6e INTR_MASK 0x00000000 0x00000000
003 01 0x1b77 INTR_ACK 0x00000000 0x00000000
004 01 0x1b85 INTR_END 0x00000000 0x00000003
005 01 0x1b8c INTR_POST_DSR 0x00000000 0x00000000
006 01 0x1b94 SCHED_UNLOCK 0x00000001 0x00000000
007 01 0x1ba2 INTR_CALL_DSR 0x00000000 0x00000000
008 01 0x1baf SCHED_LOCK 0x00000002 0x00000000
009 01 0x1bc0 THREAD_WAKE 0x0211dea0 0x0208cfb8
010 01 0x1bc7 SCHED_LOCK 0x00000003 0x00000000
011 01 0x1bd4 SCHED_UNLOCK 0x00000003 0x00000000
012 01 0x1be3 SCHED_UNLOCK 0x00000002 0x00000000
013 01 0x1bee INTR_UNMASK 0x00000000 0x00000000
014 01 0x1bf8 SCHED_RESCHEDULE 0x00000000 0x00000000
015 01 0x1c09 THREAD_SWITCH 0x0208cea4 0x0211dea0
016 01 0x1c2f INTR_MASK 0x00000012 0x00000000
017 01 0x1c38 INTR_ACK 0x00000012 0x00000000
018 01 0x1c47 INTR_END 0x00000012 0x00000003
019 01 0x1c4e INTR_POST_DSR 0x00000012 0x00000000
020 01 0x1c56 SCHED_UNLOCK 0x00000002 0x00000000
021 01 0x1c5e INTR_RESTORE 0x00000012 0x00000000
022 06 0x1c71 SCHED_UNLOCK 0x00000001 0x00000000
023 06 0x1c7f INTR_CALL_DSR 0x00000012 0x00000000
024 06 0x1cab SCHED_LOCK 0x00000002 0x00000000
025 06 0x1cbc THREAD_WAKE 0x020ff280 0x0208cfb8
026 06 0x1cc3 SCHED_LOCK 0x00000003 0x00000000
027 06 0x1cd0 SCHED_UNLOCK 0x00000003 0x00000000
028 06 0x1cdf SCHED_UNLOCK 0x00000002 0x00000000
029 06 0x1ce9 INTR_UNMASK 0x00000012 0x00000000
030 06 0x1cf3 SCHED_RESCHEDULE 0x00000000 0x00000000
031 06 0x1d02 THREAD_SWITCH 0x0211dea0 0x020ff280
032 0e 0x1d1e SCHED_UNLOCK 0x00000001 0x00000000
033 0e 0x1d30 SCHED_LOCK 0x00000001 0x00000000
034 0e 0x1d36 SCHED_UNLOCK 0x00000001 0x00000000
035 0e 0x1d5a SCHED_LOCK 0x00000001 0x00000000
036 0e 0x1d62 SCHED_LOCK 0x00000002 0x00000000
037 0e 0x1d69 SCHED_UNLOCK 0x00000002 0x00000000
038 0e 0x1d75 THREAD_SLEEP 0x020ff280 0x00000000
039 0e 0x1d7c SCHED_LOCK 0x00000002 0x00000000
040 0e 0x1d86 SCHED_UNLOCK 0x00000002 0x00000000
041 0e 0x1d90 SCHED_RESCHEDULE 0x00000001 0x00000000
042 0e 0x1d98 SCHED_RESCHEDULE 0x00000000 0x00000000
043 0e 0x1da9 THREAD_SWITCH 0x020ff280 0x0211dea0
044 06 0x1dd5 INTR_MASK 0x00000012 0x00000000
045 06 0x1dde INTR_ACK 0x00000012 0x00000000
046 06 0x1dec INTR_END 0x00000012 0x00000003
047 06 0x1df3 INTR_POST_DSR 0x00000012 0x00000000
048 06 0x1dfb SCHED_UNLOCK 0x00000001 0x00000000
049 06 0x1e09 INTR_CALL_DSR 0x00000012 0x00000000
050 06 0x1e1f SCHED_LOCK 0x00000002 0x00000000
051 06 0x1e30 THREAD_WAKE 0x020ff280 0x0208cfb8
052 06 0x1e37 SCHED_LOCK 0x00000003 0x00000000
053 06 0x1e44 SCHED_UNLOCK 0x00000003 0x00000000
054 06 0x1e53 SCHED_UNLOCK 0x00000002 0x00000000
055 06 0x1e5d INTR_UNMASK 0x00000012 0x00000000
056 06 0x1e67 SCHED_RESCHEDULE 0x00000000 0x00000000
057 06 0x1e77 THREAD_SWITCH 0x0211dea0 0x020ff280
058 0e 0x1e92 SCHED_UNLOCK 0x00000001 0x00000000
059 0e 0x1ea4 SCHED_LOCK 0x00000001 0x00000000
060 0e 0x1eaa SCHED_UNLOCK 0x00000001 0x00000000
061 0e 0x1ed9 SCHED_LOCK 0x00000001 0x00000000
062 0e 0x1edf ALARM_REM 0x020eb158 0x020f3080
063 0e 0x1ee7 SCHED_UNLOCK 0x00000001 0x00000000
064 0e 0x1ef8 SCHED_LOCK 0x00000001 0x00000000
065 0e 0x1efe SCHED_UNLOCK 0x00000001 0x00000000
066 0e 0x1f4c SCHED_LOCK 0x00000001 0x00000000
067 0e 0x1f54 SCHED_LOCK 0x00000002 0x00000000
068 0e 0x1f5b SCHED_UNLOCK 0x00000002 0x00000000
069 0e 0x1f67 THREAD_SLEEP 0x020ff280 0x00000000
070 0e 0x1f6d SCHED_LOCK 0x00000002 0x00000000
071 0e 0x1f78 SCHED_UNLOCK 0x00000002 0x00000000
072 0e 0x1f82 SCHED_RESCHEDULE 0x00000001 0x00000000
073 0e 0x1f8a SCHED_RESCHEDULE 0x00000000 0x00000000
074 0e 0x1f9b THREAD_SWITCH 0x020ff280 0x0211dea0
075 06 0x1fb3 INTR_RESTORE 0x00000012 0x00000000
076 06 0x1fc2 SCHED_LOCK 0x00000001 0x00000000
077 06 0x1fc8 SCHED_UNLOCK 0x00000001 0x00000000
078 06 0x1feb SCHED_LOCK 0x00000001 0x00000000
079 06 0x1ff1 MUTEX_LOCK 0x0211de80 0x00000000
080 06 0x1ff8 MUTEX_LOCKED 0x0211de80 0x00000000
081 06 0x1ffe SCHED_UNLOCK 0x00000001 0x00000000
082 06 0x2022 SCHED_LOCK 0x00000001 0x00000000
083 06 0x2028 MUTEX_UNLOCK 0x0211de80 0x00000000
084 06 0x2031 SCHED_UNLOCK 0x00000001 0x00000000
085 06 0x2050 SCHED_LOCK 0x00000001 0x00000000
086 06 0x2056 MUTEX_LOCK 0x0211de80 0x00000000
087 06 0x205d MUTEX_LOCKED 0x0211de80 0x00000000
088 06 0x2063 SCHED_UNLOCK 0x00000001 0x00000000
089 06 0x20cd INTR_MASK 0x00000012 0x00000000
090 06 0x20d6 INTR_ACK 0x00000012 0x00000000
091 06 0x20e4 INTR_END 0x00000012 0x00000003
092 06 0x20eb INTR_POST_DSR 0x00000012 0x00000000
093 06 0x20f4 SCHED_UNLOCK 0x00000001 0x00000000
094 06 0x2102 INTR_CALL_DSR 0x00000012 0x00000000
095 06 0x212d SCHED_LOCK 0x00000002 0x00000000
096 06 0x213f THREAD_WAKE 0x020ff280 0x0208cfb8
097 06 0x2145 SCHED_LOCK 0x00000003 0x00000000
098 06 0x2152 SCHED_UNLOCK 0x00000003 0x00000000
099 06 0x2161 SCHED_UNLOCK 0x00000002 0x00000000
100 06 0x216b INTR_UNMASK 0x00000012 0x00000000
101 06 0x2176 SCHED_RESCHEDULE 0x00000000 0x00000000
102 06 0x2185 THREAD_SWITCH 0x0211dea0 0x020ff280
103 0e 0x21a1 SCHED_UNLOCK 0x00000001 0x00000000
104 0e 0x21b2 SCHED_LOCK 0x00000001 0x00000000
105 0e 0x21b8 SCHED_UNLOCK 0x00000001 0x00000000
106 0e 0x21d6 SCHED_LOCK 0x00000001 0x00000000
107 0e 0x21de SCHED_LOCK 0x00000002 0x00000000
108 0e 0x21e4 SCHED_UNLOCK 0x00000002 0x00000000
109 0e 0x2201 INTR_MASK 0x00000012 0x00000000
110 0e 0x220a INTR_ACK 0x00000012 0x00000000
111 0e 0x2218 INTR_END 0x00000012 0x00000003
112 0e 0x221f INTR_POST_DSR 0x00000012 0x00000000
113 0e 0x2228 SCHED_UNLOCK 0x00000002 0x00000000
114 0e 0x222f INTR_RESTORE 0x00000012 0x00000000
115 0e 0x223d THREAD_SLEEP 0x020ff280 0x00000000
116 0e 0x2243 SCHED_LOCK 0x00000002 0x00000000
117 0e 0x224e SCHED_UNLOCK 0x00000002 0x00000000
118 0e 0x2258 SCHED_RESCHEDULE 0x00000001 0x00000000
119 0e 0x2260 SCHED_RESCHEDULE 0x00000000 0x00000000
120 0e 0x2271 THREAD_SWITCH 0x020ff280 0x0211dea0
121 06 0x2293 INTR_CALL_DSR 0x00000012 0x00000000
122 06 0x22a2 SCHED_LOCK 0x00000002 0x00000000
123 06 0x22b4 THREAD_WAKE 0x020ff280 0x0208cfb8
124 06 0x22ba SCHED_LOCK 0x00000003 0x00000000
125 06 0x22c7 SCHED_UNLOCK 0x00000003 0x00000000
126 06 0x22d6 SCHED_UNLOCK 0x00000002 0x00000000
127 06 0x22e0 INTR_UNMASK 0x00000012 0x00000000
128 06 0x22eb SCHED_RESCHEDULE 0x00000000 0x00000000
129 06 0x22fa THREAD_SWITCH 0x0211dea0 0x020ff280
130 0e 0x2316 SCHED_UNLOCK 0x00000001 0x00000000
131 0e 0x2327 SCHED_LOCK 0x00000001 0x00000000
132 0e 0x232d SCHED_UNLOCK 0x00000001 0x00000000
133 0e 0x2344 ALARM_INIT 0x020f3080 0x00000000
134 0e 0x234a ALARM_TRIGGER 0x00000af6 0x00000000
135 0e 0x234f ALARM_INTERVAL 0x00000000 0x00000000
136 0e 0x2358 SCHED_LOCK 0x00000001 0x00000000
137 0e 0x2360 ALARM_ADD 0x020eb158 0x020f3080
138 0e 0x237f SCHED_UNLOCK 0x00000001 0x00000000
139 0e 0x2396 SCHED_LOCK 0x00000001 0x00000000
140 0e 0x239e SCHED_LOCK 0x00000002 0x00000000
141 0e 0x23a4 SCHED_UNLOCK 0x00000002 0x00000000
142 0e 0x23b0 THREAD_SLEEP 0x020ff280 0x00000000
143 0e 0x23b7 SCHED_LOCK 0x00000002 0x00000000
144 0e 0x23c2 SCHED_UNLOCK 0x00000002 0x00000000
145 0e 0x23cc SCHED_RESCHEDULE 0x00000001 0x00000000
146 0e 0x23d4 SCHED_RESCHEDULE 0x00000000 0x00000000
147 0e 0x23e5 THREAD_SWITCH 0x020ff280 0x0211dea0
148 06 0x23fc INTR_RESTORE 0x00000012 0x00000000
149 06 0x24e9 SCHED_LOCK 0x00000001 0x00000000
150 06 0x24ef MUTEX_UNLOCK 0x0211de80 0x00000000
151 06 0x24f8 SCHED_UNLOCK 0x00000001 0x00000000
152 06 0x250c SCHED_LOCK 0x00000001 0x00000000
153 06 0x2514 SCHED_LOCK 0x00000002 0x00000000
154 06 0x251b SCHED_UNLOCK 0x00000002 0x00000000
155 06 0x2527 THREAD_SLEEP 0x0211dea0 0x00000000
156 06 0x252e SCHED_LOCK 0x00000002 0x00000000
157 06 0x2538 SCHED_UNLOCK 0x00000002 0x00000000
158 06 0x2543 SCHED_RESCHEDULE 0x00000001 0x00000000
159 06 0x254a SCHED_RESCHEDULE 0x00000000 0x00000000
160 06 0x2567 THREAD_SWITCH 0x0211dea0 0x0208cea4
161 01 0x257f INTR_RESTORE 0x00000000 0x00000000
162 01 0x2142 INTR_MASK 0x00000000 0x00000000
163 01 0x214c INTR_ACK 0x00000000 0x00000000
164 01 0x215a INTR_END 0x00000000 0x00000003
165 01 0x2161 INTR_POST_DSR 0x00000000 0x00000000
166 01 0x2169 SCHED_UNLOCK 0x00000002 0x00000000
167 01 0x2171 INTR_RESTORE 0x00000000 0x00000000
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Task switching problem
2005-07-04 10:22 ` Re[2]: " Yuriy Coureelo
@ 2005-07-04 11:13 ` Andrew Lunn
2005-07-05 3:51 ` Yuriy Coureelo
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Lunn @ 2005-07-04 11:13 UTC (permalink / raw)
To: Yuriy Coureelo; +Cc: ecos-discuss
On Mon, Jul 04, 2005 at 05:21:47PM +0600, Yuriy Coureelo wrote:
> Dear Sir!
>
> AL> You could try enabling the kernel instramentation.
> AL> Andrew
>
> Attached file contains instrumentation info.
> I translated every byte from memory dump to textual representation.
There is a program to do that. See packages/kernel/current/host/instr
> Would take a look there and maybe catch something wrong, please.
> Num Thread Time Arg1 Arg2
>
> 130 0e 0x2316 SCHED_UNLOCK 0x00000001 0x00000000
> 131 0e 0x2327 SCHED_LOCK 0x00000001 0x00000000
> 132 0e 0x232d SCHED_UNLOCK 0x00000001 0x00000000
> 133 0e 0x2344 ALARM_INIT 0x020f3080 0x00000000
> 134 0e 0x234a ALARM_TRIGGER 0x00000af6 0x00000000
> 135 0e 0x234f ALARM_INTERVAL 0x00000000 0x00000000
> 136 0e 0x2358 SCHED_LOCK 0x00000001 0x00000000
> 137 0e 0x2360 ALARM_ADD 0x020eb158 0x020f3080
> 138 0e 0x237f SCHED_UNLOCK 0x00000001 0x00000000
> 139 0e 0x2396 SCHED_LOCK 0x00000001 0x00000000
> 140 0e 0x239e SCHED_LOCK 0x00000002 0x00000000
> 141 0e 0x23a4 SCHED_UNLOCK 0x00000002 0x00000000
> 142 0e 0x23b0 THREAD_SLEEP 0x020ff280 0x00000000
> 143 0e 0x23b7 SCHED_LOCK 0x00000002 0x00000000
> 144 0e 0x23c2 SCHED_UNLOCK 0x00000002 0x00000000
> 145 0e 0x23cc SCHED_RESCHEDULE 0x00000001 0x00000000
> 146 0e 0x23d4 SCHED_RESCHEDULE 0x00000000 0x00000000
> 147 0e 0x23e5 THREAD_SWITCH 0x020ff280 0x0211dea0
>
> 148 06 0x23fc INTR_RESTORE 0x00000012 0x00000000
> 149 06 0x24e9 SCHED_LOCK 0x00000001 0x00000000
> 150 06 0x24ef MUTEX_UNLOCK 0x0211de80 0x00000000
> 151 06 0x24f8 SCHED_UNLOCK 0x00000001 0x00000000
> 152 06 0x250c SCHED_LOCK 0x00000001 0x00000000
> 153 06 0x2514 SCHED_LOCK 0x00000002 0x00000000
> 154 06 0x251b SCHED_UNLOCK 0x00000002 0x00000000
> 155 06 0x2527 THREAD_SLEEP 0x0211dea0 0x00000000
> 156 06 0x252e SCHED_LOCK 0x00000002 0x00000000
> 157 06 0x2538 SCHED_UNLOCK 0x00000002 0x00000000
> 158 06 0x2543 SCHED_RESCHEDULE 0x00000001 0x00000000
> 159 06 0x254a SCHED_RESCHEDULE 0x00000000 0x00000000
> 160 06 0x2567 THREAD_SWITCH 0x0211dea0 0x0208cea4
It looks like you get into trouble at 152, 153. There is a
SCHED_UNLOCK missing.
However its hard to tell what is going on here. You could change
packages/kernel/current/include/sched.inl
CYG_INSTRUMENT_SCHED(LOCK,get_sched_lock(),0);
to
CYG_INSTRUMENT_SCHED(LOCK,get_sched_lock(),__builtin_return_address(0));
and the same with the UNLOCK call. You can then get the address of
what called the lock and unlock functions.
You might also want to enabled more instrumentation calls.
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [ECOS] Task switching problem
2005-07-04 11:13 ` Andrew Lunn
@ 2005-07-05 3:51 ` Yuriy Coureelo
2005-07-05 7:24 ` Andrew Lunn
0 siblings, 1 reply; 7+ messages in thread
From: Yuriy Coureelo @ 2005-07-05 3:51 UTC (permalink / raw)
To: ecos-discuss
Dear Sir!
AL> It looks like you get into trouble at 152, 153. There is a
AL> SCHED_UNLOCK missing.
Let's take a look at the group of lines 152-160
The same situation is at lines 139-147, 66-74, 35-43, but there
everything is ok.
AL> You might also want to enabled more instrumentation calls.
all the instrumentations are enabled
AL> However its hard to tell what is going on here. You could change
AL> packages/kernel/current/include/sched.inl
AL> CYG_INSTRUMENT_SCHED(LOCK,get_sched_lock(),0);
AL> to
AL> CYG_INSTRUMENT_SCHED(LOCK,get_sched_lock(),__builtin_return_address(0));
AL> and the same with the UNLOCK call. You can then get the address of
AL> what called the lock and unlock functions.
ok, done, got this:
Num Thread Time Arg1 Arg2
149 06 0x1d90 SCHED_LOCK 0x00000001 0x020053d4 radiorx_data()
150 06 0x1d96 MUTEX_UNLOCK 0x0211dfc0 0x00000000 radio_mutex
151 06 0x1d9f SCHED_UNLOCK 0x00000001 0x020053d4 radiorx_data()
152 06 0x1db4 SCHED_LOCK 0x00000001 0x020054c4 radioErx_proc()
153 06 0x1dbc SCHED_LOCK 0x00000002 0x0201adbc _flagwait
154 06 0x1dc3 SCHED_UNLOCK 0x00000002 0x0201adbc _flagwait
155 06 0x1dcf THREAD_SLEEP 0x0211dfe0 0x00000000 radioErx_thread
156 06 0x1dd6 SCHED_LOCK 0x00000002 0x0201ae3c _flagwait
157 06 0x1de0 SCHED_UNLOCK 0x00000002 0x0201ae3c _flagwait
158 06 0x1dea SCHED_RESCHEDULE 0x00000001 0x00000000
159 06 0x1df2 SCHED_RESCHEDULE 0x00000000 0x00000000
160 06 0x1e0f THREAD_SWITCH 0x0211dfe0 0x0208cfe4 radioErx_thread => idle_thread
161 01 0x1e27 INTR_RESTORE 0x00000000 0x00000000
162 01 0x1d72 INTR_MASK 0x00000000 0x00000000
163 01 0x1d7b INT_ACK 0x00000000 0x00000000
164 01 0x1d8a INTR_END 0x00000000 0x00000003
165 01 0x1d91 INTR_POST_DSR 0x00000000 0x00000000
166 01 0x1d99 SCHED_UNLOCK 0x00000002 0x02000538 return_from_exception
167 01 0x1da1 INTR_RESTORE 0x00000000 0x00000000
here all stops, no more messages, processor hangs (?)
Function radiorx_data() works with mutex, unlocks it (...149-151).
Then radiorx_data() returns to radioErx_proc() thread function.
radioErx_proc() begins waiting on flag (152-157), so it's correct
number of SCHED_LOCKs.
Can't understand anything :(((
Sincerely yours
Yuriy Coureelo
------------------------
Engineer
Telecommunication Equipment Division
Micran Company
Tomsk, Russia
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Task switching problem
2005-07-05 3:51 ` Yuriy Coureelo
@ 2005-07-05 7:24 ` Andrew Lunn
2005-07-07 5:33 ` Yuriy Coureelo
0 siblings, 1 reply; 7+ messages in thread
From: Andrew Lunn @ 2005-07-05 7:24 UTC (permalink / raw)
To: Yuriy Coureelo; +Cc: ecos-discuss
On Tue, Jul 05, 2005 at 10:51:05AM +0600, Yuriy Coureelo wrote:
> Dear Sir!
>
> AL> It looks like you get into trouble at 152, 153. There is a
> AL> SCHED_UNLOCK missing.
> Let's take a look at the group of lines 152-160
> The same situation is at lines 139-147, 66-74, 35-43, but there
> everything is ok.
>
> AL> You might also want to enabled more instrumentation calls.
> all the instrumentations are enabled
>
> AL> However its hard to tell what is going on here. You could change
> AL> packages/kernel/current/include/sched.inl
> AL> CYG_INSTRUMENT_SCHED(LOCK,get_sched_lock(),0);
> AL> to
> AL> CYG_INSTRUMENT_SCHED(LOCK,get_sched_lock(),__builtin_return_address(0));
> AL> and the same with the UNLOCK call. You can then get the address of
> AL> what called the lock and unlock functions.
> ok, done, got this:
Do you have assertions enabled? That might also give a clue as to what
is happening. CYGPKG_INFRA_DEBUG is what you need.
>
> Num Thread Time Arg1 Arg2
> 149 06 0x1d90 SCHED_LOCK 0x00000001 0x020053d4 radiorx_data()
> 150 06 0x1d96 MUTEX_UNLOCK 0x0211dfc0 0x00000000 radio_mutex
> 151 06 0x1d9f SCHED_UNLOCK 0x00000001 0x020053d4 radiorx_data()
> 152 06 0x1db4 SCHED_LOCK 0x00000001 0x020054c4 radioErx_proc()
> 153 06 0x1dbc SCHED_LOCK 0x00000002 0x0201adbc _flagwait
> 154 06 0x1dc3 SCHED_UNLOCK 0x00000002 0x0201adbc _flagwait
> 155 06 0x1dcf THREAD_SLEEP 0x0211dfe0 0x00000000 radioErx_thread
> 156 06 0x1dd6 SCHED_LOCK 0x00000002 0x0201ae3c _flagwait
> 157 06 0x1de0 SCHED_UNLOCK 0x00000002 0x0201ae3c _flagwait
> 158 06 0x1dea SCHED_RESCHEDULE 0x00000001 0x00000000
> 159 06 0x1df2 SCHED_RESCHEDULE 0x00000000 0x00000000
> 160 06 0x1e0f THREAD_SWITCH 0x0211dfe0 0x0208cfe4 radioErx_thread => idle_thread
What is happening at 152? Is your code locking the schedular before
calling the flag_wait function?
Andrew
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [ECOS] Task switching problem
2005-07-05 7:24 ` Andrew Lunn
@ 2005-07-07 5:33 ` Yuriy Coureelo
0 siblings, 0 replies; 7+ messages in thread
From: Yuriy Coureelo @ 2005-07-07 5:33 UTC (permalink / raw)
To: ecos-discuss
Dear Sir!
AL> Do you have assertions enabled? That might also give a clue as to what
AL> is happening. CYGPKG_INFRA_DEBUG is what you need.
>>
>> Num Thread Time Arg1 Arg2
>> 149 06 0x1d90 SCHED_LOCK 0x00000001 0x020053d4 radiorx_data()
>> 150 06 0x1d96 MUTEX_UNLOCK 0x0211dfc0 0x00000000 radio_mutex
>> 151 06 0x1d9f SCHED_UNLOCK 0x00000001 0x020053d4 radiorx_data()
>> 152 06 0x1db4 SCHED_LOCK 0x00000001 0x020054c4 radioErx_proc()
>> 153 06 0x1dbc SCHED_LOCK 0x00000002 0x0201adbc _flagwait
>> 154 06 0x1dc3 SCHED_UNLOCK 0x00000002 0x0201adbc _flagwait
>> 155 06 0x1dcf THREAD_SLEEP 0x0211dfe0 0x00000000 radioErx_thread
>> 156 06 0x1dd6 SCHED_LOCK 0x00000002 0x0201ae3c _flagwait
>> 157 06 0x1de0 SCHED_UNLOCK 0x00000002 0x0201ae3c _flagwait
>> 158 06 0x1dea SCHED_RESCHEDULE 0x00000001 0x00000000
>> 159 06 0x1df2 SCHED_RESCHEDULE 0x00000000 0x00000000
>> 160 06 0x1e0f THREAD_SWITCH 0x0211dfe0 0x0208cfe4 radioErx_thread => idle_thread
AL> What is happening at 152? Is your code locking the schedular before
AL> calling the flag_wait function?
It's ok. Flagwait piece of code works that way.
In file packages/hal/arm/arch/current/src/vectors.s
line something about 780 contains:
#ifdef CYGFUN_HAL_COMMON_KERNEL_SUPPORT
.extern cyg_scheduler_sched_lock
ldr r3,.cyg_scheduler_sched_lock
ldr r4,[r3]
add r4,r4,#1
str r4,[r3]
#endif
I inserted before this construction checkpoint, which just puts a
byte 0xCC (into my check buffer) each time.
Finally, buffer shows following info:
correct situation:
0xCC
0xAA - this was put by interrupt_end(), beginning
0x01 - scheduler lock at the beginning of interrupt_end()
0x00 - scheduler lock at the end of interrupt_end()
0xBB - this was put by interrupt_end(), end
incorrect and nothing more after that:
0xCC
0xCC
0xAA - this was put by interrupt_end(), beginning
0x02 - scheduler lock at the beginning of interrupt_end()
0x01 - scheduler lock at the end of interrupt_end()
0xBB - this was put by interrupt_end(), end
0xCC was put twice! How is it possible? Interrupts are disabled at
this stage. Am I right?
Sincerely yours
Yuriy Coureelo
------------------------
Engineer
Telecommunication Equipment Division
Micran Company
Tomsk, Russia
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-07-07 5:33 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-07-01 8:59 [ECOS] Task switching problem Yuriy Coureelo
2005-07-01 10:53 ` Andrew Lunn
2005-07-04 10:22 ` Re[2]: " Yuriy Coureelo
2005-07-04 11:13 ` Andrew Lunn
2005-07-05 3:51 ` Yuriy Coureelo
2005-07-05 7:24 ` Andrew Lunn
2005-07-07 5:33 ` Yuriy Coureelo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).