On Feb 15, 2014, at 09:56 , Peter Dufault <dufa...@hda.com> wrote: > -- sp02, try increasing the number of tasks to 8 (optimization on): Gets an > exception, not clear where, the stack trace is below. Setting a hardware > breakpoint where _Thread_Start_multitasking() returns doesn't break there, as > it seemed to yesterday. I'll try to look some more later, I'll probably > rebuild without optimization (for debugging ease) and start stepping through > sp02 to see why it is failing with the number of tasks set to 4.
This post has a summary of what I found today (nothing), a question about if the jumbled ".scn" test results are expected (probably), and a question about RTEMS test results and if they are regularly reported on-line. I rebuilt RTEMS without optimization. SP02 fails as before with number of tasks set to 4: it fails trying to start task TA3 with RTEMS_TOO_MANY, as before, though code inspection shows it should have enough tasks (assuming idle and init tasks don't count). Increase number of tasks to 8 and it doesn't fail, and it doesn't cause an exception (as it did with optimization on), but nothing happens, it gets as far as: *** TEST 2 *** INIT - rtems_task_wake_after - yielding processor PREEMPT - rtems_task_delete - deleting selfINIT - suspending TA2 while middle task on a ready chain and then when I break into the debugger it is in the idle thread. Note that the task didn't exit (which would invoke bsp_reset), it's running but nothing is happening. (gdb) where #0 0x000138b0 in mpc55xx_wait_for_interrupt () at ../../../../../.././phycore_mpc5554/lib/include/mpc55xx/mpc55xx.h:140 #1 0x000138d8 in bsp_idle_thread (arg=0x0) at ../../../../../../../../rtems/c/src/lib/libbsp/powerpc/mpc55xxevb/startup/idle-thread.c:30 #2 0x00043750 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:188 #3 0x000436bc in _Thread_Handler_is_constructor_execution_required ( executing=0x7 <bsp_section_start_begin+7>) at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:82 Backtrace stopped: frame did not save the PC (gdb) - Are there instructions on dumping RTEMS state (what's blocked on what) from within GDB? I went on to try sp03,4,5,6,7,... and all worked OK up to 7. sp07 didn't work but the serial port output is pretty confused: *** TEST 7 *** rtems_extension_create - bad id pointer -- RTEMS_INVALID_ADDRESS rtems_extension_create - bad name -- RTEMS_INVALID_NAME rtems_extension_create - first one -- OK rtems_extension_create - second one-- OK rtems_extension_create -- RTEMS_TOO_MANY rtems_extension_delete - second one -- OK rtems_extension_delete - second one again -- RTEMS_INVALID_ID rtems_extension_ident -- OK rtems_extension_ident - bad name -- RTEMS_INVALID_NAME rtems_extension_ident - bad name -- RTEMS_INVALID_ADDRESS rtems_extension_create - harmless -- OK TASK_CREATE - TA1 - created TASK_CREATE<pause> TA2 - rtems_task_get_note - get RTEMS_NOTEPAD_8 - current priority: -TA1 - rtems_task_set_priority - get inid T0ASK_CREATE -4 TA3 - created TASKTA1 - rtems_task_get_note - get RTEMS_NOTEPAD_8 - current priority: _TA2 - rtems_task_set_note - set TA1'e d TASK_STARTTA1 - rtems_task_set_note - set TA2's RTEMS_NOTEPAD_8: -- TA1 - star1ted T-AS1K_START - TA 2 - started TASK_STTA1 - rtems_task_set_priority - set TA2's priority: ATA2 - rtems_task_set_priority - set TA1's prioritd TASK_START - TA4 - s tarted rtems_task_set_priorityT-ASK_RESTAR1T - T A3 - restarted INIT - rtems_task_set_note - set my (id) RTEMS_NOTEPAD_4 rtems_task_set_priorityto TA1's priority: 04 FAILED ( FAILED -- expected (INIT - rtems_task_set_note - set my (SELF) RTEMS_NOTEPAD_4 RTEMS_SUCCESSFULto TA1's prioL ) got (INIT - rtems_task_set_note - set TA1's RTEMS_NOTEPAD_8 ) got (to TA1's priority: 04RTEMS_INVALID_PRIORY RTEMS_INVALID_PRIORITYINIT - rtems_task_se - Is the serial port mixup output expected? I understand if it is, but if it's unexpected I'd like to fix it. - Are these "SPXX" tests run on a regular basis so I can see the status of other platforms? I looked at what's linked to from "coverage results" on the RTEMS main page hoping to find the latest runs but those tests haven't been run in a while - December 2012 for PowerPC. Are the tests in the "sptests" directory run regularly, and are the results posted on-line? Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
