Failure in cpukit/score/src/rbtreeextract.c if RTEMS_DEBUG is defined
Heinz Junkes
junkes at fhi-berlin.mpg.de
Mon Feb 17 14:45:11 UTC 2020
I have just tried out some tests from the testsuite. It doesn't look so good. Unfortunately many of them get stuck or cause a crash.
Also with some of the working tests I see the following output:
[zone: unpcb] kern.ipc.maxsockets limit reached
Can I configure the number of IPC_MAX_SOCKETS in RTEMS?
Working test, but with the message from above:
MVME2500=> setenv tfile unix01
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 32 ms (377 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'unix01.img'.
Load address: 0x10000000
Loading: #####################################
10.6 MiB/s
done
Bytes transferred = 533329 (82351 hex)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 10000000 ...
Image Name: unix01
Created: 2020-02-17 13:51:56 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 533265 Bytes = 520.8 KiB
Load Address: 00004000
Entry Point: 00004000
Verifying Checksum ... OK
## Flattened Device Tree blob at 20000000
Booting using the fdt blob at 0x20000000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK
*** LIBBSD UNIX 1 TEST ***
nexus0: <RTEMS Nexus device>
test UNIX(4) socket, without resource check
[zone: unpcb] kern.ipc.maxsockets limit reached
test UNIX(4) socket, with resource check
test UNIX(4) read/write not connected
test UNIX(4) bind, without close before unlink
test UNIX(4) bind, with close before unlink
test UNIX(4) listen/connect/accept/write/read
STACK USAGE BY THREAD
ID NAME LOW HIGH CURRENT AVAIL USED
0x09010001 IDLE 0x0204e570 0x0205056f 0x02050470 8064 320
0x0a010001 UI1 0x02050978 0x02058977 0x020582f0 32640 1888
0x0a010002 TIME 0x020592a0 0x0206129f 0x020611d0 32640 400
0x0a010003 IRQS 0x020612c8 0x020692c7 0x020691f0 32640 280
0x0a010004 config_0 0x0207bc38 0x02083c37 0x02083b50 32640 296
0x0a010005 swi5: fast task 0x02083ee8 0x0208bee7 0x0208bdf0 32640 312
0x0a010006 thread taskq 0x0208c070 0x0209406f 0x02093f90 32640 288
0x0a010007 swi6: Giant tas 0x02094320 0x0209c31f 0x0209c230 32640 304
0x0a010008 swi6: task queu 0x0209c5d0 0x020a45cf 0x020a44e0 32640 304
0x0a010009 kqueue_ctx task 0x020a4758 0x020ac757 0x020ac670 32640 296
0x0a01000a swi1: netisr 0 0x020ac948 0x020b4947 0x020b4850 32640 312
0x0a01000b softirq_0 0x020ccd00 0x020d4cff 0x020d4c20 32640 288
0x00000000 Interrupt Stack 0x0204c500 0x0204e4ff 0x00000000 8064 344
*** END OF TEST LIBBSD UNIX 1 ***
*** FATAL ***
fatal source: 5 (RTEMS_FATAL_SOURCE_EXIT)
fatal code: 0 (0x00000000)
Test that gets stuck:
MVME2500=> setenv tfile dhcpcd02
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 32 ms (377 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'dhcpcd02.img'.
Load address: 0x10000000
Loading: #################################################################
###################################
10.4 MiB/s
done
Bytes transferred = 1455058 (1633d2 hex)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 10000000 ...
Image Name: dhcpcd02
Created: 2020-02-17 13:51:47 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1454994 Bytes = 1.4 MiB
Load Address: 00004000
Entry Point: 00004000
Verifying Checksum ... OK
## Flattened Device Tree blob at 20000000
Booting using the fdt blob at 0x20000000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK
*** LIBBSD DHCPCD 2 TEST ***
nexus0: <RTEMS Nexus device>
RTEMS Shell on /dev/console. Useo 'help' to list commands.
SHLL [/] # bus0: <Open Firmware Device Tree> on nexus0
simplebus0: <Flattened device tree simple bus> on ofwbus0
simplebus1: <Flattened device tree simple bus> mem 0xffe05000-0xffe05fff irq 3 on ofwbus0
tsec0: <Enhanced Three-Speed Ethernet Controller> mem 0x24000-0x24fff irq 13,14,18 on simplebus0
miibus0: <MII bus> on tsec0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
info: tsec0: Ethernet address: ec:9e:cd:19:3c:61
tsec1: <Enhanced Three-Speed Ethernet Controller> mem 0x25000-0x25fff irq 19,20,24 on simplebus0
miibus1: <MII bus> on tsec1
ukphy1: <Generic IEEE 802.3u media interface> PHY 7 on miibus1
ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
info: tsec1: Ethernet address: ec:9e:cd:19:3c:62
tsec2: <Enhanced Three-Speed Ethernet Controller> mem 0x26000-0x26fff irq 15,16,17 on simplebus0
miibus2: <MII bus> on tsec2
ukphy2: <Generic IEEE 802.3u media interface> PHY 3 on miibus2
ukphy2: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto
info: tsec2: Ethernet address: ec:9e:cd:19:3c:63
[zone: unpcb] kern.ipc.maxsockets limit reached
info: lo0: link state changed to UP
info: version 6.2.1 starting
info: tsec0: link state changed to DOWN
info: tsec1: link state changed to DOWN
info: tsec2: link state changed to DOWN
warning: no interfaces have a carrier
info: tsec0: waiting for carrier
info: tsec1: waiting for carrier
info: tsec2: waiting for carrier
info: tsec0: link state changed to UP
info: tsec0: carrier acquired
info: DUID 00:01:00:01:e9:6d:a1:84:ec:9e:cd:19:3c:61
info: tsec0: IAID cd:19:3c:61
info: tsec1: link state changed to UP
info: tsec0: soliciting an IPv6 router
debug: tsec0: delaying Router Solicitation for LL address
debug: tsec0: using ClientID 00:6c:69:62:62:73:64:20:74:65:73:74:20:63:6c:69:65:6e:74
info: tsec0: probing for an IPv4LL address
debug: tsec0: checking for 169.254.50.93
debug: tsec0: sending ARP probe (1 of 3), next in %0.1f seconds
info: tsec1: carrier acquired
info: tsec1: IAID cd:19:3c:62
info: tsec1: soliciting an IPv6 router
debug: tsec1: delaying Router Solicitation for LL address
debug: tsec1: using ClientID 00:6c:69:62:62:73:64:20:74:65:73:74:20:63:6c:69:65:6e:74
info: tsec1: probing for an IPv4LL address
debug: tsec1: checking for 169.254.125.113
debug: tsec1: sending ARP probe (1 of 3), next in %0.1f seconds
ɽ���(2 of 3), next in %0.1f seconds
debug: tsec0: sending ARP probe (2 of 3), next in %0.1f seconds
debug: tsec0: sending ARP probe (3 of 3), next in %0.1f seconds
debug: tsec1: sending ARP probe (3 of 3), next in %0.1f seconds
��ͥ���IPv4LL address 169.254.50.93
debug: tsec0: adding IP address 169.254.50.93/16
info: tsec0: adding host route to 169.254.50.93 via 127.0.0.1
err: tsec0: ipv4_addroute: File exists
info: tsec0: adding route to 169.254.0.0/16
err: tsec0: ipv4_addroute: File exists
debug: tsec0: writing lease `/var/db/dhcpcd-tsec0.lease'
debug: tsec0: sending ARP announce (1 of 2), next in 2.0 seconds
info: tsec1: using IPv4LL address 169.254.125.113
debug: tsec1: adding IP address 169.254.125.113/16
info: tsec0: adding host route to 169.254.50.93 via 127.0.0.1
err: tsec0: ipv4_addroute: File exists
info: tsec0: adding route to 169.254.0.0/16
err: tsec0: ipv4_addroute: File exists
info: tsec1: adding host route to 169.254.125.113 via 127.0.0.1
err: tsec1: ipv4_addroute: File exists
info: tsec1: adding route to 169.254.0.0/16
err: tsec1: ipv4_addroute: File exists
debug: tsec1: writing lease `/var/db/dhcpcd-tsec1.lease'
debug: tsec1: sending ARP announce (1 of 2), next in 2.0 seconds
debug: tsec0: sending ARP announce (2 of 2)
debug: tsec1: sending ARP announce (2 of 2)
Test with crash:
MVME2500=> setenv tfile sleep01
MVME2500=> run rtems_myTests
reading mvme2500.dtb
12363 bytes read in 32 ms (377 KiB/s)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 141.14.128.9; our IP address is 141.14.128.89
Filename 'sleep01.img'.
Load address: 0x10000000
Loading: #####################################
10.3 MiB/s
done
Bytes transferred = 529900 (815ec hex)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 10000000 ...
Image Name: sleep01
Created: 2020-02-17 13:51:51 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 529836 Bytes = 517.4 KiB
Load Address: 00004000
Entry Point: 00004000
Verifying Checksum ... OK
## Flattened Device Tree blob at 20000000
Booting using the fdt blob at 0x20000000
Uncompressing Kernel Image ... OK
Loading Device Tree to 03ff9000, end 03fff04a ... OK
*** LIBBSD SLEEP 1 TEST ***
nexus0: <RTEMS Nexus device>
slave[2]: 1
test timeouts
slave[1]: 2
slave[0]: 3
test wakeup without waiter
test wakeup one
slave[2]: 4
slave[2]: 5
test waassertion "rtems_resource_snapshot_check(&snapshot)" failed: file "../../testsuite/sleep01/test_main.c", line 229, function: test_main
*** FATAL ***
fatal source: 7 (RTEMS_FATAL_SOURCE_ASSERT)
fatal code: 33917016 (0x02058858)
Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.
> On 13. Feb 2020, at 21:17, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>
> On 13/02/2020 17:56, Heinz Junkes wrote:
>
>> I'm starting an EPICS IOC. Loading works if I don't set RTEMS_DEBUG.
>> The loaded images are similar in size.
>> I have not changed anything in the EPICS software. I still have the problem that I do not understand
>> how the freebsd dhcpcd works and therefore wanted to set RTEMS_DEBUG to get more detailed output.
> Did you check some tests of the RTEMS test suite? Did you enable the stack checker? How many file descriptors did you configure?
>
> Without a debugger I would use the following approach:
>
> * compile libbsd/application with --finstrument-functions,
>
> * enable the event recording,
>
> * dump the event records in base64 encoding in the fatal error handler,
>
> * add support for base64 encoded data to the rtems-record-lttng converter, and
>
> * view the trace with babeltrace or Trace Compass.
>
> __attribute__((__no_instrument_function__)) void __cyg_profile_func_enter(void* this_fn, void* call_site)
> {
> rtems_record_produce_2(RTEMS_RECORD_CALLER,
> (rtems_record_data)call_site, RTEMS_RECORD_FUNCTION_ENTRY,
> (rtems_record_data)this_fn);
>
> }
>
> __attribute__((__no_instrument_function__)) void __cyg_profile_func_exit(void* this_fn, void* call_site)
> {
> rtems_record_produce(RTEMS_RECORD_FUNCTION_EXIT, (rtems_record_data)this_fn);
> }
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5300 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20200217/d9e3dfcb/attachment.bin>
More information about the users
mailing list