From g.weber at hi-jena.gsi.de Mon Jul 15 15:16:10 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 15 Jul 2024 13:16:10 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER Message-ID: Dear all, I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). I followed the 'cooking receipt' that I git from Hakan, as always. When compiling fuser_drasi, the following happens (on PC): (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. UDP:ARPA_INET_H build_cc_x86_64-linux-gnu_7_debug/nconf.args done. CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o f_user.c: In function ?f_user_init?: f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from incompatible pointer type [-Wincompatible-pointer-types] g_crate = nurdlib_setup(log_callback, path); ^~~~~~~~~~~~ In file included from f_user.c:15:0: ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void (*)(const char *, int, unsigned int, const char *)}? but argument is of type ?void (*)(const char *, unsigned int, unsigned int, const char *)? struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; ^~~~~~~~~~~~~ f_user.c:697:2: warning: null argument where non-null required (argument 3) [-Wnonnull] crate_dt_release_set_func(g_crate, dt_release, NULL); ^~~~~~~~~~~~~~~~~~~~~~~~~ CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) On the RIO4 the warning is a bit less detailed: RIO4-MCAL-1 mbsdaq > make fuser_drasi NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. UDP:ARPA_INET_H build_cc_ppc-linux_4.2.2_debug/nconf.args done. CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o f_user.c: In function 'f_user_init': f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from incompatible pointer type CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) Any ideas what might have happened here? Or is this normal behaviour? Many thanks! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Mon Jul 15 15:49:23 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Jul 2024 15:49:23 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: References: Message-ID: <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se> Dear G?nter, it looks like with a change of the second parameter of log_callback (both in prototype an definition) of r3bfuser/f_user.c from unsigned to int, then in compiles. Likely caused by commit '36772113' in nurdlib that changed line numbers from unsigned to int. Cheers, H?kan On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > Dear all, > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > When compiling fuser_drasi, the following happens (on PC): > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > fuser_drasi > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > For nconf results and logs, see also > build_cc_x86_64-linux-gnu_7_debug/nconf*. > UDP:ARPA_INET_H > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > f_user.c: In function ?f_user_init?: > f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from > incompatible pointer type [-Wincompatible-pointer-types] > ? g_crate = nurdlib_setup(log_callback, path); > ????????????????????????? ^~~~~~~~~~~~ > In file included from f_user.c:15:0: > ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void > (*)(const char *, int,? unsigned int,? const char *)}? but argument is of > type ?void (*)(const char *, unsigned int,? unsigned int,? const char *)? > ?struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > ?????????????? ^~~~~~~~~~~~~ > f_user.c:697:2: warning: null argument where non-null required (argument 3) > [-Wnonnull] > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > On the RIO4 the warning is a bit less detailed: > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > UDP:ARPA_INET_H > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > f_user.c: In function 'f_user_init': > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > incompatible pointer type > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > Any ideas what might have happened here? Or is this normal behaviour? > > > > Many thanks! > > > > > > Best greetings > > G?nter > > > > > > > From f96hajo at chalmers.se Mon Jul 15 15:51:50 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Jul 2024 15:51:50 +0200 Subject: [subexp-daq] NURDLIB - SIS3316 - major rework of check_hit In-Reply-To: <25eb8fb4-5175-4e80-beca-369124e99a64@chalmers.se> References: <2c3831fdce994d1b8d166f1b02275ba0@hi-jena.gsi.de> <25eb8fb4-5175-4e80-beca-369124e99a64@chalmers.se> Message-ID: Dear G?nter, I guess the branch SIS3316_check_hit_reworked_rebased has now seen some use, such that it can be assumed to work and merged? Cheers, H?kan On Fri, 14 Jun 2024, Hans Toshihide T?rnqvist wrote: > Dear G?nter, > > I had a look, it seemed fine. > > There is a rebased version against the current main: > SIS3316_check_hit_reworked_rebased > > Due to some new safety checks, I had to remove a sis3316-only config > function and instead rely on common existing config functions, so please > try it out and see that it works ok. If this runs I will put all of it > in 'main'! > > Best regards, > Hans > > > On 2024-06-10 18:54, Weber, Guenter Dr. wrote: >> Dear all, >> >> >> I just pushed a new version of the sis3316.c, where check_hit was >> rewritten. The reason was that the existing code did not work together >> with the discard option for the channel readout. Please note that in >> readout_dma I am now using an excess bit (not necessary to represent >> even the largest number of raw sample words possible) to store the >> information that an event was discarded. This is then used in check_event. >> >> >> As I did a lot of changes, please have an extra close look at the code. >> >> >> If everyone is happy with the new check_event, I will also make changes >> to the discard routine in readout_dma as at the moment, some assumptions >> on the settings of the module are hard coded - at least that is my >> impression at the moment. >> >> >> >> >> Thanks a lot! >> >> >> >> >> Best greetings >> >> G?nter >> >> >> > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > From g.weber at hi-jena.gsi.de Mon Jul 15 16:02:57 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 15 Jul 2024 14:02:57 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se> Message-ID: Dear H?kan, thank you for the reply. After implementing the suggested changes, I now get the following warning (on PC): (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. UDP:ARPA_INET_H build_cc_x86_64-linux-gnu_7_debug/nconf.args done. CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o f_user.c: In function ?f_user_init?: f_user.c:697:2: warning: null argument where non-null required (argument 3) [-Wnonnull] crate_dt_release_set_func(g_crate, dt_release, NULL); ^~~~~~~~~~~~~~~~~~~~~~~~~ CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) On the RIO4 there is no warning: RIO4-MCAL-1 mbsdaq > make fuser_drasi NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. UDP:ARPA_INET_H build_cc_ppc-linux_4.2.2_debug/nconf.args done. CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) In a few minutes I can tell you if the DAQ is running with the new software or not. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 15. Juli 2024 15:49:23 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER Dear G?nter, it looks like with a change of the second parameter of log_callback (both in prototype an definition) of r3bfuser/f_user.c from unsigned to int, then in compiles. Likely caused by commit '36772113' in nurdlib that changed line numbers from unsigned to int. Cheers, H?kan On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > Dear all, > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > When compiling fuser_drasi, the following happens (on PC): > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > fuser_drasi > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > For nconf results and logs, see also > build_cc_x86_64-linux-gnu_7_debug/nconf*. > UDP:ARPA_INET_H > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > f_user.c: In function ?f_user_init?: > f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from > incompatible pointer type [-Wincompatible-pointer-types] > g_crate = nurdlib_setup(log_callback, path); > ^~~~~~~~~~~~ > In file included from f_user.c:15:0: > ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void > (*)(const char *, int, unsigned int, const char *)}? but argument is of > type ?void (*)(const char *, unsigned int, unsigned int, const char *)? > struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > ^~~~~~~~~~~~~ > f_user.c:697:2: warning: null argument where non-null required (argument 3) > [-Wnonnull] > crate_dt_release_set_func(g_crate, dt_release, NULL); > ^~~~~~~~~~~~~~~~~~~~~~~~~ > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > On the RIO4 the warning is a bit less detailed: > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > UDP:ARPA_INET_H > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > f_user.c: In function 'f_user_init': > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > incompatible pointer type > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > Any ideas what might have happened here? Or is this normal behaviour? > > > > Many thanks! > > > > > > Best greetings > > G?nter > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Mon Jul 15 16:13:07 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 15 Jul 2024 14:13:07 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, Message-ID: <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de> Dear friends, unfortunately, the DAQ crashes on startup. Here is the output: 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). Message not logged - thread has no error buffer yet... CPUS: 1 delay: 1 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). Message not logged - thread has no error buffer yet... HOST: RIO4-MCAL-1 Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 (eth1). 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 419430400 = 0x19000000, 1 consumers. 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). client union size: 244 240 188 508 640 204 204 => 640 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 10: lwroc_main.c:704: Log message rate limit in effect. 10: lwroc_readout.c:116: call readout_init... 10: lwroc_thread_util.c:118: This is the triva control thread! 10: lwroc_thread_util.c:118: This is the net io thread! 10: lwroc_thread_util.c:118: This is the slow_async thread! 10: lwroc_thread_util.c:118: This is the data server thread! 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB connection(s): 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) 10: lwroc_message_internal.c:485: Message client connected! 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) [192.168.1.1]. 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) 10: lwroc_triva_control.c:418: Minimum event time ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) 10: lwroc_triva_state.c:1486: (Re)send ident messages... 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 9: lwroc_triva_control.c:507: TEST: GO 10: lwroc_triva_control.c:725: RUN: RESET 10: lwroc_triva_control.c:729: RUN: MT=14 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 2.8 kHz) 10: lwroc_triva_readout.c:376: Trigger 14 seen. 10: config/config.c:205: Will try default cfg path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: config/parser.c:319: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { 10: config/parser.c:331: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } 10: config/parser.c:319: Opened './main.cfg' { 10: config/config.c:1388: .Global log level=verbose. 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } 10: config/parser.c:331: Closed './main.cfg' } 10: crate/crate.c:373: crate_create { 10: crate/crate.c:714: crate_create(MCAL) } 10: crate/crate.c:1022: crate_init(MCAL) { 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns wr(0x30000000+0x64/32)=356ns. 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns wr(0x31000000+0x64/32)=359ns. 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns wr(0x32000000+0x64/32)=399ns. 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. 10: crate/crate.c:1196: crate_init(MCAL) } 10: ctrl/ctrl.c:1046: Control server online. Message not logged - thread has no error buffer yet... 10: f_user.c:559: WR ID=0x200. 10: f_user.c:565: TS offset unset. Will not modify stamp. 10: f_user.c:572: TPAT: No. 10: f_user.c:573: Sync-check: No. 10: f_user.c:575: Spill triggers: No. 10: f_user.c:576: LMU: No. 10: f_user.c:577: Timer latches: No. 10: f_user.c:578: Spill shape: No. 10: f_user.c:579: Micro-structure: No. 10: f_user.c:581: Multi-event flag: No. 10: f_user.c:586: UDP destination: None. 1: lwroc_main.c:132: SIGSEGV received. 1: -:0: Backtrace: 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] 1: -:0: [0x100344] 1: -:0: [(nil)] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] 1: -:0: /lib/libc.so.6 [0xfb91260] 1: -:0: /lib/libc.so.6 [0xfb913ec] 1: -:0: Backtrace (again, with addr2line): 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 1: -:0: ?? ??:0 sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 2 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 1: -:0: ?? ??:0 1: -:0: ?? ??:0 1: -:0: Backtrace (again, addresses): 1: -:0: 0x0x100ae20c: 1: -:0: 0x0x100ad56c: 1: -:0: 0x0x100ae518: 1: -:0: 0x0x100a6374: 1: -:0: 0x0x100344: 1: -:0: 0x(nil): 1: -:0: 0x0x100066c0: 1: -:0: 0x0x10073774: 1: -:0: 0x0x100a6e98: 1: -:0: 0x0x100a7f38: 1: -:0: 0x0x100a6890: 1: -:0: 0x0x100a5dc0: 1: -:0: 0x0xfb91260: 1: -:0: 0x0xfb913ec: 1: -:0: BUG or FATAL reported. 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. Send slave abort readout. (1) Send master abort (0x200). 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) 1: -:0: Hardware cleanup done. 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort test/readout: 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) ^C8: lwroc_main.c:105: SIGINT received. 10: lwroc_thread_util.c:62: Set terminate first! (main) ^C8: lwroc_main.c:105: SIGINT received. ^C5: lwroc_main.c:109: 3rd signal SIGINT received. Looks like DRASI still has a problem ? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von Weber, Guenter Dr. Gesendet: Montag, 15. Juli 2024 16:02:57 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER Dear H?kan, thank you for the reply. After implementing the suggested changes, I now get the following warning (on PC): (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. UDP:ARPA_INET_H build_cc_x86_64-linux-gnu_7_debug/nconf.args done. CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o f_user.c: In function ?f_user_init?: f_user.c:697:2: warning: null argument where non-null required (argument 3) [-Wnonnull] crate_dt_release_set_func(g_crate, dt_release, NULL); ^~~~~~~~~~~~~~~~~~~~~~~~~ CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) On the RIO4 there is no warning: RIO4-MCAL-1 mbsdaq > make fuser_drasi NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. UDP:ARPA_INET_H build_cc_ppc-linux_4.2.2_debug/nconf.args done. CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) In a few minutes I can tell you if the DAQ is running with the new software or not. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 15. Juli 2024 15:49:23 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER Dear G?nter, it looks like with a change of the second parameter of log_callback (both in prototype an definition) of r3bfuser/f_user.c from unsigned to int, then in compiles. Likely caused by commit '36772113' in nurdlib that changed line numbers from unsigned to int. Cheers, H?kan On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > Dear all, > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > When compiling fuser_drasi, the following happens (on PC): > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > fuser_drasi > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > For nconf results and logs, see also > build_cc_x86_64-linux-gnu_7_debug/nconf*. > UDP:ARPA_INET_H > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > f_user.c: In function ?f_user_init?: > f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from > incompatible pointer type [-Wincompatible-pointer-types] > g_crate = nurdlib_setup(log_callback, path); > ^~~~~~~~~~~~ > In file included from f_user.c:15:0: > ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void > (*)(const char *, int, unsigned int, const char *)}? but argument is of > type ?void (*)(const char *, unsigned int, unsigned int, const char *)? > struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > ^~~~~~~~~~~~~ > f_user.c:697:2: warning: null argument where non-null required (argument 3) > [-Wnonnull] > crate_dt_release_set_func(g_crate, dt_release, NULL); > ^~~~~~~~~~~~~~~~~~~~~~~~~ > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > On the RIO4 the warning is a bit less detailed: > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > UDP:ARPA_INET_H > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > f_user.c: In function 'f_user_init': > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > incompatible pointer type > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > Any ideas what might have happened here? Or is this normal behaviour? > > > > Many thanks! > > > > > > Best greetings > > G?nter > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.weber at hi-jena.gsi.de Mon Jul 15 16:14:31 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 15 Jul 2024 14:14:31 +0000 Subject: [subexp-daq] NURDLIB - SIS3316 - major rework of check_hit In-Reply-To: References: <2c3831fdce994d1b8d166f1b02275ba0@hi-jena.gsi.de> <25eb8fb4-5175-4e80-beca-369124e99a64@chalmers.se>, Message-ID: <6f15eaec255d4039b9a7bd8eeaec0c01@hi-jena.gsi.de> Dear H?kan, unfortunately, I am just now starting with the check and immediatly run into the compile problem from ~an hour ago. I will be on travel for the next two days, but if the DAQ is running again, we can do the checks within a day or two. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 15. Juli 2024 15:51:50 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] NURDLIB - SIS3316 - major rework of check_hit Dear G?nter, I guess the branch SIS3316_check_hit_reworked_rebased has now seen some use, such that it can be assumed to work and merged? Cheers, H?kan On Fri, 14 Jun 2024, Hans Toshihide T?rnqvist wrote: > Dear G?nter, > > I had a look, it seemed fine. > > There is a rebased version against the current main: > SIS3316_check_hit_reworked_rebased > > Due to some new safety checks, I had to remove a sis3316-only config > function and instead rely on common existing config functions, so please > try it out and see that it works ok. If this runs I will put all of it > in 'main'! > > Best regards, > Hans > > > On 2024-06-10 18:54, Weber, Guenter Dr. wrote: >> Dear all, >> >> >> I just pushed a new version of the sis3316.c, where check_hit was >> rewritten. The reason was that the existing code did not work together >> with the discard option for the channel readout. Please note that in >> readout_dma I am now using an excess bit (not necessary to represent >> even the largest number of raw sample words possible) to store the >> information that an event was discarded. This is then used in check_event. >> >> >> As I did a lot of changes, please have an extra close look at the code. >> >> >> If everyone is happy with the new check_event, I will also make changes >> to the discard routine in readout_dma as at the moment, some assumptions >> on the settings of the module are hard coded - at least that is my >> impression at the moment. >> >> >> >> >> Thanks a lot! >> >> >> >> >> Best greetings >> >> G?nter >> >> >> > -- > subexp-daq mailing list > subexp-daq at lists.chalmers.se > https://lists.chalmers.se/mailman/listinfo/subexp-daq > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Mon Jul 15 16:15:05 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Jul 2024 16:15:05 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se> Message-ID: I actually do not see that warning myself, even if nurlib during compilation says FUNC_NONNULL:YES Anyhow, I suspect that if you change in include/nurdlib/crate.h in the prototype of crate_dt_release_set_func to have FUNC_NONNULL((1,2)) instead of FUNC_NONNULL(()) then it might work. No doubt Hans will then make a more permanent fix... ;) Cheers, H?kan On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > thank you for the reply. > > > After implementing the suggested changes, I now get the following warning > (on PC): > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > fuser_drasi > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > For nconf results and logs, see also > build_cc_x86_64-linux-gnu_7_debug/nconf*. > UDP:ARPA_INET_H > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > f_user.c: In function ?f_user_init?: > f_user.c:697:2: warning: null argument where non-null required (argument 3) > [-Wnonnull] > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > On the RIO4 there is no warning: > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > UDP:ARPA_INET_H > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > In a few minutes I can tell you if the DAQ is running with the new software > or not. > > > > > > Best greetings > > G?nter > > > > > > ____________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan > T Johansson > Gesendet: Montag, 15. Juli 2024 15:49:23 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > Dear G?nter, > > it looks like with a change of the second parameter of log_callback (both > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > then in compiles. > > Likely caused by commit '36772113' in nurdlib that changed line numbers > from unsigned to int. > > Cheers, > H?kan > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear all, > > > > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, > etc.). > > > > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > > > > When compiling fuser_drasi, the following happens (on PC): > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > > fuser_drasi > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > For nconf results and logs, see also > > build_cc_x86_64-linux-gnu_7_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > f_user.c: In function ?f_user_init?: > > f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from > > incompatible pointer type [-Wincompatible-pointer-types] > > ? g_crate = nurdlib_setup(log_callback, path); > > ????????????????????????? ^~~~~~~~~~~~ > > In file included from f_user.c:15:0: > > ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void > > (*)(const char *, int,? unsigned int,? const char *)}? but argument is of > > type ?void (*)(const char *, unsigned int,? unsigned int,? const char *)? > > ?struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > > ?????????????? ^~~~~~~~~~~~~ > > f_user.c:697:2: warning: null argument where non-null required (argument > 3) > > [-Wnonnull] > > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > On the RIO4 the warning is a bit less detailed: > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > For nconf results and logs, see also > build_cc_ppc-linux_4.2.2_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > f_user.c: In function 'f_user_init': > > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > > incompatible pointer type > > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > Any ideas what might have happened here? Or is this normal behaviour? > > > > > > > > Many thanks! > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > > > > From f96hajo at chalmers.se Mon Jul 15 16:31:17 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Jul 2024 16:31:17 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de> Message-ID: <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> Looks like the issue might be at: 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 which for me is: p32 = land_vme = event_buffer.ptr; part of a block of code: SUBEVENT_BEGIN(0, 0, event_buffer); p32 = land_vme = event_buffer.ptr; *p32++ = LAND_VME_HAS_TIME_STAMP; *p32++ = tt; or possibly some function that it calls. You have the same code at that line? Could you also send the daq startup script and the nurdlib configuration file? Cheers, H?kan On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > unfortunately, the DAQ crashes on startup. Here is the output: > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > Message not logged - thread has no error buffer yet... > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > Message not logged - thread has no error buffer yet... > HOST: RIO4-MCAL-1 > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 (eth1). > 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 419430400 = 0x19000000, 1 consumers. > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). > client union size: 244 240 188 508 640 204 204? => 640 > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > 10: lwroc_main.c:704: Log message rate limit in effect. > 10: lwroc_readout.c:116: call readout_init... > 10: lwroc_thread_util.c:118: This is the triva control thread! > 10: lwroc_thread_util.c:118: This is the net io thread! > 10: lwroc_thread_util.c:118: This is the slow_async thread! > 10: lwroc_thread_util.c:118: This is the data server thread! > 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. > 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) > 10: lwroc_message_internal.c:485: Message client connected! > 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) [192.168.1.1]. > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > 10: lwroc_triva_control.c:418: Minimum event time ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > 9: lwroc_triva_control.c:507: TEST: GO > 10: lwroc_triva_control.c:725: RUN: RESET > 10: lwroc_triva_control.c:729: RUN: MT=14 > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max 2.8 kHz) > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > 10: config/config.c:205: Will try default cfg path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: config/parser.c:319: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > 10: config/parser.c:331: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > 10: config/parser.c:319: Opened './main.cfg' { > 10: config/config.c:1388: .Global log level=verbose. > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:331: Closed './main.cfg' } > 10: crate/crate.c:373: crate_create { > 10: crate/crate.c:714: crate_create(MCAL) } > 10: crate/crate.c:1022: crate_init(MCAL) { > 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. > 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns wr(0x30000000+0x64/32)=356ns. > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.??? ? > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. > 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns wr(0x31000000+0x64/32)=359ns. > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. > 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns wr(0x32000000+0x64/32)=399ns. > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. > 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. > 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. > 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. > 10: crate/crate.c:1196: crate_init(MCAL) } > 10: ctrl/ctrl.c:1046: Control server online. > Message not logged - thread has no error buffer yet... > 10: f_user.c:559: WR ID=0x200. > 10: f_user.c:565: TS offset unset. Will not modify stamp. > 10: f_user.c:572: TPAT: No. > 10: f_user.c:573: Sync-check: No. > 10: f_user.c:575: Spill triggers: No. > 10: f_user.c:576: LMU: No. > 10: f_user.c:577: Timer latches: No. > 10: f_user.c:578: Spill shape: No. > 10: f_user.c:579: Micro-structure: No. > 10: f_user.c:581: Multi-event flag: No. > 10: f_user.c:586: UDP destination: None. > 1: lwroc_main.c:132: SIGSEGV received. > 1: -:0: Backtrace: > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > 1: -:0: [0x100344] > 1: -:0: [(nil)] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > 1: -:0: /lib/libc.so.6 [0xfb91260] > 1: -:0: /lib/libc.so.6 [0xfb913ec] > 1: -:0: Backtrace (again, with addr2line): > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > 1: -:0: ?? ??:0 > sh: -c: line 0: syntax error near unexpected token `(' > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > sh: -c: line 0: syntax error near unexpected token `(' > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 2 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > 1: -:0: ?? ??:0 > 1: -:0: ?? ??:0 > 1: -:0: Backtrace (again, addresses): > 1: -:0: 0x0x100ae20c: > 1: -:0: 0x0x100ad56c: > 1: -:0: 0x0x100ae518: > 1: -:0: 0x0x100a6374: > 1: -:0: 0x0x100344: > 1: -:0: 0x(nil): > 1: -:0: 0x0x100066c0: > 1: -:0: 0x0x10073774: > 1: -:0: 0x0x100a6e98: > 1: -:0: 0x0x100a7f38: > 1: -:0: 0x0x100a6890: > 1: -:0: 0x0x100a5dc0: > 1: -:0: 0x0xfb91260: > 1: -:0: 0x0xfb913ec: > 1: -:0: BUG or FATAL reported. > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > Send slave abort readout. (1) > Send master abort (0x200). > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > 1: -:0: Hardware cleanup done. > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > ^C8: lwroc_main.c:105: SIGINT received. > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > ^C8: lwroc_main.c:105: SIGINT received. > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > Looks like DRASI still has a problem ? > > > > > Best greetings > > G?nter > > > > > > > > ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von Weber, Guenter Dr. > Gesendet: Montag, 15. Juli 2024 16:02:57 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > Dear H?kan, > > > thank you for the reply. > > > After implementing the suggested changes, I now get the following warning (on PC): > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. > UDP:ARPA_INET_H > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > f_user.c: In function ?f_user_init?: > f_user.c:697:2: warning: null argument where non-null required (argument 3) [-Wnonnull] > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > On the RIO4 there is no warning: > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > UDP:ARPA_INET_H > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > In a few minutes I can tell you if the DAQ is running with the new software or not. > > > > > > Best greetings > > G?nter > > > > > > ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Montag, 15. Juli 2024 15:49:23 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > Dear G?nter, > > it looks like with a change of the second parameter of log_callback (both > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > then in compiles. > > Likely caused by commit '36772113' in nurdlib that changed line numbers > from unsigned to int. > > Cheers, > H?kan > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear all, > > > > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > > > > When compiling fuser_drasi, the following happens (on PC): > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > > fuser_drasi > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > For nconf results and logs, see also > > build_cc_x86_64-linux-gnu_7_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > f_user.c: In function ?f_user_init?: > > f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from > > incompatible pointer type [-Wincompatible-pointer-types] > > ? g_crate = nurdlib_setup(log_callback, path); > > ????????????????????????? ^~~~~~~~~~~~ > > In file included from f_user.c:15:0: > > ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void > > (*)(const char *, int,? unsigned int,? const char *)}? but argument is of > > type ?void (*)(const char *, unsigned int,? unsigned int,? const char *)? > > ?struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > > ?????????????? ^~~~~~~~~~~~~ > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > > [-Wnonnull] > > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > On the RIO4 the warning is a bit less detailed: > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > f_user.c: In function 'f_user_init': > > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > > incompatible pointer type > > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > Any ideas what might have happened here? Or is this normal behaviour? > > > > > > > > Many thanks! > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > > > > From f96hajo at chalmers.se Mon Jul 15 16:34:40 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Jul 2024 16:34:40 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de> <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> Message-ID: <842ad762-fab8-3c11-d150-df9785fcba77@chalmers.se> And comment out the SIS3316 modules and see if things can run without those? The error is in code which I would assume to not break just due to an nurdlib update. Cheers, H?kan On Mon, 15 Jul 2024, H?kan T Johansson wrote: > > Looks like the issue might be at: > > 1: -:0: f_user_readout > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > which for me is: > > p32 = land_vme = event_buffer.ptr; > > part of a block of code: > > SUBEVENT_BEGIN(0, 0, event_buffer); > p32 = land_vme = event_buffer.ptr; > *p32++ = LAND_VME_HAS_TIME_STAMP; > *p32++ = tt; > > or possibly some function that it calls. > > You have the same code at that line? > > Could you also send the daq startup script and the nurdlib configuration > file? > > Cheers, > H?kan > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > >> >> Dear friends, >> >> >> unfortunately, the DAQ crashes on startup. Here is the output: >> >> >> 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: >> 56583). >> Message not logged - thread has no error buffer yet... >> CPUS: 1 >> delay: 1 >> 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: >> 56583). >> Message not logged - thread has no error buffer yet... >> HOST: RIO4-MCAL-1 >> Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] >> 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 >> (eth1). >> 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size >> 419430400 = 0x19000000, 1 consumers. >> 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) >> 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). >> client union size: 244 240 188 508 640 204 204? => 640 >> 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: >> /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 >> 10: lwroc_main.c:704: Log message rate limit in effect. >> 10: lwroc_readout.c:116: call readout_init... >> 10: lwroc_thread_util.c:118: This is the triva control thread! >> 10: lwroc_thread_util.c:118: This is the net io thread! >> 10: lwroc_thread_util.c:118: This is the slow_async thread! >> 10: lwroc_thread_util.c:118: This is the data server thread! >> 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. >> 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB >> connection(s): >> 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) >> 10: lwroc_message_internal.c:485: Message client connected! >> 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) >> [192.168.1.1]. >> 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) >> 10: lwroc_triva_control.c:418: Minimum event time >> ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) >> 10: lwroc_triva_state.c:1486: (Re)send ident messages... >> 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 >> 9: lwroc_triva_control.c:507: TEST: GO >> 10: lwroc_triva_control.c:725: RUN: RESET >> 10: lwroc_triva_control.c:729: RUN: MT=14 >> 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max 2.8 >> kHz) >> 10: lwroc_triva_readout.c:376: Trigger 14 seen. >> 10: config/config.c:205: Will try default cfg >> path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', >> can be set with NURDLIB_DEF_PATH. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 1 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: config/parser.c:319: Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' >> { >> 10: config/parser.c:331: Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' >> } >> 10: config/parser.c:319: Opened './main.cfg' { >> 10: config/config.c:1388: .Global log level=verbose. >> 10: config/parser.c:319: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' >> { >> 10: config/parser.c:331: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' >> } >> 10: config/parser.c:319: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' >> { >> 10: config/parser.c:331: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' >> } >> 10: config/parser.c:319: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' >> { >> 10: config/parser.c:331: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' >> } >> 10: config/parser.c:319: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' >> { >> 10: config/parser.c:331: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' >> } >> 10: config/parser.c:319: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' >> { >> 10: config/parser.c:331: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' >> } >> 10: config/parser.c:319: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' >> { >> 10: config/parser.c:331: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' >> } >> 10: config/parser.c:319: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' >> { >> 10: config/parser.c:331: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' >> } >> 10: config/parser.c:319: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' >> { >> 10: config/parser.c:331: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' >> } >> 10: config/parser.c:319: .Opened >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' >> { >> 10: config/parser.c:331: .Closed >> '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' >> } >> 10: config/parser.c:331: Closed './main.cfg' } >> 10: crate/crate.c:373: crate_create { >> 10: crate/crate.c:714: crate_create(MCAL) } >> 10: crate/crate.c:1022: crate_init(MCAL) { >> 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. >> LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) >> 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. >> 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns >> wr(0x30000000+0x64/32)=356ns. >> 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. >> 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and >> in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 1 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and >> in deadtime.??? ? >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 1 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. >> 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns >> wr(0x31000000+0x64/32)=359ns. >> 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. >> 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and >> in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 1 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. >> 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns >> wr(0x32000000+0x64/32)=399ns. >> 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. >> 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. >> 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. >> 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. >> 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and >> in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 1 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and >> in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 1 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and >> in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 1 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and >> in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 1 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a >> 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a >> 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. >> 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. >> 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. >> 10: crate/crate.c:1196: crate_init(MCAL) } >> 10: ctrl/ctrl.c:1046: Control server online. >> Message not logged - thread has no error buffer yet... >> 10: f_user.c:559: WR ID=0x200. >> 10: f_user.c:565: TS offset unset. Will not modify stamp. >> 10: f_user.c:572: TPAT: No. >> 10: f_user.c:573: Sync-check: No. >> 10: f_user.c:575: Spill triggers: No. >> 10: f_user.c:576: LMU: No. >> 10: f_user.c:577: Timer latches: No. >> 10: f_user.c:578: Spill shape: No. >> 10: f_user.c:579: Micro-structure: No. >> 10: f_user.c:581: Multi-event flag: No. >> 10: f_user.c:586: UDP destination: None. >> 1: lwroc_main.c:132: SIGSEGV received. >> 1: -:0: Backtrace: >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x100ae20c] >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x100ad56c] >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x100ae518] >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x100a6374] >> 1: -:0: [0x100344] >> 1: -:0: [(nil)] >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x100066c0] >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x10073774] >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x100a6e98] >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x100a7f38] >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x100a6890] >> 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> [0x100a5dc0] >> 1: -:0: /lib/libc.so.6 [0xfb91260] >> 1: -:0: /lib/libc.so.6 [0xfb913ec] >> 1: -:0: Backtrace (again, with addr2line): >> 1: -:0: lwroc_dump_backtrace >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 >> 1: -:0: lwroc_do_message_internal >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 >> 1: -:0: lwroc_message_internal >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 >> 1: -:0: lwroc_sighandler >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 >> 1: -:0: ?? ??:0 >> sh: -c: line 0: syntax error near unexpected token `(' >> sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' >> sh: -c: line 0: syntax error near unexpected token `(' >> sh: -c: line 0: `addr2line -i -f -C (nil) -e >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' >> 1: -:0: f_user_readout >> /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 >> 1: -:0: fud_read_event >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 >> 1: -:0: lwroc_triva_event_loop >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 >> 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and >> in deadtime. >> 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 >> (IN_READOUT).? EC: 2 >> 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. >> 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... >> 1: -:0: lwroc_triva_readout >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 >> 1: -:0: lwroc_main_loop >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 >> 1: -:0: main >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 >> 1: -:0: ?? ??:0 >> 1: -:0: ?? ??:0 >> 1: -:0: Backtrace (again, addresses): >> 1: -:0: 0x0x100ae20c: >> 1: -:0: 0x0x100ad56c: >> 1: -:0: 0x0x100ae518: >> 1: -:0: 0x0x100a6374: >> 1: -:0: 0x0x100344: >> 1: -:0: 0x(nil): >> 1: -:0: 0x0x100066c0: >> 1: -:0: 0x0x10073774: >> 1: -:0: 0x0x100a6e98: >> 1: -:0: 0x0x100a7f38: >> 1: -:0: 0x0x100a6890: >> 1: -:0: 0x0x100a5dc0: >> 1: -:0: 0x0xfb91260: >> 1: -:0: 0x0xfb913ec: >> 1: -:0: BUG or FATAL reported. >> 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). >> 1: -:0: Debug cmd: cd >> /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb >> ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 >> 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... >> 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). >> 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and >> slaves to abort. >> Send slave abort readout. (1) >> Send master abort (0x200). >> 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. >> 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for >> readout... >> 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort >> test/readout: >> 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) >> 1: -:0: Hardware cleanup done. >> 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort >> test/readout: >> 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) >> 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort >> test/readout: >> 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) >> ^C8: lwroc_main.c:105: SIGINT received. >> 10: lwroc_thread_util.c:62: Set terminate first!? (main) >> ^C8: lwroc_main.c:105: SIGINT received. >> ^C5: lwroc_main.c:109: 3rd signal SIGINT received. >> >> >> >> >> Looks like DRASI still has a problem ? >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> >> >> >> ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ >> Von: subexp-daq im Auftrag von >> Weber, Guenter Dr. >> Gesendet: Montag, 15. Juli 2024 16:02:57 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? >> >> Dear H?kan, >> >> >> thank you for the reply. >> >> >> After implementing the suggested changes, I now get the following warning >> (on PC): >> >> >> (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make >> fuser_drasi >> NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args >> For nconf results and logs, see also >> build_cc_x86_64-linux-gnu_7_debug/nconf*. >> UDP:ARPA_INET_H >> build_cc_x86_64-linux-gnu_7_debug/nconf.args done. >> CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o >> CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o >> f_user.c: In function ?f_user_init?: >> f_user.c:697:2: warning: null argument where non-null required (argument 3) >> [-Wnonnull] >> ? crate_dt_release_set_func(g_crate, dt_release, NULL); >> ? ^~~~~~~~~~~~~~~~~~~~~~~~~ >> CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o >> LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi >> build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) >> >> On the RIO4 there is no warning: >> >> >> RIO4-MCAL-1 mbsdaq > make fuser_drasi >> NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >> For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. >> UDP:ARPA_INET_H >> build_cc_ppc-linux_4.2.2_debug/nconf.args done. >> CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o >> CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o >> CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o >> LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) >> >> In a few minutes I can tell you if the DAQ is running with the new software >> or not. >> >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> >> >> ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ >> Von: subexp-daq im Auftrag von H?kan >> T Johansson >> Gesendet: Montag, 15. Juli 2024 15:49:23 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? >> >> Dear G?nter, >> >> it looks like with a change of the second parameter of log_callback (both >> in prototype an definition) of r3bfuser/f_user.c from unsigned to int, >> then in compiles. >> >> Likely caused by commit '36772113' in nurdlib that changed line numbers >> from unsigned to int. >> >> Cheers, >> H?kan >> >> >> >> On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: >> >> > >> > Dear all, >> > >> > >> > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, >> etc.). >> > >> > >> > I followed the 'cooking receipt' that I git from Hakan, as always. >> > >> > >> > When compiling fuser_drasi, the following happens (on PC): >> > >> > >> > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make >> > fuser_drasi >> > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args >> > For nconf results and logs, see also >> > build_cc_x86_64-linux-gnu_7_debug/nconf*. >> > UDP:ARPA_INET_H >> > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. >> > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o >> > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o >> > f_user.c: In function ?f_user_init?: >> > f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from >> > incompatible pointer type [-Wincompatible-pointer-types] >> > ? g_crate = nurdlib_setup(log_callback, path); >> > ????????????????????????? ^~~~~~~~~~~~ >> > In file included from f_user.c:15:0: >> > ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void >> > (*)(const char *, int,? unsigned int,? const char *)}? but argument is of >> > type ?void (*)(const char *, unsigned int,? unsigned int,? const char *)? >> > ?struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; >> > ?????????????? ^~~~~~~~~~~~~ >> > f_user.c:697:2: warning: null argument where non-null required (argument >> 3) >> > [-Wnonnull] >> > ? crate_dt_release_set_func(g_crate, dt_release, NULL); >> > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ >> > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o >> > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi >> > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) >> > >> > >> > On the RIO4 the warning is a bit less detailed: >> > >> > >> > RIO4-MCAL-1 mbsdaq > make fuser_drasi >> > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args >> > For nconf results and logs, see also >> build_cc_ppc-linux_4.2.2_debug/nconf*. >> > UDP:ARPA_INET_H >> > build_cc_ppc-linux_4.2.2_debug/nconf.args done. >> > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o >> > f_user.c: In function 'f_user_init': >> > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from >> > incompatible pointer type >> > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o >> > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o >> > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi >> > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) >> > >> > Any ideas what might have happened here? Or is this normal behaviour? >> > >> > >> > >> > Many thanks! >> > >> > >> > >> > >> > >> > Best greetings >> > >> > G?nter >> > >> > >> > >> > >> > >> > >> > >> > From g.weber at hi-jena.gsi.de Mon Jul 15 16:42:44 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 15 Jul 2024 14:42:44 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> Message-ID: <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de> Dear H?kan, my f_user.c has the identical block at the identical position. Removing the STRUCK modules from main.cfg does not change the situation: 10: crate/crate.c:1196: crate_init(MCAL) } 10: ctrl/ctrl.c:1046: Control server online. Message not logged - thread has no error buffer yet... 10: f_user.c:559: WR ID=0x200. 10: f_user.c:565: TS offset unset. Will not modify stamp. 10: f_user.c:572: TPAT: No. 10: f_user.c:573: Sync-check: No. 10: f_user.c:575: Spill triggers: No. 10: f_user.c:576: LMU: No. 10: f_user.c:577: Timer latches: No. 10: f_user.c:578: Spill shape: No. 10: f_user.c:579: Micro-structure: No. 10: f_user.c:581: Multi-event flag: No. 10: f_user.c:586: UDP destination: None. 1: lwroc_main.c:132: SIGSEGV received. 1: -:0: Backtrace: 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] 1: -:0: [0x100344] 1: -:0: [(nil)] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] 1: -:0: /lib/libc.so.6 [0xfb91260] 1: -:0: /lib/libc.so.6 [0xfb913ec] 1: -:0: Backtrace (again, with addr2line): 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 1: -:0: ?? ??:0 sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 1: -:0: ?? ??:0 1: -:0: ?? ??:0 1: -:0: Backtrace (again, addresses): 1: -:0: 0x0x100ae20c: 1: -:0: 0x0x100ad56c: 1: -:0: 0x0x100ae518: 1: -:0: 0x0x100a6374: 1: -:0: 0x0x100344: 1: -:0: 0x(nil): 1: -:0: 0x0x100066c0: 1: -:0: 0x0x10073774: 1: -:0: 0x0x100a6e98: 1: -:0: 0x0x100a7f38: 1: -:0: 0x0x100a6890: 1: -:0: 0x0x100a5dc0: 1: -:0: 0x0xfb91260: 1: -:0: 0x0xfb913ec: 1: -:0: BUG or FATAL reported. 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25186 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. Send slave abort readout. (1) Send master abort (0x200). 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) 1: -:0: Hardware cleanup done. 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) ^C8: lwroc_main.c:105: SIGINT received. 10: lwroc_thread_util.c:62: Set terminate first! (main) ^C8: lwroc_main.c:105: SIGINT received. ^C5: lwroc_main.c:109: 3rd signal SIGINT received. Attached please find the files you asked for. Would be really great if you could figure out what is happening. Best greetings from Jena G?nter Looks like the issue might be at: 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 which for me is: p32 = land_vme = event_buffer.ptr; part of a block of code: SUBEVENT_BEGIN(0, 0, event_buffer); p32 = land_vme = event_buffer.ptr; *p32++ = LAND_VME_HAS_TIME_STAMP; *p32++ = tt; or possibly some function that it calls. You have the same code at that line? Could you also send the daq startup script and the nurdlib configuration file? Cheers, H?kan On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > unfortunately, the DAQ crashes on startup. Here is the output: > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > Message not logged - thread has no error buffer yet... > CPUS: 1 > delay: 1 > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > Message not logged - thread has no error buffer yet... > HOST: RIO4-MCAL-1 > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 (eth1). > 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 419430400 = 0x19000000, 1 consumers. > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) > 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). > client union size: 244 240 188 508 640 204 204 => 640 > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > 10: lwroc_main.c:704: Log message rate limit in effect. > 10: lwroc_readout.c:116: call readout_init... > 10: lwroc_thread_util.c:118: This is the triva control thread! > 10: lwroc_thread_util.c:118: This is the net io thread! > 10: lwroc_thread_util.c:118: This is the slow_async thread! > 10: lwroc_thread_util.c:118: This is the data server thread! > 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. > 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB connection(s): > 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) > 10: lwroc_message_internal.c:485: Message client connected! > 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) [192.168.1.1]. > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) > 10: lwroc_triva_control.c:418: Minimum event time ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > 9: lwroc_triva_control.c:507: TEST: GO > 10: lwroc_triva_control.c:725: RUN: RESET > 10: lwroc_triva_control.c:729: RUN: MT=14 > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 2.8 kHz) > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > 10: config/config.c:205: Will try default cfg path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: config/parser.c:319: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > 10: config/parser.c:331: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > 10: config/parser.c:319: Opened './main.cfg' { > 10: config/config.c:1388: .Global log level=verbose. > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > 10: config/parser.c:331: Closed './main.cfg' } > 10: crate/crate.c:373: crate_create { > 10: crate/crate.c:714: crate_create(MCAL) } > 10: crate/crate.c:1022: crate_init(MCAL) { > 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. > 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns wr(0x30000000+0x64/32)=356ns. > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. > 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns wr(0x31000000+0x64/32)=359ns. > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. > 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns wr(0x32000000+0x64/32)=399ns. > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. > 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. > 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. > 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. > 10: crate/crate.c:1196: crate_init(MCAL) } > 10: ctrl/ctrl.c:1046: Control server online. > Message not logged - thread has no error buffer yet... > 10: f_user.c:559: WR ID=0x200. > 10: f_user.c:565: TS offset unset. Will not modify stamp. > 10: f_user.c:572: TPAT: No. > 10: f_user.c:573: Sync-check: No. > 10: f_user.c:575: Spill triggers: No. > 10: f_user.c:576: LMU: No. > 10: f_user.c:577: Timer latches: No. > 10: f_user.c:578: Spill shape: No. > 10: f_user.c:579: Micro-structure: No. > 10: f_user.c:581: Multi-event flag: No. > 10: f_user.c:586: UDP destination: None. > 1: lwroc_main.c:132: SIGSEGV received. > 1: -:0: Backtrace: > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > 1: -:0: [0x100344] > 1: -:0: [(nil)] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > 1: -:0: /lib/libc.so.6 [0xfb91260] > 1: -:0: /lib/libc.so.6 [0xfb913ec] > 1: -:0: Backtrace (again, with addr2line): > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > 1: -:0: ?? ??:0 > sh: -c: line 0: syntax error near unexpected token `(' > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > sh: -c: line 0: syntax error near unexpected token `(' > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 2 > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > 1: -:0: ?? ??:0 > 1: -:0: ?? ??:0 > 1: -:0: Backtrace (again, addresses): > 1: -:0: 0x0x100ae20c: > 1: -:0: 0x0x100ad56c: > 1: -:0: 0x0x100ae518: > 1: -:0: 0x0x100a6374: > 1: -:0: 0x0x100344: > 1: -:0: 0x(nil): > 1: -:0: 0x0x100066c0: > 1: -:0: 0x0x10073774: > 1: -:0: 0x0x100a6e98: > 1: -:0: 0x0x100a7f38: > 1: -:0: 0x0x100a6890: > 1: -:0: 0x0x100a5dc0: > 1: -:0: 0x0xfb91260: > 1: -:0: 0x0xfb913ec: > 1: -:0: BUG or FATAL reported. > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > Send slave abort readout. (1) > Send master abort (0x200). > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > 1: -:0: Hardware cleanup done. > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > ^C8: lwroc_main.c:105: SIGINT received. > 10: lwroc_thread_util.c:62: Set terminate first! (main) > ^C8: lwroc_main.c:105: SIGINT received. > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > Looks like DRASI still has a problem ?? > > > > > Best greetings > > G?nter > > > > > > > > ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von Weber, Guenter Dr. > Gesendet: Montag, 15. Juli 2024 16:02:57 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > Dear H?kan, > > > thank you for the reply. > > > After implementing the suggested changes, I now get the following warning (on PC): > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. > UDP:ARPA_INET_H > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > f_user.c: In function 'f_user_init': > f_user.c:697:2: warning: null argument where non-null required (argument 3) [-Wnonnull] > crate_dt_release_set_func(g_crate, dt_release, NULL); > ^~~~~~~~~~~~~~~~~~~~~~~~~ > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > On the RIO4 there is no warning: > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > UDP:ARPA_INET_H > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > In a few minutes I can tell you if the DAQ is running with the new software or not. > > > > > > Best greetings > > G?nter > > > > > > ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Montag, 15. Juli 2024 15:49:23 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > Dear G?nter, > > it looks like with a change of the second parameter of log_callback (both > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > then in compiles. > > Likely caused by commit '36772113' in nurdlib that changed line numbers > from unsigned to int. > > Cheers, > H?kan > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear all, > > > > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > > > > When compiling fuser_drasi, the following happens (on PC): > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > > fuser_drasi > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > For nconf results and logs, see also > > build_cc_x86_64-linux-gnu_7_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > f_user.c: In function 'f_user_init': > > f_user.c:682:26: warning: passing argument 1 of 'nurdlib_setup' from > > incompatible pointer type [-Wincompatible-pointer-types] > > g_crate = nurdlib_setup(log_callback, path); > > ^~~~~~~~~~~~ > > In file included from f_user.c:15:0: > > ../nurdlib/include/nurdlib.h:28:15: note: expected 'LogCallback {aka void > > (*)(const char *, int, unsigned int, const char *)}' but argument is of > > type 'void (*)(const char *, unsigned int, unsigned int, const char *)' > > struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > > ^~~~~~~~~~~~~ > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > > [-Wnonnull] > > crate_dt_release_set_func(g_crate, dt_release, NULL); > > ^~~~~~~~~~~~~~~~~~~~~~~~~ > > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > On the RIO4 the warning is a bit less detailed: > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > f_user.c: In function 'f_user_init': > > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > > incompatible pointer type > > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > Any ideas what might have happened here? Or is this normal behaviour? > > > > > > > > Many thanks! > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cfg Type: application/octet-stream Size: 5377 bytes Desc: main.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: r3bfuser.cfg Type: application/octet-stream Size: 11 bytes Desc: r3bfuser.cfg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: master.bash Type: application/octet-stream Size: 380 bytes Desc: master.bash URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: trloii_setup.sh Type: application/x-sh Size: 1967 bytes Desc: trloii_setup.sh URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vulom.trlo Type: application/octet-stream Size: 3103 bytes Desc: vulom.trlo URL: From f96hajo at chalmers.se Mon Jul 15 16:50:45 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Jul 2024 16:50:45 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de> Message-ID: <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > Dear H?kan, > > > my f_user.c has the identical block at the identical position. > > > Removing the STRUCK modules from main.cfg does not change the situation: That at least removes a lot of unknowns from the equation. ;) Could you add a bunch of printf("a...\n"); fflush(stdout); on the lines around that block, se we know better exactly where it crashes? And then if that brings it down, also start to print pointer values (before their use). With the backtrace, it is also a bit unclear if it actually is failing on the line above or below... Cheers, H?kan > > > 10: crate/crate.c:1196: crate_init(MCAL) } > 10: ctrl/ctrl.c:1046: Control server online. > Message not logged - thread has no error buffer yet... > 10: f_user.c:559: WR ID=0x200. > 10: f_user.c:565: TS offset unset. Will not modify stamp. > 10: f_user.c:572: TPAT: No. > 10: f_user.c:573: Sync-check: No. > 10: f_user.c:575: Spill triggers: No. > 10: f_user.c:576: LMU: No. > 10: f_user.c:577: Timer latches: No. > 10: f_user.c:578: Spill shape: No. > 10: f_user.c:579: Micro-structure: No. > 10: f_user.c:581: Multi-event flag: No. > 10: f_user.c:586: UDP destination: None. > 1: lwroc_main.c:132: SIGSEGV received. > 1: -:0: Backtrace: > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > 1: -:0: [0x100344] > 1: -:0: [(nil)] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > 1: -:0: /lib/libc.so.6 [0xfb91260] > 1: -:0: /lib/libc.so.6 [0xfb913ec] > 1: -:0: Backtrace (again, with addr2line): > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > 1: -:0: ?? ??:0 > sh: -c: line 0: syntax error near unexpected token `(' > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > sh: -c: line 0: syntax error near unexpected token `(' > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > 1: -:0: ?? ??:0 > 1: -:0: ?? ??:0 > 1: -:0: Backtrace (again, addresses): > 1: -:0: 0x0x100ae20c: > 1: -:0: 0x0x100ad56c: > 1: -:0: 0x0x100ae518: > 1: -:0: 0x0x100a6374: > 1: -:0: 0x0x100344: > 1: -:0: 0x(nil): > 1: -:0: 0x0x100066c0: > 1: -:0: 0x0x10073774: > 1: -:0: 0x0x100a6e98: > 1: -:0: 0x0x100a7f38: > 1: -:0: 0x0x100a6890: > 1: -:0: 0x0x100a5dc0: > 1: -:0: 0x0xfb91260: > 1: -:0: 0x0xfb913ec: > 1: -:0: BUG or FATAL reported. > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25186 > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > Send slave abort readout. (1) > Send master abort (0x200). > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > 1: -:0: Hardware cleanup done. > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > ^C8: lwroc_main.c:105: SIGINT received. > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > ^C8: lwroc_main.c:105: SIGINT received. > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > Attached please find the files you asked for. > > > > Would be really great if you could figure out what is happening. > > > > > Best greetings from Jena > > G?nter > > > > > > > > > > > Looks like the issue might be at: > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > which for me is: > > ???????? p32 = land_vme = event_buffer.ptr; > > part of a block of code: > > ???????? SUBEVENT_BEGIN(0, 0, event_buffer); > ???????? p32 = land_vme = event_buffer.ptr; > ???????? *p32++ = LAND_VME_HAS_TIME_STAMP; > ???????? *p32++ = tt; > > or possibly some function that it calls. > > You have the same code at that line? > > Could you also send the daq startup script and the nurdlib > configuration file? > > Cheers, > H?kan > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > unfortunately, the DAQ crashes on startup. Here is the output: > > > > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > Message not logged - thread has no error buffer yet... > > CPUS: 1 > > delay: 1 > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > Message not logged - thread has no error buffer yet... > > HOST: RIO4-MCAL-1 > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 (eth1). > > 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 419430400 = 0x19000000, 1 consumers. > > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > > 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). > > client union size: 244 240 188 508 640 204 204? => 640 > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > 10: lwroc_main.c:704: Log message rate limit in effect. > > 10: lwroc_readout.c:116: call readout_init... > > 10: lwroc_thread_util.c:118: This is the triva control thread! > > 10: lwroc_thread_util.c:118: This is the net io thread! > > 10: lwroc_thread_util.c:118: This is the slow_async thread! > > 10: lwroc_thread_util.c:118: This is the data server thread! > > 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. > > 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) > > 10: lwroc_message_internal.c:485: Message client connected! > > 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) [192.168.1.1]. > > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > > 10: lwroc_triva_control.c:418: Minimum event time ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > 9: lwroc_triva_control.c:507: TEST: GO > > 10: lwroc_triva_control.c:725: RUN: RESET > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max 2.8 kHz) > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > 10: config/config.c:205: Will try default cfg path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: config/parser.c:319: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > > 10: config/parser.c:331: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > > 10: config/parser.c:319: Opened './main.cfg' { > > 10: config/config.c:1388: .Global log level=verbose. > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:331: Closed './main.cfg' } > > 10: crate/crate.c:373: crate_create { > > 10: crate/crate.c:714: crate_create(MCAL) } > > 10: crate/crate.c:1022: crate_init(MCAL) { > > 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. > > 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns wr(0x30000000+0x64/32)=356ns. > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.??? ? > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. > > 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns wr(0x31000000+0x64/32)=359ns. > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. > > 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns wr(0x32000000+0x64/32)=399ns. > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. > > 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. > > 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. > > 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. > > 10: crate/crate.c:1196: crate_init(MCAL) } > > 10: ctrl/ctrl.c:1046: Control server online. > > Message not logged - thread has no error buffer yet... > > 10: f_user.c:559: WR ID=0x200. > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > 10: f_user.c:572: TPAT: No. > > 10: f_user.c:573: Sync-check: No. > > 10: f_user.c:575: Spill triggers: No. > > 10: f_user.c:576: LMU: No. > > 10: f_user.c:577: Timer latches: No. > > 10: f_user.c:578: Spill shape: No. > > 10: f_user.c:579: Micro-structure: No. > > 10: f_user.c:581: Multi-event flag: No. > > 10: f_user.c:586: UDP destination: None. > > 1: lwroc_main.c:132: SIGSEGV received. > > 1: -:0: Backtrace: > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > 1: -:0: [0x100344] > > 1: -:0: [(nil)] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > 1: -:0: Backtrace (again, with addr2line): > > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > 1: -:0: ?? ??:0 > > sh: -c: line 0: syntax error near unexpected token `(' > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > sh: -c: line 0: syntax error near unexpected token `(' > > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 2 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > 1: -:0: ?? ??:0 > > 1: -:0: ?? ??:0 > > 1: -:0: Backtrace (again, addresses): > > 1: -:0: 0x0x100ae20c: > > 1: -:0: 0x0x100ad56c: > > 1: -:0: 0x0x100ae518: > > 1: -:0: 0x0x100a6374: > > 1: -:0: 0x0x100344: > > 1: -:0: 0x(nil): > > 1: -:0: 0x0x100066c0: > > 1: -:0: 0x0x10073774: > > 1: -:0: 0x0x100a6e98: > > 1: -:0: 0x0x100a7f38: > > 1: -:0: 0x0x100a6890: > > 1: -:0: 0x0x100a5dc0: > > 1: -:0: 0x0xfb91260: > > 1: -:0: 0x0xfb913ec: > > 1: -:0: BUG or FATAL reported. > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > > Send slave abort readout. (1) > > Send master abort (0x200). > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > 1: -:0: Hardware cleanup done. > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > ^C8: lwroc_main.c:105: SIGINT received. > > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > > ^C8: lwroc_main.c:105: SIGINT received. > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > > > > > > Looks like DRASI still has a problem ?? > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > > > >_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von Weber, Guenter Dr. > > Gesendet: Montag, 15. Juli 2024 16:02:57 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > > > Dear H?kan, > > > > > > thank you for the reply. > > > > > > After implementing the suggested changes, I now get the following warning (on PC): > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > f_user.c: In function ?f_user_init?: > > f_user.c:697:2: warning: null argument where non-null required (argument 3) [-Wnonnull] > > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > On the RIO4 there is no warning: > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > In a few minutes I can tell you if the DAQ is running with the new software or not. > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > >_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Montag, 15. Juli 2024 15:49:23 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > > > Dear G?nter, > > > > it looks like with a change of the second parameter of log_callback (both > > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > > then in compiles. > > > > Likely caused by commit '36772113' in nurdlib that changed line numbers > > from unsigned to int. > > > > Cheers, > > H?kan > > > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear all, > > > > > > > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > > > > > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > > > > > > > When compiling fuser_drasi, the following happens (on PC): > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > > > fuser_drasi > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > For nconf results and logs, see also > > > build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > UDP:ARPA_INET_H > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > f_user.c: In function ?f_user_init?: > > > f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from > > > incompatible pointer type [-Wincompatible-pointer-types] > > > ? g_crate = nurdlib_setup(log_callback, path); > > > ????????????????????????? ^~~~~~~~~~~~ > > > In file included from f_user.c:15:0: > > > ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void > > > (*)(const char *, int,? unsigned int,? const char *)}? but argument is of > > > type ?void (*)(const char *, unsigned int,? unsigned int,? const char *)? > > > ?struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > > > ?????????????? ^~~~~~~~~~~~~ > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > > > [-Wnonnull] > > > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > > > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > > > > On the RIO4 the warning is a bit less detailed: > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > UDP:ARPA_INET_H > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > f_user.c: In function 'f_user_init': > > > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > > > incompatible pointer type > > > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > Any ideas what might have happened here? Or is this normal behaviour? > > > > > > > > > > > > Many thanks! > > > > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Mon Jul 15 17:33:08 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 15 Jul 2024 15:33:08 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> Message-ID: <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de> Here is what I did: printf("before block\n"); fflush(stdout); SUBEVENT_BEGIN(0, 0, event_buffer); printf("after SUBEVENT_BEGIN \n"); fflush(stdout); p32 = land_vme = event_buffer.ptr; printf("after p32 = land_vme = event_buffer.ptr -> %u \n", p32); fflush(stdout); *p32++ = LAND_VME_HAS_TIME_STAMP; printf("after *p32++ = LAND_VME_HAS_TIME_STAMP -> %u \n", p32); fflush(stdout); *p32++ = tt; printf("after *p32++ = tt -> %u \n", p32); fflush(stdout); { uint32_t diff; diff = crate_counter_get_diff(g_counter_ms); printf("after diff -> %u \n", diff); fflush(stdout); if (diff > 1 || g_cfg.mevent_flag) { *land_vme |= LAND_VME_MULTI_EVENT; *p32++ = diff; } } EVENT_BUFFER_ADVANCE(event_buffer, p32); printf("after EVENT_BUFFER_ADVANCE -> %u %u \n", event_buffer, p32); fflush(stdout); ret |= crate_readout(g_crate, &event_buffer); SUBEVENT_END(event_buffer); And this is what we get: before block after SUBEVENT_BEGIN after p32 = land_vme = event_buffer.ptr -> 805691484 after *p32++ = LAND_VME_HAS_TIME_STAMP -> 805691488 after *p32++ = tt -> 805691492 1: lwroc_main.c:132: SIGSEGV received. 1: -:0: Backtrace: 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae32c] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad68c] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae638] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6494] 1: -:0: [0x100344] 1: -:0: /lib/libc.so.6(fflush+0xb4) [0xfbd78bc] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100067a8] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073894] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6fb8] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a8058] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a69b0] 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5ee0] 1: -:0: /lib/libc.so.6 [0xfb91260] 1: -:0: /lib/libc.so.6 [0xfb913ec] 1: -:0: Backtrace (again, with addr2line): 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 1: -:0: ?? ??:0 1: -:0: ?? ??:0 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:987 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 1: -:0: ?? ??:0 1: -:0: ?? ??:0 1: -:0: BUG or FATAL reported. 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25615 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. Send slave abort readout. (1) Send master abort (0x200). ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 15. Juli 2024 16:50:45 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > Dear H?kan, > > > my f_user.c has the identical block at the identical position. > > > Removing the STRUCK modules from main.cfg does not change the situation: That at least removes a lot of unknowns from the equation. ;) Could you add a bunch of printf("a...\n"); fflush(stdout); on the lines around that block, se we know better exactly where it crashes? And then if that brings it down, also start to print pointer values (before their use). With the backtrace, it is also a bit unclear if it actually is failing on the line above or below... Cheers, H?kan > > > 10: crate/crate.c:1196: crate_init(MCAL) } > 10: ctrl/ctrl.c:1046: Control server online. > Message not logged - thread has no error buffer yet... > 10: f_user.c:559: WR ID=0x200. > 10: f_user.c:565: TS offset unset. Will not modify stamp. > 10: f_user.c:572: TPAT: No. > 10: f_user.c:573: Sync-check: No. > 10: f_user.c:575: Spill triggers: No. > 10: f_user.c:576: LMU: No. > 10: f_user.c:577: Timer latches: No. > 10: f_user.c:578: Spill shape: No. > 10: f_user.c:579: Micro-structure: No. > 10: f_user.c:581: Multi-event flag: No. > 10: f_user.c:586: UDP destination: None. > 1: lwroc_main.c:132: SIGSEGV received. > 1: -:0: Backtrace: > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > 1: -:0: [0x100344] > 1: -:0: [(nil)] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > 1: -:0: /lib/libc.so.6 [0xfb91260] > 1: -:0: /lib/libc.so.6 [0xfb913ec] > 1: -:0: Backtrace (again, with addr2line): > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > 1: -:0: ?? ??:0 > sh: -c: line 0: syntax error near unexpected token `(' > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > sh: -c: line 0: syntax error near unexpected token `(' > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > 1: -:0: ?? ??:0 > 1: -:0: ?? ??:0 > 1: -:0: Backtrace (again, addresses): > 1: -:0: 0x0x100ae20c: > 1: -:0: 0x0x100ad56c: > 1: -:0: 0x0x100ae518: > 1: -:0: 0x0x100a6374: > 1: -:0: 0x0x100344: > 1: -:0: 0x(nil): > 1: -:0: 0x0x100066c0: > 1: -:0: 0x0x10073774: > 1: -:0: 0x0x100a6e98: > 1: -:0: 0x0x100a7f38: > 1: -:0: 0x0x100a6890: > 1: -:0: 0x0x100a5dc0: > 1: -:0: 0x0xfb91260: > 1: -:0: 0x0xfb913ec: > 1: -:0: BUG or FATAL reported. > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25186 > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > Send slave abort readout. (1) > Send master abort (0x200). > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > 1: -:0: Hardware cleanup done. > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > ^C8: lwroc_main.c:105: SIGINT received. > 10: lwroc_thread_util.c:62: Set terminate first! (main) > ^C8: lwroc_main.c:105: SIGINT received. > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > Attached please find the files you asked for. > > > > Would be really great if you could figure out what is happening. > > > > > Best greetings from Jena > > G?nter > > > > > > > > > > > Looks like the issue might be at: > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > which for me is: > > p32 = land_vme = event_buffer.ptr; > > part of a block of code: > > SUBEVENT_BEGIN(0, 0, event_buffer); > p32 = land_vme = event_buffer.ptr; > *p32++ = LAND_VME_HAS_TIME_STAMP; > *p32++ = tt; > > or possibly some function that it calls. > > You have the same code at that line? > > Could you also send the daq startup script and the nurdlib > configuration file? > > Cheers, > H?kan > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear friends, > > > > > > unfortunately, the DAQ crashes on startup. Here is the output: > > > > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > Message not logged - thread has no error buffer yet... > > CPUS: 1 > > delay: 1 > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > Message not logged - thread has no error buffer yet... > > HOST: RIO4-MCAL-1 > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 (eth1). > > 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 419430400 = 0x19000000, 1 consumers. > > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) > > 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). > > client union size: 244 240 188 508 640 204 204 => 640 > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > 10: lwroc_main.c:704: Log message rate limit in effect. > > 10: lwroc_readout.c:116: call readout_init... > > 10: lwroc_thread_util.c:118: This is the triva control thread! > > 10: lwroc_thread_util.c:118: This is the net io thread! > > 10: lwroc_thread_util.c:118: This is the slow_async thread! > > 10: lwroc_thread_util.c:118: This is the data server thread! > > 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. > > 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB connection(s): > > 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) > > 10: lwroc_message_internal.c:485: Message client connected! > > 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) [192.168.1.1]. > > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) > > 10: lwroc_triva_control.c:418: Minimum event time ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > 9: lwroc_triva_control.c:507: TEST: GO > > 10: lwroc_triva_control.c:725: RUN: RESET > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 2.8 kHz) > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > 10: config/config.c:205: Will try default cfg path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: config/parser.c:319: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > > 10: config/parser.c:331: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > > 10: config/parser.c:319: Opened './main.cfg' { > > 10: config/config.c:1388: .Global log level=verbose. > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > 10: config/parser.c:331: Closed './main.cfg' } > > 10: crate/crate.c:373: crate_create { > > 10: crate/crate.c:714: crate_create(MCAL) } > > 10: crate/crate.c:1022: crate_init(MCAL) { > > 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. > > 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns wr(0x30000000+0x64/32)=356ns. > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. > > 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns wr(0x31000000+0x64/32)=359ns. > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. > > 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns wr(0x32000000+0x64/32)=399ns. > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. > > 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. > > 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. > > 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. > > 10: crate/crate.c:1196: crate_init(MCAL) } > > 10: ctrl/ctrl.c:1046: Control server online. > > Message not logged - thread has no error buffer yet... > > 10: f_user.c:559: WR ID=0x200. > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > 10: f_user.c:572: TPAT: No. > > 10: f_user.c:573: Sync-check: No. > > 10: f_user.c:575: Spill triggers: No. > > 10: f_user.c:576: LMU: No. > > 10: f_user.c:577: Timer latches: No. > > 10: f_user.c:578: Spill shape: No. > > 10: f_user.c:579: Micro-structure: No. > > 10: f_user.c:581: Multi-event flag: No. > > 10: f_user.c:586: UDP destination: None. > > 1: lwroc_main.c:132: SIGSEGV received. > > 1: -:0: Backtrace: > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > 1: -:0: [0x100344] > > 1: -:0: [(nil)] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > 1: -:0: Backtrace (again, with addr2line): > > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > 1: -:0: ?? ??:0 > > sh: -c: line 0: syntax error near unexpected token `(' > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > sh: -c: line 0: syntax error near unexpected token `(' > > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 2 > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > 1: -:0: ?? ??:0 > > 1: -:0: ?? ??:0 > > 1: -:0: Backtrace (again, addresses): > > 1: -:0: 0x0x100ae20c: > > 1: -:0: 0x0x100ad56c: > > 1: -:0: 0x0x100ae518: > > 1: -:0: 0x0x100a6374: > > 1: -:0: 0x0x100344: > > 1: -:0: 0x(nil): > > 1: -:0: 0x0x100066c0: > > 1: -:0: 0x0x10073774: > > 1: -:0: 0x0x100a6e98: > > 1: -:0: 0x0x100a7f38: > > 1: -:0: 0x0x100a6890: > > 1: -:0: 0x0x100a5dc0: > > 1: -:0: 0x0xfb91260: > > 1: -:0: 0x0xfb913ec: > > 1: -:0: BUG or FATAL reported. > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > > Send slave abort readout. (1) > > Send master abort (0x200). > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > 1: -:0: Hardware cleanup done. > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > ^C8: lwroc_main.c:105: SIGINT received. > > 10: lwroc_thread_util.c:62: Set terminate first! (main) > > ^C8: lwroc_main.c:105: SIGINT received. > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > > > > > > Looks like DRASI still has a problem ?? > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > > > > > >_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von Weber, Guenter Dr. > > Gesendet: Montag, 15. Juli 2024 16:02:57 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > > > Dear H?kan, > > > > > > thank you for the reply. > > > > > > After implementing the suggested changes, I now get the following warning (on PC): > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > f_user.c: In function 'f_user_init': > > f_user.c:697:2: warning: null argument where non-null required (argument 3) [-Wnonnull] > > crate_dt_release_set_func(g_crate, dt_release, NULL); > > ^~~~~~~~~~~~~~~~~~~~~~~~~ > > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > On the RIO4 there is no warning: > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > UDP:ARPA_INET_H > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > In a few minutes I can tell you if the DAQ is running with the new software or not. > > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > > >_____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Montag, 15. Juli 2024 15:49:23 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > > > Dear G?nter, > > > > it looks like with a change of the second parameter of log_callback (both > > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > > then in compiles. > > > > Likely caused by commit '36772113' in nurdlib that changed line numbers > > from unsigned to int. > > > > Cheers, > > H?kan > > > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear all, > > > > > > > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > > > > > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > > > > > > > When compiling fuser_drasi, the following happens (on PC): > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > > > fuser_drasi > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > For nconf results and logs, see also > > > build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > UDP:ARPA_INET_H > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > f_user.c: In function 'f_user_init': > > > f_user.c:682:26: warning: passing argument 1 of 'nurdlib_setup' from > > > incompatible pointer type [-Wincompatible-pointer-types] > > > g_crate = nurdlib_setup(log_callback, path); > > > ^~~~~~~~~~~~ > > > In file included from f_user.c:15:0: > > > ../nurdlib/include/nurdlib.h:28:15: note: expected 'LogCallback {aka void > > > (*)(const char *, int, unsigned int, const char *)}' but argument is of > > > type 'void (*)(const char *, unsigned int, unsigned int, const char *)' > > > struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > > > ^~~~~~~~~~~~~ > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > > > [-Wnonnull] > > > crate_dt_release_set_func(g_crate, dt_release, NULL); > > > ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > > > > On the RIO4 the warning is a bit less detailed: > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > UDP:ARPA_INET_H > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > f_user.c: In function 'f_user_init': > > > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > > > incompatible pointer type > > > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > Any ideas what might have happened here? Or is this normal behaviour? > > > > > > > > > > > > Many thanks! > > > > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Mon Jul 15 17:40:54 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Mon, 15 Jul 2024 17:40:54 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de> Message-ID: <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> Looks like it breaks in crate_counter_get_diff(). Could you print also g_counter_ms before that line is reached. I'm getting the suspicion that it is NULL. Since the function is quite small: uint32_t crate_counter_get_diff(struct CrateCounter const *a_counter) { return COUNTER_DIFF_RAW(a_counter->cur, a_counter->prev); } and #define COUNTER_DIFF_RAW(c, raw)\ (((c).value - (raw)) & (c).mask) Cheers, H?kan On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > Here is what I did: > > > ? ? printf("before block\n"); ?fflush(stdout); > > ? ? SUBEVENT_BEGIN(0, 0, event_buffer); > ? ? printf("after SUBEVENT_BEGIN \n"); ?fflush(stdout); > ? ? p32 = land_vme = event_buffer.ptr; > ? ? printf("after p32 = land_vme = event_buffer.ptr -> %u \n", p32); ?fflush(stdout); > ? ? *p32++ = LAND_VME_HAS_TIME_STAMP; > ? ? printf("after *p32++ = LAND_VME_HAS_TIME_STAMP -> %u \n", p32); ?fflush(stdout); > ? ? *p32++ = tt; > ? ? printf("after *p32++ = tt -> %u \n", p32); ?fflush(stdout); > ? ? { > ? ? ? ? uint32_t diff; > > ? ? ? ? diff = crate_counter_get_diff(g_counter_ms); > ? ? ? ? printf("after diff -> %u \n", diff); ?fflush(stdout); > ? ? ? ? if (diff > 1 || g_cfg.mevent_flag) { > ? ? ? ? ? ? *land_vme |= LAND_VME_MULTI_EVENT; > ? ? ? ? ? ? *p32++ = diff; > ? ? ? ? } > ? ? } > ? ? EVENT_BUFFER_ADVANCE(event_buffer, p32); > ? ? printf("after EVENT_BUFFER_ADVANCE ?-> %u %u \n", event_buffer, p32); ?fflush(stdout); > ? ? ret |= crate_readout(g_crate, &event_buffer); > ? ? SUBEVENT_END(event_buffer); > > > And this is what we get: > > > before block > after SUBEVENT_BEGIN > after p32 = land_vme = event_buffer.ptr -> 805691484 > after *p32++ = LAND_VME_HAS_TIME_STAMP -> 805691488 > after *p32++ = tt -> 805691492 > 1: lwroc_main.c:132: SIGSEGV received. > 1: -:0: Backtrace: > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae32c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad68c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae638] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6494] > 1: -:0: [0x100344] > 1: -:0: /lib/libc.so.6(fflush+0xb4) [0xfbd78bc] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100067a8] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073894] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6fb8] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a8058] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a69b0] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5ee0] > 1: -:0: /lib/libc.so.6 [0xfb91260] > 1: -:0: /lib/libc.so.6 [0xfb913ec] > 1: -:0: Backtrace (again, with addr2line): > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > 1: -:0: ?? ??:0 > 1: -:0: ?? ??:0 > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:987 > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > 1: -:0: ?? ??:0 > 1: -:0: ?? ??:0 > 1: -:0: BUG or FATAL reported. > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25615 > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > Send slave abort readout. (1) > Send master abort (0x200). > > > ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Montag, 15. Juli 2024 16:50:45 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > Dear H?kan, > > > > > > my f_user.c has the identical block at the identical position. > > > > > > Removing the STRUCK modules from main.cfg does not change the situation: > > That at least removes a lot of unknowns from the equation. ;) > > Could you add a bunch of > > ? printf("a...\n");? fflush(stdout); > > on the lines around that block, se we know better exactly where it > crashes?? And then if that brings it down, also start to print pointer > values (before their use). > > With the backtrace, it is also a bit unclear if it actually is failing on > the line above or below... > > Cheers, > H?kan > > > > > > > > > > > 10: crate/crate.c:1196: crate_init(MCAL) } > > 10: ctrl/ctrl.c:1046: Control server online. > > Message not logged - thread has no error buffer yet... > > 10: f_user.c:559: WR ID=0x200. > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > 10: f_user.c:572: TPAT: No. > > 10: f_user.c:573: Sync-check: No. > > 10: f_user.c:575: Spill triggers: No. > > 10: f_user.c:576: LMU: No. > > 10: f_user.c:577: Timer latches: No. > > 10: f_user.c:578: Spill shape: No. > > 10: f_user.c:579: Micro-structure: No. > > 10: f_user.c:581: Multi-event flag: No. > > 10: f_user.c:586: UDP destination: None. > > 1: lwroc_main.c:132: SIGSEGV received. > > 1: -:0: Backtrace: > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > 1: -:0: [0x100344] > > 1: -:0: [(nil)] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > 1: -:0: Backtrace (again, with addr2line): > > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > 1: -:0: ?? ??:0 > > sh: -c: line 0: syntax error near unexpected token `(' > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > sh: -c: line 0: syntax error near unexpected token `(' > > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > 1: -:0: ?? ??:0 > > 1: -:0: ?? ??:0 > > 1: -:0: Backtrace (again, addresses): > > 1: -:0: 0x0x100ae20c: > > 1: -:0: 0x0x100ad56c: > > 1: -:0: 0x0x100ae518: > > 1: -:0: 0x0x100a6374: > > 1: -:0: 0x0x100344: > > 1: -:0: 0x(nil): > > 1: -:0: 0x0x100066c0: > > 1: -:0: 0x0x10073774: > > 1: -:0: 0x0x100a6e98: > > 1: -:0: 0x0x100a7f38: > > 1: -:0: 0x0x100a6890: > > 1: -:0: 0x0x100a5dc0: > > 1: -:0: 0x0xfb91260: > > 1: -:0: 0x0xfb913ec: > > 1: -:0: BUG or FATAL reported. > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25186 > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > > Send slave abort readout. (1) > > Send master abort (0x200). > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > 1: -:0: Hardware cleanup done. > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > ^C8: lwroc_main.c:105: SIGINT received. > > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > > ^C8: lwroc_main.c:105: SIGINT received. > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > Attached please find the files you asked for. > > > > > > > > Would be really great if you could figure out what is happening. > > > > > > > > > > Best greetings from Jena > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > Looks like the issue might be at: > > > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > > which for me is: > > > > ???????? p32 = land_vme = event_buffer.ptr; > > > > part of a block of code: > > > > ???????? SUBEVENT_BEGIN(0, 0, event_buffer); > > ???????? p32 = land_vme = event_buffer.ptr; > > ???????? *p32++ = LAND_VME_HAS_TIME_STAMP; > > ???????? *p32++ = tt; > > > > or possibly some function that it calls. > > > > You have the same code at that line? > > > > Could you also send the daq startup script and the nurdlib > > configuration file? > > > > Cheers, > > H?kan > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear friends, > > > > > > > > > unfortunately, the DAQ crashes on startup. Here is the output: > > > > > > > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > > Message not logged - thread has no error buffer yet... > > > CPUS: 1 > > > delay: 1 > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > > Message not logged - thread has no error buffer yet... > > > HOST: RIO4-MCAL-1 > > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 (eth1). > > > 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 419430400 = 0x19000000, 1 consumers. > > > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > > > 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). > > > client union size: 244 240 188 508 640 204 204? => 640 > > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > > 10: lwroc_main.c:704: Log message rate limit in effect. > > > 10: lwroc_readout.c:116: call readout_init... > > > 10: lwroc_thread_util.c:118: This is the triva control thread! > > > 10: lwroc_thread_util.c:118: This is the net io thread! > > > 10: lwroc_thread_util.c:118: This is the slow_async thread! > > > 10: lwroc_thread_util.c:118: This is the data server thread! > > > 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB connection(s): > > > 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) > > > 10: lwroc_message_internal.c:485: Message client connected! > > > 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) [192.168.1.1]. > > > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > > > 10: lwroc_triva_control.c:418: Minimum event time ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) > > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > > 9: lwroc_triva_control.c:507: TEST: GO > > > 10: lwroc_triva_control.c:725: RUN: RESET > > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max 2.8 kHz) > > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > > 10: config/config.c:205: Will try default cfg path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: config/parser.c:319: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > > > 10: config/parser.c:331: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > > > 10: config/parser.c:319: Opened './main.cfg' { > > > 10: config/config.c:1388: .Global log level=verbose. > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > > 10: config/parser.c:331: Closed './main.cfg' } > > > 10: crate/crate.c:373: crate_create { > > > 10: crate/crate.c:714: crate_create(MCAL) } > > > 10: crate/crate.c:1022: crate_init(MCAL) { > > > 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. > > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > > 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. > > > 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns wr(0x30000000+0x64/32)=356ns. > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime.??? ? > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. > > > 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns wr(0x31000000+0x64/32)=359ns. > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. > > > 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns wr(0x32000000+0x64/32)=399ns. > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > > 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. > > > 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > > 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. > > > 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. > > > 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. > > > 10: crate/crate.c:1196: crate_init(MCAL) } > > > 10: ctrl/ctrl.c:1046: Control server online. > > > Message not logged - thread has no error buffer yet... > > > 10: f_user.c:559: WR ID=0x200. > > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > > 10: f_user.c:572: TPAT: No. > > > 10: f_user.c:573: Sync-check: No. > > > 10: f_user.c:575: Spill triggers: No. > > > 10: f_user.c:576: LMU: No. > > > 10: f_user.c:577: Timer latches: No. > > > 10: f_user.c:578: Spill shape: No. > > > 10: f_user.c:579: Micro-structure: No. > > > 10: f_user.c:581: Multi-event flag: No. > > > 10: f_user.c:586: UDP destination: None. > > > 1: lwroc_main.c:132: SIGSEGV received. > > > 1: -:0: Backtrace: > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > > 1: -:0: [0x100344] > > > 1: -:0: [(nil)] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > > 1: -:0: Backtrace (again, with addr2line): > > > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > > > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > > > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > > > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > > 1: -:0: ?? ??:0 > > > sh: -c: line 0: syntax error near unexpected token `(' > > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > sh: -c: line 0: syntax error near unexpected token `(' > > > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 2 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > > 1: -:0: ?? ??:0 > > > 1: -:0: ?? ??:0 > > > 1: -:0: Backtrace (again, addresses): > > > 1: -:0: 0x0x100ae20c: > > > 1: -:0: 0x0x100ad56c: > > > 1: -:0: 0x0x100ae518: > > > 1: -:0: 0x0x100a6374: > > > 1: -:0: 0x0x100344: > > > 1: -:0: 0x(nil): > > > 1: -:0: 0x0x100066c0: > > > 1: -:0: 0x0x10073774: > > > 1: -:0: 0x0x100a6e98: > > > 1: -:0: 0x0x100a7f38: > > > 1: -:0: 0x0x100a6890: > > > 1: -:0: 0x0x100a5dc0: > > > 1: -:0: 0x0xfb91260: > > > 1: -:0: 0x0xfb913ec: > > > 1: -:0: BUG or FATAL reported. > > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 > > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > > > Send slave abort readout. (1) > > > Send master abort (0x200). > > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > 1: -:0: Hardware cleanup done. > > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > ^C8: lwroc_main.c:105: SIGINT received. > > > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > > > ^C8: lwroc_main.c:105: SIGINT received. > > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > > > > > > > > > > > Looks like DRASI still has a problem ?? > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > >>____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > _ > > _ > > > Von: subexp-daq im Auftrag von Weber, Guenter Dr. > > > Gesendet: Montag, 15. Juli 2024 16:02:57 > > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > > > > > Dear H?kan, > > > > > > > > > thank you for the reply. > > > > > > > > > After implementing the suggested changes, I now get the following warning (on PC): > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > UDP:ARPA_INET_H > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > f_user.c: In function ?f_user_init?: > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) [-Wnonnull] > > > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > > > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > On the RIO4 there is no warning: > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > UDP:ARPA_INET_H > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > In a few minutes I can tell you if the DAQ is running with the new software or not. > > > > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > > > > > > > >>____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > _ > > _ > > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > Gesendet: Montag, 15. Juli 2024 15:49:23 > > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > > > > > Dear G?nter, > > > > > > it looks like with a change of the second parameter of log_callback (both > > > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > > > then in compiles. > > > > > > Likely caused by commit '36772113' in nurdlib that changed line numbers > > > from unsigned to int. > > > > > > Cheers, > > > H?kan > > > > > > > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > Dear all, > > > > > > > > > > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > > > > > > > > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > > > > > > > > > > When compiling fuser_drasi, the following happens (on PC): > > > > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > > > > fuser_drasi > > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > > For nconf results and logs, see also > > > > build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > > UDP:ARPA_INET_H > > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > > f_user.c: In function ?f_user_init?: > > > > f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from > > > > incompatible pointer type [-Wincompatible-pointer-types] > > > > ? g_crate = nurdlib_setup(log_callback, path); > > > > ????????????????????????? ^~~~~~~~~~~~ > > > > In file included from f_user.c:15:0: > > > > ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void > > > > (*)(const char *, int,? unsigned int,? const char *)}? but argument is of > > > > type ?void (*)(const char *, unsigned int,? unsigned int,? const char *)? > > > > ?struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > > > > ?????????????? ^~~~~~~~~~~~~ > > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > > > > [-Wnonnull] > > > > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > > > > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > > > > > > > On the RIO4 the warning is a bit less detailed: > > > > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > > UDP:ARPA_INET_H > > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > > f_user.c: In function 'f_user_init': > > > > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > > > > incompatible pointer type > > > > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > > > Any ideas what might have happened here? Or is this normal behaviour? > > > > > > > > > > > > > > > > Many thanks! > > > > > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Wed Jul 17 16:51:45 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Wed, 17 Jul 2024 14:51:45 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> Message-ID: <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de> Dear H?kan, yes, the pointer g_counter_ms is zero. What should I do now? Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Montag, 15. Juli 2024 17:40:54 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER Looks like it breaks in crate_counter_get_diff(). Could you print also g_counter_ms before that line is reached. I'm getting the suspicion that it is NULL. Since the function is quite small: uint32_t crate_counter_get_diff(struct CrateCounter const *a_counter) { return COUNTER_DIFF_RAW(a_counter->cur, a_counter->prev); } and #define COUNTER_DIFF_RAW(c, raw)\ (((c).value - (raw)) & (c).mask) Cheers, H?kan On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > Here is what I did: > > > printf("before block\n"); fflush(stdout); > > SUBEVENT_BEGIN(0, 0, event_buffer); > printf("after SUBEVENT_BEGIN \n"); fflush(stdout); > p32 = land_vme = event_buffer.ptr; > printf("after p32 = land_vme = event_buffer.ptr -> %u \n", p32); fflush(stdout); > *p32++ = LAND_VME_HAS_TIME_STAMP; > printf("after *p32++ = LAND_VME_HAS_TIME_STAMP -> %u \n", p32); fflush(stdout); > *p32++ = tt; > printf("after *p32++ = tt -> %u \n", p32); fflush(stdout); > { > uint32_t diff; > > diff = crate_counter_get_diff(g_counter_ms); > printf("after diff -> %u \n", diff); fflush(stdout); > if (diff > 1 || g_cfg.mevent_flag) { > *land_vme |= LAND_VME_MULTI_EVENT; > *p32++ = diff; > } > } > EVENT_BUFFER_ADVANCE(event_buffer, p32); > printf("after EVENT_BUFFER_ADVANCE -> %u %u \n", event_buffer, p32); fflush(stdout); > ret |= crate_readout(g_crate, &event_buffer); > SUBEVENT_END(event_buffer); > > > And this is what we get: > > > before block > after SUBEVENT_BEGIN > after p32 = land_vme = event_buffer.ptr -> 805691484 > after *p32++ = LAND_VME_HAS_TIME_STAMP -> 805691488 > after *p32++ = tt -> 805691492 > 1: lwroc_main.c:132: SIGSEGV received. > 1: -:0: Backtrace: > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae32c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad68c] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae638] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6494] > 1: -:0: [0x100344] > 1: -:0: /lib/libc.so.6(fflush+0xb4) [0xfbd78bc] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100067a8] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073894] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6fb8] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a8058] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a69b0] > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5ee0] > 1: -:0: /lib/libc.so.6 [0xfb91260] > 1: -:0: /lib/libc.so.6 [0xfb913ec] > 1: -:0: Backtrace (again, with addr2line): > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > 1: -:0: ?? ??:0 > 1: -:0: ?? ??:0 > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:987 > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > 1: -:0: ?? ??:0 > 1: -:0: ?? ??:0 > 1: -:0: BUG or FATAL reported. > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25615 > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > Send slave abort readout. (1) > Send master abort (0x200). > > > ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Montag, 15. Juli 2024 16:50:45 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > Dear H?kan, > > > > > > my f_user.c has the identical block at the identical position. > > > > > > Removing the STRUCK modules from main.cfg does not change the situation: > > That at least removes a lot of unknowns from the equation. ;) > > Could you add a bunch of > > printf("a...\n"); fflush(stdout); > > on the lines around that block, se we know better exactly where it > crashes? And then if that brings it down, also start to print pointer > values (before their use). > > With the backtrace, it is also a bit unclear if it actually is failing on > the line above or below... > > Cheers, > H?kan > > > > > > > > > > > 10: crate/crate.c:1196: crate_init(MCAL) } > > 10: ctrl/ctrl.c:1046: Control server online. > > Message not logged - thread has no error buffer yet... > > 10: f_user.c:559: WR ID=0x200. > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > 10: f_user.c:572: TPAT: No. > > 10: f_user.c:573: Sync-check: No. > > 10: f_user.c:575: Spill triggers: No. > > 10: f_user.c:576: LMU: No. > > 10: f_user.c:577: Timer latches: No. > > 10: f_user.c:578: Spill shape: No. > > 10: f_user.c:579: Micro-structure: No. > > 10: f_user.c:581: Multi-event flag: No. > > 10: f_user.c:586: UDP destination: None. > > 1: lwroc_main.c:132: SIGSEGV received. > > 1: -:0: Backtrace: > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > 1: -:0: [0x100344] > > 1: -:0: [(nil)] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > 1: -:0: Backtrace (again, with addr2line): > > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > 1: -:0: ?? ??:0 > > sh: -c: line 0: syntax error near unexpected token `(' > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > sh: -c: line 0: syntax error near unexpected token `(' > > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > 1: -:0: ?? ??:0 > > 1: -:0: ?? ??:0 > > 1: -:0: Backtrace (again, addresses): > > 1: -:0: 0x0x100ae20c: > > 1: -:0: 0x0x100ad56c: > > 1: -:0: 0x0x100ae518: > > 1: -:0: 0x0x100a6374: > > 1: -:0: 0x0x100344: > > 1: -:0: 0x(nil): > > 1: -:0: 0x0x100066c0: > > 1: -:0: 0x0x10073774: > > 1: -:0: 0x0x100a6e98: > > 1: -:0: 0x0x100a7f38: > > 1: -:0: 0x0x100a6890: > > 1: -:0: 0x0x100a5dc0: > > 1: -:0: 0x0xfb91260: > > 1: -:0: 0x0xfb913ec: > > 1: -:0: BUG or FATAL reported. > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25186 > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > > Send slave abort readout. (1) > > Send master abort (0x200). > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > 1: -:0: Hardware cleanup done. > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > ^C8: lwroc_main.c:105: SIGINT received. > > 10: lwroc_thread_util.c:62: Set terminate first! (main) > > ^C8: lwroc_main.c:105: SIGINT received. > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > Attached please find the files you asked for. > > > > > > > > Would be really great if you could figure out what is happening. > > > > > > > > > > Best greetings from Jena > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > Looks like the issue might be at: > > > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > > which for me is: > > > > p32 = land_vme = event_buffer.ptr; > > > > part of a block of code: > > > > SUBEVENT_BEGIN(0, 0, event_buffer); > > p32 = land_vme = event_buffer.ptr; > > *p32++ = LAND_VME_HAS_TIME_STAMP; > > *p32++ = tt; > > > > or possibly some function that it calls. > > > > You have the same code at that line? > > > > Could you also send the daq startup script and the nurdlib > > configuration file? > > > > Cheers, > > H?kan > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear friends, > > > > > > > > > unfortunately, the DAQ crashes on startup. Here is the output: > > > > > > > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > > Message not logged - thread has no error buffer yet... > > > CPUS: 1 > > > delay: 1 > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > > Message not logged - thread has no error buffer yet... > > > HOST: RIO4-MCAL-1 > > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 (eth1). > > > 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 419430400 = 0x19000000, 1 consumers. > > > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) > > > 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). > > > client union size: 244 240 188 508 640 204 204 => 640 > > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > > 10: lwroc_main.c:704: Log message rate limit in effect. > > > 10: lwroc_readout.c:116: call readout_init... > > > 10: lwroc_thread_util.c:118: This is the triva control thread! > > > 10: lwroc_thread_util.c:118: This is the net io thread! > > > 10: lwroc_thread_util.c:118: This is the slow_async thread! > > > 10: lwroc_thread_util.c:118: This is the data server thread! > > > 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB connection(s): > > > 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) > > > 10: lwroc_message_internal.c:485: Message client connected! > > > 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) [192.168.1.1]. > > > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) > > > 10: lwroc_triva_control.c:418: Minimum event time ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) > > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > > 9: lwroc_triva_control.c:507: TEST: GO > > > 10: lwroc_triva_control.c:725: RUN: RESET > > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 2.8 kHz) > > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > > 10: config/config.c:205: Will try default cfg path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set with NURDLIB_DEF_PATH. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: config/parser.c:319: Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > > > 10: config/parser.c:331: Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > > > 10: config/parser.c:319: Opened './main.cfg' { > > > 10: config/config.c:1388: .Global log level=verbose. > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > 10: config/parser.c:319: .Opened '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' { > > > 10: config/parser.c:331: .Closed '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level.cfg' } > > > 10: config/parser.c:331: Closed './main.cfg' } > > > 10: crate/crate.c:373: crate_create { > > > 10: crate/crate.c:714: crate_create(MCAL) } > > > 10: crate/crate.c:1022: crate_init(MCAL) { > > > 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. > > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > > 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. > > > 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns wr(0x30000000+0x64/32)=356ns. > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. > > > 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns wr(0x31000000+0x64/32)=359ns. > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. > > > 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns wr(0x32000000+0x64/32)=399ns. > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > > 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. > > > 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 1 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > > 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. > > > 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. > > > 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. > > > 10: crate/crate.c:1196: crate_init(MCAL) } > > > 10: ctrl/ctrl.c:1046: Control server online. > > > Message not logged - thread has no error buffer yet... > > > 10: f_user.c:559: WR ID=0x200. > > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > > 10: f_user.c:572: TPAT: No. > > > 10: f_user.c:573: Sync-check: No. > > > 10: f_user.c:575: Spill triggers: No. > > > 10: f_user.c:576: LMU: No. > > > 10: f_user.c:577: Timer latches: No. > > > 10: f_user.c:578: Spill shape: No. > > > 10: f_user.c:579: Micro-structure: No. > > > 10: f_user.c:581: Multi-event flag: No. > > > 10: f_user.c:586: UDP destination: None. > > > 1: lwroc_main.c:132: SIGSEGV received. > > > 1: -:0: Backtrace: > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > > 1: -:0: [0x100344] > > > 1: -:0: [(nil)] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > > 1: -:0: Backtrace (again, with addr2line): > > > 1: -:0: lwroc_dump_backtrace /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:951 > > > 1: -:0: lwroc_do_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1590 > > > 1: -:0: lwroc_message_internal /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1692 > > > 1: -:0: lwroc_sighandler /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > > 1: -:0: ?? ??:0 > > > sh: -c: line 0: syntax error near unexpected token `(' > > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > sh: -c: line 0: syntax error near unexpected token `(' > > > sh: -c: line 0: `addr2line -i -f -C (nil) -e ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > 1: -:0: fud_read_event /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > > 1: -:0: lwroc_triva_event_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 2 > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > 1: -:0: lwroc_triva_readout /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > > 1: -:0: lwroc_main_loop /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > > 1: -:0: main /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > > 1: -:0: ?? ??:0 > > > 1: -:0: ?? ??:0 > > > 1: -:0: Backtrace (again, addresses): > > > 1: -:0: 0x0x100ae20c: > > > 1: -:0: 0x0x100ad56c: > > > 1: -:0: 0x0x100ae518: > > > 1: -:0: 0x0x100a6374: > > > 1: -:0: 0x0x100344: > > > 1: -:0: 0x(nil): > > > 1: -:0: 0x0x100066c0: > > > 1: -:0: 0x0x10073774: > > > 1: -:0: 0x0x100a6e98: > > > 1: -:0: 0x0x100a7f38: > > > 1: -:0: 0x0x100a6890: > > > 1: -:0: 0x0x100a5dc0: > > > 1: -:0: 0x0xfb91260: > > > 1: -:0: 0x0xfb913ec: > > > 1: -:0: BUG or FATAL reported. > > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 > > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to abort. > > > Send slave abort readout. (1) > > > Send master abort (0x200). > > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > 1: -:0: Hardware cleanup done. > > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > ^C8: lwroc_main.c:105: SIGINT received. > > > 10: lwroc_thread_util.c:62: Set terminate first! (main) > > > ^C8: lwroc_main.c:105: SIGINT received. > > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > > > > > > > > > > > Looks like DRASI still has a problem ?? > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > >>____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > _ > > _ > > > Von: subexp-daq im Auftrag von Weber, Guenter Dr. > > > Gesendet: Montag, 15. Juli 2024 16:02:57 > > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > > > > > Dear H?kan, > > > > > > > > > thank you for the reply. > > > > > > > > > After implementing the suggested changes, I now get the following warning (on PC): > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > UDP:ARPA_INET_H > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > f_user.c: In function 'f_user_init': > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) [-Wnonnull] > > > crate_dt_release_set_func(g_crate, dt_release, NULL); > > > ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > On the RIO4 there is no warning: > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > UDP:ARPA_INET_H > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > In a few minutes I can tell you if the DAQ is running with the new software or not. > > > > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > > > > > > > >>____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ > _ > > _ > > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > Gesendet: Montag, 15. Juli 2024 15:49:23 > > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > > > > > Dear G?nter, > > > > > > it looks like with a change of the second parameter of log_callback (both > > > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > > > then in compiles. > > > > > > Likely caused by commit '36772113' in nurdlib that changed line numbers > > > from unsigned to int. > > > > > > Cheers, > > > H?kan > > > > > > > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > Dear all, > > > > > > > > > > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > > > > > > > > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > > > > > > > > > > When compiling fuser_drasi, the following happens (on PC): > > > > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > > > > fuser_drasi > > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > > For nconf results and logs, see also > > > > build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > > UDP:ARPA_INET_H > > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > > f_user.c: In function 'f_user_init': > > > > f_user.c:682:26: warning: passing argument 1 of 'nurdlib_setup' from > > > > incompatible pointer type [-Wincompatible-pointer-types] > > > > g_crate = nurdlib_setup(log_callback, path); > > > > ^~~~~~~~~~~~ > > > > In file included from f_user.c:15:0: > > > > ../nurdlib/include/nurdlib.h:28:15: note: expected 'LogCallback {aka void > > > > (*)(const char *, int, unsigned int, const char *)}' but argument is of > > > > type 'void (*)(const char *, unsigned int, unsigned int, const char *)' > > > > struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > > > > ^~~~~~~~~~~~~ > > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > > > > [-Wnonnull] > > > > crate_dt_release_set_func(g_crate, dt_release, NULL); > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > > > > > > > On the RIO4 the warning is a bit less detailed: > > > > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > > UDP:ARPA_INET_H > > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > > f_user.c: In function 'f_user_init': > > > > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > > > > incompatible pointer type > > > > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > > > Any ideas what might have happened here? Or is this normal behaviour? > > > > > > > > > > > > > > > > Many thanks! > > > > > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Wed Jul 17 17:05:09 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 17 Jul 2024 17:05:09 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de> Message-ID: <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> Dear G?nter, We are in Hans' territory here, so I am a bit lost. Since g_counter_ms is not used elsewhere, you could try to replace diff = crate_counter_get_diff(g_counter_ms); with just diff = 1; and we see if the DAQ is willing to run. It might be that unpacking fails later with the SIS3316 enabled. Assuming this is the same error that hit also when the SIS3316 modules were enabled, the issue should (now) not be that there are no modules configured, but something else. And, if it runs, you could see if the SIS3316 modules are willing to start at least with that change. Cheers, H?kan On Wed, 17 Jul 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > yes, the pointer g_counter_ms is zero. > > > > What should I do now? > > > > > > Best greetings > > G?nter > > > > _________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Montag, 15. Juli 2024 17:40:54 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > Looks like it breaks in crate_counter_get_diff(). > > Could you print also g_counter_ms before that line is reached. > > I'm getting the suspicion that it is NULL. > > Since the function is quite small: > > uint32_t > crate_counter_get_diff(struct CrateCounter const *a_counter) > { > ???????? return COUNTER_DIFF_RAW(a_counter->cur, a_counter->prev); > } > > and > > #define COUNTER_DIFF_RAW(c, raw)\ > ???? (((c).value - (raw)) & (c).mask) > > Cheers, > H?kan > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Here is what I did: > > > > > > ? ? printf("before block\n"); ?fflush(stdout); > > > > ? ? SUBEVENT_BEGIN(0, 0, event_buffer); > > ? ? printf("after SUBEVENT_BEGIN \n"); ?fflush(stdout); > > ? ? p32 = land_vme = event_buffer.ptr; > > ? ? printf("after p32 = land_vme = event_buffer.ptr -> %u \n", p32); ?fflush(stdout); > > ? ? *p32++ = LAND_VME_HAS_TIME_STAMP; > > ? ? printf("after *p32++ = LAND_VME_HAS_TIME_STAMP -> %u \n", p32); ?fflush(stdout); > > ? ? *p32++ = tt; > > ? ? printf("after *p32++ = tt -> %u \n", p32); ?fflush(stdout); > > ? ? { > > ? ? ? ? uint32_t diff; > > > > ? ? ? ? diff = crate_counter_get_diff(g_counter_ms); > > ? ? ? ? printf("after diff -> %u \n", diff); ?fflush(stdout); > > ? ? ? ? if (diff > 1 || g_cfg.mevent_flag) { > > ? ? ? ? ? ? *land_vme |= LAND_VME_MULTI_EVENT; > > ? ? ? ? ? ? *p32++ = diff; > > ? ? ? ? } > > ? ? } > > ? ? EVENT_BUFFER_ADVANCE(event_buffer, p32); > > ? ? printf("after EVENT_BUFFER_ADVANCE ?-> %u %u \n", event_buffer, p32); > ?fflush(stdout); > > ? ? ret |= crate_readout(g_crate, &event_buffer); > > ? ? SUBEVENT_END(event_buffer); > > > > > > And this is what we get: > > > > > > before block > > after SUBEVENT_BEGIN > > after p32 = land_vme = event_buffer.ptr -> 805691484 > > after *p32++ = LAND_VME_HAS_TIME_STAMP -> 805691488 > > after *p32++ = tt -> 805691492 > > 1: lwroc_main.c:132: SIGSEGV received. > > 1: -:0: Backtrace: > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae32c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad68c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae638] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6494] > > 1: -:0: [0x100344] > > 1: -:0: /lib/libc.so.6(fflush+0xb4) [0xfbd78bc] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100067a8] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073894] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6fb8] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a8058] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a69b0] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5ee0] > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > 1: -:0: Backtrace (again, with addr2line): > > 1: -:0: lwroc_dump_backtrace/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:9 > 51 > > 1: -:0: lwroc_do_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 590 > > 1: -:0: lwroc_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 692 > > 1: -:0: lwroc_sighandler > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > 1: -:0: ?? ??:0 > > 1: -:0: ?? ??:0 > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:987 > > 1: -:0: fud_read_event > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > 1: -:0: lwroc_triva_event_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > 1: -:0: lwroc_triva_readout > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > 1: -:0: lwroc_main_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > 1: -:0: main > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > 1: -:0: ?? ??:0 > > 1: -:0: ?? ??:0 > > 1: -:0: BUG or FATAL reported. > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; > gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25615 > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to > abort. > > Send slave abort readout. (1) > > Send master abort (0x200). > > > > > >________________________________________________________________________________________ > _______________________________________________________________________________________ > _______________________________________________________________________________________ > ________________ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > Gesendet: Montag, 15. Juli 2024 16:50:45 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear H?kan, > > > > > > > > > my f_user.c has the identical block at the identical position. > > > > > > > > > Removing the STRUCK modules from main.cfg does not change the situation: > > > > That at least removes a lot of unknowns from the equation. ;) > > > > Could you add a bunch of > > > > ? printf("a...\n");? fflush(stdout); > > > > on the lines around that block, se we know better exactly where it > > crashes?? And then if that brings it down, also start to print pointer > > values (before their use). > > > > With the backtrace, it is also a bit unclear if it actually is failing on > > the line above or below... > > > > Cheers, > > H?kan > > > > > > > > > > > > > > > > > > > 10: crate/crate.c:1196: crate_init(MCAL) } > > > 10: ctrl/ctrl.c:1046: Control server online. > > > Message not logged - thread has no error buffer yet... > > > 10: f_user.c:559: WR ID=0x200. > > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > > 10: f_user.c:572: TPAT: No. > > > 10: f_user.c:573: Sync-check: No. > > > 10: f_user.c:575: Spill triggers: No. > > > 10: f_user.c:576: LMU: No. > > > 10: f_user.c:577: Timer latches: No. > > > 10: f_user.c:578: Spill shape: No. > > > 10: f_user.c:579: Micro-structure: No. > > > 10: f_user.c:581: Multi-event flag: No. > > > 10: f_user.c:586: UDP destination: None. > > > 1: lwroc_main.c:132: SIGSEGV received. > > > 1: -:0: Backtrace: > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > > 1: -:0: [0x100344] > > > 1: -:0: [(nil)] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > > 1: -:0: Backtrace (again, with addr2line): > > > 1: -:0: lwroc_dump_backtrace/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:9 > 51 > > > 1: -:0: lwroc_do_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 590 > > > 1: -:0: lwroc_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 692 > > > 1: -:0: lwroc_sighandler > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > > 1: -:0: ?? ??:0 > > > sh: -c: line 0: syntax error near unexpected token `(' > > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > sh: -c: line 0: syntax error near unexpected token `(' > > > sh: -c: line 0: `addr2line -i -f -C (nil) -e > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > 1: -:0: f_user_readout > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > 1: -:0: fud_read_event > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > > 1: -:0: lwroc_triva_event_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > > 1: -:0: lwroc_triva_readout > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > > 1: -:0: lwroc_main_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > > 1: -:0: main > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > > 1: -:0: ?? ??:0 > > > 1: -:0: ?? ??:0 > > > 1: -:0: Backtrace (again, addresses): > > > 1: -:0: 0x0x100ae20c: > > > 1: -:0: 0x0x100ad56c: > > > 1: -:0: 0x0x100ae518: > > > 1: -:0: 0x0x100a6374: > > > 1: -:0: 0x0x100344: > > > 1: -:0: 0x(nil): > > > 1: -:0: 0x0x100066c0: > > > 1: -:0: 0x0x10073774: > > > 1: -:0: 0x0x100a6e98: > > > 1: -:0: 0x0x100a7f38: > > > 1: -:0: 0x0x100a6890: > > > 1: -:0: 0x0x100a5dc0: > > > 1: -:0: 0x0xfb91260: > > > 1: -:0: 0x0xfb913ec: > > > 1: -:0: BUG or FATAL reported. > > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; > gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25186 > > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to > abort. > > > Send slave abort readout. (1) > > > Send master abort (0x200). > > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > 1: -:0: Hardware cleanup done. > > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > ^C8: lwroc_main.c:105: SIGINT received. > > > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > > > ^C8: lwroc_main.c:105: SIGINT received. > > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > > Attached please find the files you asked for. > > > > > > > > > > > > Would be really great if you could figure out what is happening. > > > > > > > > > > > > > > > Best greetings from Jena > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Looks like the issue might be at: > > > > > > 1: -:0: f_user_readout > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > > > > which for me is: > > > > > > ???????? p32 = land_vme = event_buffer.ptr; > > > > > > part of a block of code: > > > > > > ???????? SUBEVENT_BEGIN(0, 0, event_buffer); > > > ???????? p32 = land_vme = event_buffer.ptr; > > > ???????? *p32++ = LAND_VME_HAS_TIME_STAMP; > > > ???????? *p32++ = tt; > > > > > > or possibly some function that it calls. > > > > > > You have the same code at that line? > > > > > > Could you also send the daq startup script and the nurdlib > > > configuration file? > > > > > > Cheers, > > > H?kan > > > > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > Dear friends, > > > > > > > > > > > > unfortunately, the DAQ crashes on startup. Here is the output: > > > > > > > > > > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > > > Message not logged - thread has no error buffer yet... > > > > CPUS: 1 > > > > delay: 1 > > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > > > Message not logged - thread has no error buffer yet... > > > > HOST: RIO4-MCAL-1 > > > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > > > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 (eth1). > > > > 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 419430400 = > 0x19000000, 1 consumers. > > > > 10: lwroc_triva_readout.c:66: Silence TRIVA? (HALT) > > > > 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). > > > > client union size: 244 240 188 508 640 204 204? => 640 > > > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > > > 10: lwroc_main.c:704: Log message rate limit in effect. > > > > 10: lwroc_readout.c:116: call readout_init... > > > > 10: lwroc_thread_util.c:118: This is the triva control thread! > > > > 10: lwroc_thread_util.c:118: This is the net io thread! > > > > 10: lwroc_thread_util.c:118: This is the slow_async thread! > > > > 10: lwroc_thread_util.c:118: This is the data server thread! > > > > 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. > > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB > connection(s): > > > > 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) > > > > 10: lwroc_message_internal.c:485: Message client connected! > > > > 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) > [192.168.1.1]. > > > > 10: lwroc_triva_control.c:370: Setup TRIVA? (DISBUS, HALT, MASTER, RESET) > > > > 10: lwroc_triva_control.c:418: Minimum event time > ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) > > > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > > > 9: lwroc_triva_control.c:507: TEST: GO > > > > 10: lwroc_triva_control.c:725: RUN: RESET > > > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > > > 9: lwroc_triva_control.c:737:?? GO (1 good test triggers done) (max 2.8 kHz) > > > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > > > 10: config/config.c:205: Will try default cfg > path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set > with NURDLIB_DEF_PATH. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: config/parser.c:319: Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > > > > 10: config/parser.c:331: Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > > > > 10: config/parser.c:319: Opened './main.cfg' { > > > > 10: config/config.c:1388: .Global log level=verbose. > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > > > > 10: config/parser.c:319: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' { > > > > 10: config/parser.c:331: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' } > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > > 10: config/parser.c:319: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' { > > > > 10: config/parser.c:331: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' } > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > > 10: config/parser.c:319: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' { > > > > 10: config/parser.c:331: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' } > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > > 10: config/parser.c:319: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' { > > > > 10: config/parser.c:331: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' } > > > > 10: config/parser.c:331: Closed './main.cfg' } > > > > 10: crate/crate.c:373: crate_create { > > > > 10: crate/crate.c:714: crate_create(MCAL) } > > > > 10: crate/crate.c:1022: crate_init(MCAL) { > > > > 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. > > > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > > > 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. > > > > 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns > wr(0x30000000+0x64/32)=356ns. > > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. > > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime.??? ? > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. > > > > 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns > wr(0x31000000+0x64/32)=359ns. > > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. > > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. > > > > 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns > wr(0x32000000+0x64/32)=399ns. > > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. > > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > > > 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. > > > > 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > > > 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. > > > > 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. > > > > 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. > > > > 10: crate/crate.c:1196: crate_init(MCAL) } > > > > 10: ctrl/ctrl.c:1046: Control server online. > > > > Message not logged - thread has no error buffer yet... > > > > 10: f_user.c:559: WR ID=0x200. > > > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > > > 10: f_user.c:572: TPAT: No. > > > > 10: f_user.c:573: Sync-check: No. > > > > 10: f_user.c:575: Spill triggers: No. > > > > 10: f_user.c:576: LMU: No. > > > > 10: f_user.c:577: Timer latches: No. > > > > 10: f_user.c:578: Spill shape: No. > > > > 10: f_user.c:579: Micro-structure: No. > > > > 10: f_user.c:581: Multi-event flag: No. > > > > 10: f_user.c:586: UDP destination: None. > > > > 1: lwroc_main.c:132: SIGSEGV received. > > > > 1: -:0: Backtrace: > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > > > 1: -:0: [0x100344] > > > > 1: -:0: [(nil)] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > > > 1: -:0: Backtrace (again, with addr2line): > > > > 1: -:0: lwroc_dump_backtrace/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:9 > 51 > > > > 1: -:0: lwroc_do_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 590 > > > > 1: -:0: lwroc_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 692 > > > > 1: -:0: lwroc_sighandler > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > > > 1: -:0: ?? ??:0 > > > > sh: -c: line 0: syntax error near unexpected token `(' > > > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > > sh: -c: line 0: syntax error near unexpected token `(' > > > > sh: -c: line 0: `addr2line -i -f -C (nil) -e > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > > 1: -:0: f_user_readout > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > > 1: -:0: fud_read_event > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > > > 1: -:0: lwroc_triva_event_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: > 2 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 1: -:0: lwroc_triva_readout > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > > > 1: -:0: lwroc_main_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > > > 1: -:0: main > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > > > 1: -:0: ?? ??:0 > > > > 1: -:0: ?? ??:0 > > > > 1: -:0: Backtrace (again, addresses): > > > > 1: -:0: 0x0x100ae20c: > > > > 1: -:0: 0x0x100ad56c: > > > > 1: -:0: 0x0x100ae518: > > > > 1: -:0: 0x0x100a6374: > > > > 1: -:0: 0x0x100344: > > > > 1: -:0: 0x(nil): > > > > 1: -:0: 0x0x100066c0: > > > > 1: -:0: 0x0x10073774: > > > > 1: -:0: 0x0x100a6e98: > > > > 1: -:0: 0x0x100a7f38: > > > > 1: -:0: 0x0x100a6890: > > > > 1: -:0: 0x0x100a5dc0: > > > > 1: -:0: 0x0xfb91260: > > > > 1: -:0: 0x0xfb913ec: > > > > 1: -:0: BUG or FATAL reported. > > > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 > ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 > > > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to > abort. > > > > Send slave abort readout. (1) > > > > Send master abort (0x200). > > > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort > test/readout: > > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > > 1: -:0: Hardware cleanup done. > > > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort > test/readout: > > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > > 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort > test/readout: > > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > > ^C8: lwroc_main.c:105: SIGINT received. > > > > 10: lwroc_thread_util.c:62: Set terminate first!? (main) > > > > ^C8: lwroc_main.c:105: SIGINT received. > > > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > > > > > > > > > > > > > > > > Looks like DRASI still has a problem ?? > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>>______________________________________________________________________________________ > _______________________________________________________________________________________ > _______________________________________________________________________________________ > ________________ > > _ > > > _ > > > > Von: subexp-daq im Auftrag von Weber, > Guenter Dr. > > > > Gesendet: Montag, 15. Juli 2024 16:02:57 > > > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > > > > > > > Dear H?kan, > > > > > > > > > > > > thank you for the reply. > > > > > > > > > > > > After implementing the suggested changes, I now get the following warning (on PC): > > > > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi > > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > > For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > > UDP:ARPA_INET_H > > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > > f_user.c: In function ?f_user_init?: > > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > [-Wnonnull] > > > > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > > > > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > > > On the RIO4 there is no warning: > > > > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > > UDP:ARPA_INET_H > > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > > > In a few minutes I can tell you if the DAQ is running with the new software or not. > > > > > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > >>>______________________________________________________________________________________ > _______________________________________________________________________________________ > _______________________________________________________________________________________ > ________________ > > _ > > > _ > > > > Von: subexp-daq im Auftrag von H?kan T > Johansson > > > > Gesendet: Montag, 15. Juli 2024 15:49:23 > > > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > > > > > > > Dear G?nter, > > > > > > > > it looks like with a change of the second parameter of log_callback (both > > > > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > > > > then in compiles. > > > > > > > > Likely caused by commit '36772113' in nurdlib that changed line numbers > > > > from unsigned to int. > > > > > > > > Cheers, > > > > H?kan > > > > > > > > > > > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > > > > > > > > > > > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > > > > > > > > > > > > > When compiling fuser_drasi, the following happens (on PC): > > > > > > > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > > > > > fuser_drasi > > > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > > > For nconf results and logs, see also > > > > > build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > > > UDP:ARPA_INET_H > > > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > > > CC??? build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > > > CC??? build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > > > f_user.c: In function ?f_user_init?: > > > > > f_user.c:682:26: warning: passing argument 1 of ?nurdlib_setup? from > > > > > incompatible pointer type [-Wincompatible-pointer-types] > > > > > ? g_crate = nurdlib_setup(log_callback, path); > > > > > ????????????????????????? ^~~~~~~~~~~~ > > > > > In file included from f_user.c:15:0: > > > > > ../nurdlib/include/nurdlib.h:28:15: note: expected ?LogCallback {aka void > > > > > (*)(const char *, int,? unsigned int,? const char *)}? but argument is of > > > > > type ?void (*)(const char *, unsigned int,? unsigned int,? const char *)? > > > > > ?struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > > > > > ?????????????? ^~~~~~~~~~~~~ > > > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > > > > > [-Wnonnull] > > > > > ? crate_dt_release_set_func(g_crate, dt_release, NULL); > > > > > ? ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > CC??? build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > > > LD??? build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > > > > > > > > > > On the RIO4 the warning is a bit less detailed: > > > > > > > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > > > UDP:ARPA_INET_H > > > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > > > CC??? build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > > > f_user.c: In function 'f_user_init': > > > > > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > > > > > incompatible pointer type > > > > > CC??? build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > > > CC??? build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > > > LD??? build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > > > > > Any ideas what might have happened here? Or is this normal behaviour? > > > > > > > > > > > > > > > > > > > > Many thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Thu Jul 18 10:55:44 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 18 Jul 2024 08:55:44 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de>, <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> Message-ID: Dear H?kan, with diff = 1 the DAQ is running as long as only the VULOM4B is readout. Adding a SIS3316 module results in an readout error of that module, followed by a reset of the DAQ. Thus, I am currently unable to test SIS3316_check_hit_reworked_rebased. Sorry :-( Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Mittwoch, 17. Juli 2024 17:05:09 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER Dear G?nter, We are in Hans' territory here, so I am a bit lost. Since g_counter_ms is not used elsewhere, you could try to replace diff = crate_counter_get_diff(g_counter_ms); with just diff = 1; and we see if the DAQ is willing to run. It might be that unpacking fails later with the SIS3316 enabled. Assuming this is the same error that hit also when the SIS3316 modules were enabled, the issue should (now) not be that there are no modules configured, but something else. And, if it runs, you could see if the SIS3316 modules are willing to start at least with that change. Cheers, H?kan On Wed, 17 Jul 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > yes, the pointer g_counter_ms is zero. > > > > What should I do now? > > > > > > Best greetings > > G?nter > > > > _________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Montag, 15. Juli 2024 17:40:54 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > Looks like it breaks in crate_counter_get_diff(). > > Could you print also g_counter_ms before that line is reached. > > I'm getting the suspicion that it is NULL. > > Since the function is quite small: > > uint32_t > crate_counter_get_diff(struct CrateCounter const *a_counter) > { > return COUNTER_DIFF_RAW(a_counter->cur, a_counter->prev); > } > > and > > #define COUNTER_DIFF_RAW(c, raw)\ > (((c).value - (raw)) & (c).mask) > > Cheers, > H?kan > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Here is what I did: > > > > > > printf("before block\n"); fflush(stdout); > > > > SUBEVENT_BEGIN(0, 0, event_buffer); > > printf("after SUBEVENT_BEGIN \n"); fflush(stdout); > > p32 = land_vme = event_buffer.ptr; > > printf("after p32 = land_vme = event_buffer.ptr -> %u \n", p32); fflush(stdout); > > *p32++ = LAND_VME_HAS_TIME_STAMP; > > printf("after *p32++ = LAND_VME_HAS_TIME_STAMP -> %u \n", p32); fflush(stdout); > > *p32++ = tt; > > printf("after *p32++ = tt -> %u \n", p32); fflush(stdout); > > { > > uint32_t diff; > > > > diff = crate_counter_get_diff(g_counter_ms); > > printf("after diff -> %u \n", diff); fflush(stdout); > > if (diff > 1 || g_cfg.mevent_flag) { > > *land_vme |= LAND_VME_MULTI_EVENT; > > *p32++ = diff; > > } > > } > > EVENT_BUFFER_ADVANCE(event_buffer, p32); > > printf("after EVENT_BUFFER_ADVANCE -> %u %u \n", event_buffer, p32); > fflush(stdout); > > ret |= crate_readout(g_crate, &event_buffer); > > SUBEVENT_END(event_buffer); > > > > > > And this is what we get: > > > > > > before block > > after SUBEVENT_BEGIN > > after p32 = land_vme = event_buffer.ptr -> 805691484 > > after *p32++ = LAND_VME_HAS_TIME_STAMP -> 805691488 > > after *p32++ = tt -> 805691492 > > 1: lwroc_main.c:132: SIGSEGV received. > > 1: -:0: Backtrace: > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae32c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad68c] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae638] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6494] > > 1: -:0: [0x100344] > > 1: -:0: /lib/libc.so.6(fflush+0xb4) [0xfbd78bc] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100067a8] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073894] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6fb8] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a8058] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a69b0] > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5ee0] > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > 1: -:0: Backtrace (again, with addr2line): > > 1: -:0: lwroc_dump_backtrace/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:9 > 51 > > 1: -:0: lwroc_do_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 590 > > 1: -:0: lwroc_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 692 > > 1: -:0: lwroc_sighandler > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > 1: -:0: ?? ??:0 > > 1: -:0: ?? ??:0 > > 1: -:0: f_user_readout /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:987 > > 1: -:0: fud_read_event > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > 1: -:0: lwroc_triva_event_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > 1: -:0: lwroc_triva_readout > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > 1: -:0: lwroc_main_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > 1: -:0: main > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > 1: -:0: ?? ??:0 > > 1: -:0: ?? ??:0 > > 1: -:0: BUG or FATAL reported. > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; > gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25615 > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to > abort. > > Send slave abort readout. (1) > > Send master abort (0x200). > > > > > >________________________________________________________________________________________ > _______________________________________________________________________________________ > _______________________________________________________________________________________ > ________________ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > Gesendet: Montag, 15. Juli 2024 16:50:45 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear H?kan, > > > > > > > > > my f_user.c has the identical block at the identical position. > > > > > > > > > Removing the STRUCK modules from main.cfg does not change the situation: > > > > That at least removes a lot of unknowns from the equation. ;) > > > > Could you add a bunch of > > > > printf("a...\n"); fflush(stdout); > > > > on the lines around that block, se we know better exactly where it > > crashes? And then if that brings it down, also start to print pointer > > values (before their use). > > > > With the backtrace, it is also a bit unclear if it actually is failing on > > the line above or below... > > > > Cheers, > > H?kan > > > > > > > > > > > > > > > > > > > 10: crate/crate.c:1196: crate_init(MCAL) } > > > 10: ctrl/ctrl.c:1046: Control server online. > > > Message not logged - thread has no error buffer yet... > > > 10: f_user.c:559: WR ID=0x200. > > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > > 10: f_user.c:572: TPAT: No. > > > 10: f_user.c:573: Sync-check: No. > > > 10: f_user.c:575: Spill triggers: No. > > > 10: f_user.c:576: LMU: No. > > > 10: f_user.c:577: Timer latches: No. > > > 10: f_user.c:578: Spill shape: No. > > > 10: f_user.c:579: Micro-structure: No. > > > 10: f_user.c:581: Multi-event flag: No. > > > 10: f_user.c:586: UDP destination: None. > > > 1: lwroc_main.c:132: SIGSEGV received. > > > 1: -:0: Backtrace: > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > > 1: -:0: [0x100344] > > > 1: -:0: [(nil)] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > > 1: -:0: Backtrace (again, with addr2line): > > > 1: -:0: lwroc_dump_backtrace/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:9 > 51 > > > 1: -:0: lwroc_do_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 590 > > > 1: -:0: lwroc_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 692 > > > 1: -:0: lwroc_sighandler > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > > 1: -:0: ?? ??:0 > > > sh: -c: line 0: syntax error near unexpected token `(' > > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > sh: -c: line 0: syntax error near unexpected token `(' > > > sh: -c: line 0: `addr2line -i -f -C (nil) -e > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > 1: -:0: f_user_readout > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > 1: -:0: fud_read_event > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > > 1: -:0: lwroc_triva_event_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > > 1: -:0: lwroc_triva_readout > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > > 1: -:0: lwroc_main_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > > 1: -:0: main > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > > 1: -:0: ?? ??:0 > > > 1: -:0: ?? ??:0 > > > 1: -:0: Backtrace (again, addresses): > > > 1: -:0: 0x0x100ae20c: > > > 1: -:0: 0x0x100ad56c: > > > 1: -:0: 0x0x100ae518: > > > 1: -:0: 0x0x100a6374: > > > 1: -:0: 0x0x100344: > > > 1: -:0: 0x(nil): > > > 1: -:0: 0x0x100066c0: > > > 1: -:0: 0x0x10073774: > > > 1: -:0: 0x0x100a6e98: > > > 1: -:0: 0x0x100a7f38: > > > 1: -:0: 0x0x100a6890: > > > 1: -:0: 0x0x100a5dc0: > > > 1: -:0: 0x0xfb91260: > > > 1: -:0: 0x0xfb913ec: > > > 1: -:0: BUG or FATAL reported. > > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 ; > gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 25186 > > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to > abort. > > > Send slave abort readout. (1) > > > Send master abort (0x200). > > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > 1: -:0: Hardware cleanup done. > > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort test/readout: > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > ^C8: lwroc_main.c:105: SIGINT received. > > > 10: lwroc_thread_util.c:62: Set terminate first! (main) > > > ^C8: lwroc_main.c:105: SIGINT received. > > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > > Attached please find the files you asked for. > > > > > > > > > > > > Would be really great if you could figure out what is happening. > > > > > > > > > > > > > > > Best greetings from Jena > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Looks like the issue might be at: > > > > > > 1: -:0: f_user_readout > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > > > > which for me is: > > > > > > p32 = land_vme = event_buffer.ptr; > > > > > > part of a block of code: > > > > > > SUBEVENT_BEGIN(0, 0, event_buffer); > > > p32 = land_vme = event_buffer.ptr; > > > *p32++ = LAND_VME_HAS_TIME_STAMP; > > > *p32++ = tt; > > > > > > or possibly some function that it calls. > > > > > > You have the same code at that line? > > > > > > Could you also send the daq startup script and the nurdlib > > > configuration file? > > > > > > Cheers, > > > H?kan > > > > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > Dear friends, > > > > > > > > > > > > unfortunately, the DAQ crashes on startup. Here is the output: > > > > > > > > > > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > > > Message not logged - thread has no error buffer yet... > > > > CPUS: 1 > > > > delay: 1 > > > > 10: lwroc_hostname_util.c:109: Host 'lyserv' known as 192.168.1.1 (port: 56583). > > > > Message not logged - thread has no error buffer yet... > > > > HOST: RIO4-MCAL-1 > > > > Token: d6d68d7b (d6d68d7b:d6d68d7b) [/mbsusr/mbsdaq/.drasi_tokens/mcal] > > > > 10: lwroc_hostname_util.c:460: Own address: 192.168.1.71/255.255.255.0 (eth1). > > > > 10: lwroc_data_pipe.c:146: Data buffer READOUT_PIPE, fmt LMD, size 419430400 = > 0x19000000, 1 consumers. > > > > 10: lwroc_triva_readout.c:66: Silence TRIVA (HALT) > > > > 10: lwroc_net_io.c:172: Started server on port 56583 (data port 35797). > > > > client union size: 244 240 188 508 640 204 204 => 640 > > > > 10: lwroc_udp_awaken_hints.c:159: UDP awaken hints file: > /tmp/drasi.u1001/drasi.hints.u1001.RIO4-MCAL-1:56583 > > > > 10: lwroc_main.c:704: Log message rate limit in effect. > > > > 10: lwroc_readout.c:116: call readout_init... > > > > 10: lwroc_thread_util.c:118: This is the triva control thread! > > > > 10: lwroc_thread_util.c:118: This is the net io thread! > > > > 10: lwroc_thread_util.c:118: This is the slow_async thread! > > > > 10: lwroc_thread_util.c:118: This is the data server thread! > > > > 8: lwroc_message_wait.c:86: Waited 1 seconds for msg client. > > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for initial slave and EB > connection(s): > > > > 8: lwroc_triva_state.c:422: [EB lyserv] (state 0) > > > > 10: lwroc_message_internal.c:485: Message client connected! > > > > 10: lwroc_net_trans.c:1234: [drasi] Transport client connected (data) > [192.168.1.1]. > > > > 10: lwroc_triva_control.c:370: Setup TRIVA (DISBUS, HALT, MASTER, RESET) > > > > 10: lwroc_triva_control.c:418: Minimum event time > ctime(350000)+1*rd(690)+3*wr(633)+fctime(1000)=353589 ns (2.828 kHz) > > > > 10: lwroc_triva_state.c:1486: (Re)send ident messages... > > > > 10: lwroc_triva_control.c:495: START TEST ACQ: HALT, CLEAR=RESET, MT=1 > > > > 9: lwroc_triva_control.c:507: TEST: GO > > > > 10: lwroc_triva_control.c:725: RUN: RESET > > > > 10: lwroc_triva_control.c:729: RUN: MT=14 > > > > 9: lwroc_triva_control.c:737: GO (1 good test triggers done) (max 2.8 kHz) > > > > 10: lwroc_triva_readout.c:376: Trigger 14 seen. > > > > 10: config/config.c:205: Will try default cfg > path='/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default', can be set > with NURDLIB_DEF_PATH. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: config/parser.c:319: Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' { > > > > 10: config/parser.c:331: Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/global.cfg' } > > > > 10: config/parser.c:319: Opened './main.cfg' { > > > > 10: config/config.c:1388: .Global log level=verbose. > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/crate.cfg' } > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/gsi_vulom.cfg' } > > > > 10: config/parser.c:319: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' { > > > > 10: config/parser.c:331: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' } > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > > 10: config/parser.c:319: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' { > > > > 10: config/parser.c:331: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' } > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > > 10: config/parser.c:319: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' { > > > > 10: config/parser.c:331: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' } > > > > 10: config/parser.c:319: .Opened > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' { > > > > 10: config/parser.c:331: .Closed > '/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/sis_3316.cfg' } > > > > 10: config/parser.c:319: .Opened'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' { > > > > 10: config/parser.c:331: .Closed'/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/nurdlib/cfg/default/module_log_level. > cfg' } > > > > 10: config/parser.c:331: Closed './main.cfg' } > > > > 10: crate/crate.c:373: crate_create { > > > > 10: crate/crate.c:714: crate_create(MCAL) } > > > > 10: crate/crate.c:1022: crate_init(MCAL) { > > > > 10: crate/crate.c:1046: .Slow-init module[0]=GSI_VULOM. > > > > LOG: TRLO: MD5SUM: 0x1409285e (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > > > > 10: crate/crate.c:1046: .Slow-init module[1]=SIS_3316. > > > > 10: module/map/map.c:286: ...rd(0x30000000+0x64/32)=532ns > wr(0x30000000+0x64/32)=356ns. > > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800178. > > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: crate/crate.c:1046: .Slow-init module[2]=SIS_3316. > > > > 10: module/map/map.c:286: ...rd(0x31000000+0x64/32)=528ns > wr(0x31000000+0x64/32)=359ns. > > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x008001a7. > > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x33162010. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x01250011. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x01250011. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x01250011. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x01250011. > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: crate/crate.c:1046: .Slow-init module[3]=SIS_3316. > > > > 10: module/map/map.c:286: ...rd(0x32000000+0x64/32)=564ns > wr(0x32000000+0x64/32)=399ns. > > > > 10: module/sis_3316/sis_3316.c:1481: ..Serial number=0x00800171. > > > > 10: module/sis_3316/sis_3316.c:1488: ..id/firmware=0x3316200e. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[0] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[1] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[2] firmware=0x0125000c. > > > > 10: module/sis_3316/sis_3316.c:1491: ..adc[3] firmware=0x0125000c. > > > > 10: crate/crate.c:1099: .Fast-init module[0]=GSI_VULOM. > > > > 10: crate/crate.c:1099: .Fast-init module[1]=SIS_3316. > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 15 mV -> 0x080001f3 > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 13 mV -> 0x080001b0 > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 15 mV -> 0x080001f3 > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: crate/crate.c:1099: .Fast-init module[2]=SIS_3316. > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: > 1 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 10: crate/crate.c:1099: .Fast-init module[3]=SIS_3316. > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[0] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[1] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[2] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[3] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[4] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[5] = 10 mV -> 0x0800014c > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[6] = 13 mV -> 0x080001b0 > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[7] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[8] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[9] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[10] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[11] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[12] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[13] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[14] = 8 mV -> 0x0800010a > > > > 10: module/sis_3316/sis_3316.c:4380: ...threshold[15] = 8 mV -> 0x0800010a > > > > 10: crate/crate.c:1131: .Post-init module[1]=SIS_3316. > > > > 10: crate/crate.c:1131: .Post-init module[2]=SIS_3316. > > > > 10: crate/crate.c:1131: .Post-init module[3]=SIS_3316. > > > > 10: crate/crate.c:1196: crate_init(MCAL) } > > > > 10: ctrl/ctrl.c:1046: Control server online. > > > > Message not logged - thread has no error buffer yet... > > > > 10: f_user.c:559: WR ID=0x200. > > > > 10: f_user.c:565: TS offset unset. Will not modify stamp. > > > > 10: f_user.c:572: TPAT: No. > > > > 10: f_user.c:573: Sync-check: No. > > > > 10: f_user.c:575: Spill triggers: No. > > > > 10: f_user.c:576: LMU: No. > > > > 10: f_user.c:577: Timer latches: No. > > > > 10: f_user.c:578: Spill shape: No. > > > > 10: f_user.c:579: Micro-structure: No. > > > > 10: f_user.c:581: Multi-event flag: No. > > > > 10: f_user.c:586: UDP destination: None. > > > > 1: lwroc_main.c:132: SIGSEGV received. > > > > 1: -:0: Backtrace: > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae20c] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ad56c] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100ae518] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6374] > > > > 1: -:0: [0x100344] > > > > 1: -:0: [(nil)] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100066c0] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x10073774] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6e98] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a7f38] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a6890] > > > > 1: -:0: ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi [0x100a5dc0] > > > > 1: -:0: /lib/libc.so.6 [0xfb91260] > > > > 1: -:0: /lib/libc.so.6 [0xfb913ec] > > > > 1: -:0: Backtrace (again, with addr2line): > > > > 1: -:0: lwroc_dump_backtrace/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:9 > 51 > > > > 1: -:0: lwroc_do_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 590 > > > > 1: -:0: lwroc_message_internal/LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_message_internal.c:1 > 692 > > > > 1: -:0: lwroc_sighandler > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:132 > > > > 1: -:0: ?? ??:0 > > > > sh: -c: line 0: syntax error near unexpected token `(' > > > > sh: -c: line 0: `addr2line -a -f -i -C -p (nil) -e > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > > sh: -c: line 0: syntax error near unexpected token `(' > > > > sh: -c: line 0: `addr2line -i -f -C (nil) -e > ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 2> /dev/null' > > > > 1: -:0: f_user_readout > /mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/r3bfuser/f_user.c:975 > > > > 1: -:0: fud_read_event > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/f_user_daq/f_user_daq.c:607 > > > > 1: -:0: lwroc_triva_event_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:463 > > > > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in > deadtime. > > > > 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: > 2 > > > > 10: lwroc_triva_state.c:2428: [EB lyserv] EB: Status: 0x0. > > > > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > > > > 1: -:0: lwroc_triva_readout > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_triva_readout.c:818 > > > > 1: -:0: lwroc_main_loop > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_readout.c:153 > > > > 1: -:0: main > /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/drasi/lwroc/lwroc_main.c:712 > > > > 1: -:0: ?? ??:0 > > > > 1: -:0: ?? ??:0 > > > > 1: -:0: Backtrace (again, addresses): > > > > 1: -:0: 0x0x100ae20c: > > > > 1: -:0: 0x0x100ad56c: > > > > 1: -:0: 0x0x100ae518: > > > > 1: -:0: 0x0x100a6374: > > > > 1: -:0: 0x0x100344: > > > > 1: -:0: 0x(nil): > > > > 1: -:0: 0x0x100066c0: > > > > 1: -:0: 0x0x10073774: > > > > 1: -:0: 0x0x100a6e98: > > > > 1: -:0: 0x0x100a7f38: > > > > 1: -:0: 0x0x100a6890: > > > > 1: -:0: 0x0x100a5dc0: > > > > 1: -:0: 0x0xfb91260: > > > > 1: -:0: 0x0xfb913ec: > > > > 1: -:0: BUG or FATAL reported. > > > > 1: -:0: Sleeping INDEFINITELY (to allow debugger attachment). > > > > 1: -:0: Debug cmd: cd /LynxOS/mbsusr/mbsdaq/mbsrun/rio4/2024_mcalstruck/rio4-mcal-1 > ; gdb ../r3bfuser/build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi 19740 > > > > 1: -:0: Performing hardware cleanup (TRIVA HALT, RESET) in 2 s... > > > > 8: lwroc_triva_state.c:1999: Master TRIVA/MI has error (status = 0x410). > > > > 8: lwroc_triva_state.c:2708: Issue during test/run (33), tell master and slaves to > abort. > > > > Send slave abort readout. (1) > > > > Send master abort (0x200). > > > > 10: lwroc_triva_control.c:863: TRIVA control: run abort request received. > > > > 9: lwroc_triva_control.c:1032: TRIVA control: run aborted - waiting for readout... > > > > 8: lwroc_triva_state.c:414: Waited 1 seconds for master/slaves to abort > test/readout: > > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > > 1: -:0: Hardware cleanup done. > > > > 8: lwroc_triva_state.c:414: Waited 5 seconds for master/slaves to abort > test/readout: > > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > > 8: lwroc_triva_state.c:414: Waited 10 seconds for master/slaves to abort > test/readout: > > > > 8: lwroc_triva_state.c:422: [??conn (this)] (state 13) > > > > ^C8: lwroc_main.c:105: SIGINT received. > > > > 10: lwroc_thread_util.c:62: Set terminate first! (main) > > > > ^C8: lwroc_main.c:105: SIGINT received. > > > > ^C5: lwroc_main.c:109: 3rd signal SIGINT received. > > > > > > > > > > > > > > > > > > > > Looks like DRASI still has a problem ?? > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>>______________________________________________________________________________________ > _______________________________________________________________________________________ > _______________________________________________________________________________________ > ________________ > > _ > > > _ > > > > Von: subexp-daq im Auftrag von Weber, > Guenter Dr. > > > > Gesendet: Montag, 15. Juli 2024 16:02:57 > > > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > > > > > > > Dear H?kan, > > > > > > > > > > > > thank you for the reply. > > > > > > > > > > > > After implementing the suggested changes, I now get the following warning (on PC): > > > > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make fuser_drasi > > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > > For nconf results and logs, see also build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > > UDP:ARPA_INET_H > > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > > f_user.c: In function 'f_user_init': > > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > [-Wnonnull] > > > > crate_dt_release_set_func(g_crate, dt_release, NULL); > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > > > On the RIO4 there is no warning: > > > > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > > UDP:ARPA_INET_H > > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > > > In a few minutes I can tell you if the DAQ is running with the new software or not. > > > > > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > >>>______________________________________________________________________________________ > _______________________________________________________________________________________ > _______________________________________________________________________________________ > ________________ > > _ > > > _ > > > > Von: subexp-daq im Auftrag von H?kan T > Johansson > > > > Gesendet: Montag, 15. Juli 2024 15:49:23 > > > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > > > > > > > Dear G?nter, > > > > > > > > it looks like with a change of the second parameter of log_callback (both > > > > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > > > > then in compiles. > > > > > > > > Likely caused by commit '36772113' in nurdlib that changed line numbers > > > > from unsigned to int. > > > > > > > > Cheers, > > > > H?kan > > > > > > > > > > > > > > > > On Mon, 15 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > > > > Dear all, > > > > > > > > > > > > > > > I just set up a new DAQ system (new NURDLIB, TRLOII, DRASI, R3BFUSER, etc.). > > > > > > > > > > > > > > > I followed the 'cooking receipt' that I git from Hakan, as always. > > > > > > > > > > > > > > > When compiling fuser_drasi, the following happens (on PC): > > > > > > > > > > > > > > > (base) mbsdaq at atpnbg011:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ make > > > > > fuser_drasi > > > > > NCONF build_cc_x86_64-linux-gnu_7_debug/nconf.args > > > > > For nconf results and logs, see also > > > > > build_cc_x86_64-linux-gnu_7_debug/nconf*. > > > > > UDP:ARPA_INET_H > > > > > build_cc_x86_64-linux-gnu_7_debug/nconf.args done. > > > > > CC build_cc_x86_64-linux-gnu_7_debug/subevent.drasi.o > > > > > CC build_cc_x86_64-linux-gnu_7_debug/f_user.drasi.o > > > > > f_user.c: In function 'f_user_init': > > > > > f_user.c:682:26: warning: passing argument 1 of 'nurdlib_setup' from > > > > > incompatible pointer type [-Wincompatible-pointer-types] > > > > > g_crate = nurdlib_setup(log_callback, path); > > > > > ^~~~~~~~~~~~ > > > > > In file included from f_user.c:15:0: > > > > > ../nurdlib/include/nurdlib.h:28:15: note: expected 'LogCallback {aka void > > > > > (*)(const char *, int, unsigned int, const char *)}' but argument is of > > > > > type 'void (*)(const char *, unsigned int, unsigned int, const char *)' > > > > > struct Crate *nurdlib_setup(LogCallback, char const *) FUNC_RETURNS; > > > > > ^~~~~~~~~~~~~ > > > > > f_user.c:697:2: warning: null argument where non-null required (argument 3) > > > > > [-Wnonnull] > > > > > crate_dt_release_set_func(g_crate, dt_release, NULL); > > > > > ^~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > CC build_cc_x86_64-linux-gnu_7_debug/udp.drasi.o > > > > > LD build_cc_x86_64-linux-gnu_7_debug/m_read_meb.drasi > > > > > build_cc_x86_64-linux-gnu_7_debug: Simon says: Alles wird gut ;o) > > > > > > > > > > > > > > > On the RIO4 the warning is a bit less detailed: > > > > > > > > > > > > > > > RIO4-MCAL-1 mbsdaq > make fuser_drasi > > > > > NCONF build_cc_ppc-linux_4.2.2_debug/nconf.args > > > > > For nconf results and logs, see also build_cc_ppc-linux_4.2.2_debug/nconf*. > > > > > UDP:ARPA_INET_H > > > > > build_cc_ppc-linux_4.2.2_debug/nconf.args done. > > > > > CC build_cc_ppc-linux_4.2.2_debug/f_user.drasi.o > > > > > f_user.c: In function 'f_user_init': > > > > > f_user.c:682: warning: passing argument 1 of 'nurdlib_setup' from > > > > > incompatible pointer type > > > > > CC build_cc_ppc-linux_4.2.2_debug/subevent.drasi.o > > > > > CC build_cc_ppc-linux_4.2.2_debug/udp.drasi.o > > > > > LD build_cc_ppc-linux_4.2.2_debug/m_read_meb.drasi > > > > > build_cc_ppc-linux_4.2.2_debug: Simon says: Alles wird gut ;o) > > > > > > > > > > Any ideas what might have happened here? Or is this normal behaviour? > > > > > > > > > > > > > > > > > > > > Many thanks! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > > > G?nter > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Jul 18 15:47:46 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 18 Jul 2024 15:47:46 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de>, <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> Message-ID: <03efc420-d9ff-5ad3-0e5d-eebb91c36a26@chalmers.se> Dear G?nter, did I follow this thread correctly that these tests are with 'new' hardware, i.e. a setup which has no working reference software? You have / are using the SIS3316 modules in another physical setup with some fairly recent branch in the previous nurdlib repository? https://gitlab.com/chalmers-subexp/nurdlib.prelgpl21/-/network/master -- If so, there are three changes at the same time: - Nurdlib updates (also split by the repository change). - The SIS3316 code branch adapted from the previous to the new repository. - A new hardware setup. Cheers, H?kan On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > with diff = 1 the DAQ is running as long as only the VULOM4B is readout. Adding a SIS3316 > module results in an readout error of that module, followed by a reset of the DAQ. > > > Thus, I am currently unable to test SIS3316_check_hit_reworked_rebased. Sorry :-( > > > > > Best greetings > > G?nter From g.weber at hi-jena.gsi.de Thu Jul 18 16:36:54 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 18 Jul 2024 14:36:54 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <03efc420-d9ff-5ad3-0e5d-eebb91c36a26@chalmers.se> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de>, <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> , <03efc420-d9ff-5ad3-0e5d-eebb91c36a26@chalmers.se> Message-ID: <67d8ae7b46cc4150aef9b212fd757c6e@hi-jena.gsi.de> Dear H?kan, we have to DAQ systems with identical hardware. Whenever, there is a new version (TRLOII, NURDLIB, DRASI, etc.) from your side that we want to test, I am setting up one of them with the most recent software version. So, right now we have a running system that is roughly on the software status of two months ago (if I remember corretly, this was after the repository change as we first had to ask you to recreate the SIS3316 development branch) with some modifications from our side to the SIS3316 code (committed about six weeks ago). And we have the 'new' system that has identical hardware and the software status from last week. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 18. Juli 2024 15:47:46 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER Dear G?nter, did I follow this thread correctly that these tests are with 'new' hardware, i.e. a setup which has no working reference software? You have / are using the SIS3316 modules in another physical setup with some fairly recent branch in the previous nurdlib repository? https://gitlab.com/chalmers-subexp/nurdlib.prelgpl21/-/network/master -- If so, there are three changes at the same time: - Nurdlib updates (also split by the repository change). - The SIS3316 code branch adapted from the previous to the new repository. - A new hardware setup. Cheers, H?kan On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > with diff = 1 the DAQ is running as long as only the VULOM4B is readout. Adding a SIS3316 > module results in an readout error of that module, followed by a reset of the DAQ. > > > Thus, I am currently unable to test SIS3316_check_hit_reworked_rebased. Sorry :-( > > > > > Best greetings > > G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Jul 18 16:50:42 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 18 Jul 2024 16:50:42 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <67d8ae7b46cc4150aef9b212fd757c6e@hi-jena.gsi.de> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de>, <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> , <03efc420-d9ff-5ad3-0e5d-eebb91c36a26@chalmers.se> <67d8ae7b46cc4150aef9b212fd757c6e@hi-jena.gsi.de> Message-ID: On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > we have to DAQ systems with identical hardware. Whenever, there is a new version (TRLOII, > NURDLIB, DRASI, etc.) from your side that we want to test, I am setting up one of them > with the most recent software version. > > > So, right now we have a running system that is roughly on the software status of two > months ago (if I remember corretly, this was after the repository change as we first had > to ask you to recreate the SIS3316 development branch) with some modifications from our > side to the SIS3316 code (committed about six weeks ago). Just so I follow correctly: both systems are tested able to run with some (specific) software version? Could you send the git hashes of nurdlib/r3bfuser/trloii/drasi of that working combination? > And we have the 'new' system > that has identical hardware and the software status from last week.? Cheers, H?kan > > > > Best greetings > > G?nter > > > > > _________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Donnerstag, 18. Juli 2024 15:47:46 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > Dear G?nter, > > did I follow this thread correctly that these tests are with 'new' > hardware, i.e. a setup which has no working reference software? > > You have / are using the SIS3316 modules in another physical setup with > some fairly recent branch in the previous nurdlib repository? > > https://gitlab.com/chalmers-subexp/nurdlib.prelgpl21/-/network/master > > -- > > If so, there are three changes at the same time: > > - Nurdlib updates (also split by the repository change). > > - The SIS3316 code branch adapted from the previous to the new repository. > > - A new hardware setup. > > Cheers, > H?kan > > > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear H?kan, > > > > > > with diff = 1 the DAQ is running as long as only the VULOM4B is readout. Adding a > SIS3316 > > module results in an readout error of that module, followed by a reset of the DAQ. > > > > > > Thus, I am currently unable to test SIS3316_check_hit_reworked_rebased. Sorry :-( > > > > > > > > > > Best greetings > > > > G?nter > > From g.weber at hi-jena.gsi.de Thu Jul 18 17:02:39 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Thu, 18 Jul 2024 15:02:39 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de>, <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> , <03efc420-d9ff-5ad3-0e5d-eebb91c36a26@chalmers.se> <67d8ae7b46cc4150aef9b212fd757c6e@hi-jena.gsi.de>, Message-ID: Here are the hashes of the (old) software combination that runs without issues: (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/nurdlib$ git rev-parse --short HEAD c36ae0a (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/trloii$ git rev-parse --short HEAD 0020559 (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/drasi$ git rev-parse --short HEAD 1c08b62 (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ git rev-parse --short HEAD d09918b I hope this is what you were asking for. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 18. Juli 2024 16:50:42 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > Dear H?kan, > > > we have to DAQ systems with identical hardware. Whenever, there is a new version (TRLOII, > NURDLIB, DRASI, etc.) from your side that we want to test, I am setting up one of them > with the most recent software version. > > > So, right now we have a running system that is roughly on the software status of two > months ago (if I remember corretly, this was after the repository change as we first had > to ask you to recreate the SIS3316 development branch) with some modifications from our > side to the SIS3316 code (committed about six weeks ago). Just so I follow correctly: both systems are tested able to run with some (specific) software version? Could you send the git hashes of nurdlib/r3bfuser/trloii/drasi of that working combination? > And we have the 'new' system > that has identical hardware and the software status from last week. Cheers, H?kan > > > > Best greetings > > G?nter > > > > > _________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Donnerstag, 18. Juli 2024 15:47:46 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > Dear G?nter, > > did I follow this thread correctly that these tests are with 'new' > hardware, i.e. a setup which has no working reference software? > > You have / are using the SIS3316 modules in another physical setup with > some fairly recent branch in the previous nurdlib repository? > > https://gitlab.com/chalmers-subexp/nurdlib.prelgpl21/-/network/master > > -- > > If so, there are three changes at the same time: > > - Nurdlib updates (also split by the repository change). > > - The SIS3316 code branch adapted from the previous to the new repository. > > - A new hardware setup. > > Cheers, > H?kan > > > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear H?kan, > > > > > > with diff = 1 the DAQ is running as long as only the VULOM4B is readout. Adding a > SIS3316 > > module results in an readout error of that module, followed by a reset of the DAQ. > > > > > > Thus, I am currently unable to test SIS3316_check_hit_reworked_rebased. Sorry :-( > > > > > > > > > > Best greetings > > > > G?nter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Thu Jul 18 17:39:43 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Thu, 18 Jul 2024 17:39:43 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de>, <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> , <03efc420-d9ff-5ad3-0e5d-eebb91c36a26@chalmers.se> <67d8ae7b46cc4150aef9b212fd757c6e@hi-jena.gsi.de>, Message-ID: <38a24224-cff9-f04c-6888-ca3df06c6eda@chalmers.se> Dear G?nter, thanks! Yes, what I was looking for. r3bfuser - same as new version (so should not be at fault ;) ) Good news (to me) is that the nurdlib is in the same repo. There are changes in sis3316-code in nurdlib between the working c36ae0a and non-working ccac28b which are beyond my understanding. Unless urgent for you, I would suggest that we wait with that until Hans is back from vacation. ;) Meanwhile, if you like, you could of course start out at the working version combination, and update drasi and trloii to current version. One at a time. The interfaces between those and also those and nurdlib are small and should not have seen changes lately, so I would expect any such combinations to compile. Cheers, H?kan On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > Here are the hashes of the (old) software combination that runs without issues: > > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/nurdlib$ git rev-parse --short HEAD > c36ae0a > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/trloii$ git rev-parse --short HEAD > 0020559 > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/drasi$ git rev-parse --short HEAD > 1c08b62 > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ git rev-parse --short HEAD > d09918b > > I hope this is what you were asking for. > > > > Best greetings > G?nter > > _______________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Donnerstag, 18. Juli 2024 16:50:42 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear H?kan, > > > > > > we have to DAQ systems with identical hardware. Whenever, there is a new version (TRLOII, > > NURDLIB, DRASI, etc.) from your side that we want to test, I am setting up one of them > > with the most recent software version. > > > > > > So, right now we have a running system that is roughly on the software status of two > > months ago (if I remember corretly, this was after the repository change as we first had > > to ask you to recreate the SIS3316 development branch) with some modifications from our > > side to the SIS3316 code (committed about six weeks ago). > > Just so I follow correctly: both systems are tested able to run with some > (specific) software version? > > Could you send the git hashes of nurdlib/r3bfuser/trloii/drasi of that > working combination? > > > And we have the 'new' system > > that has identical hardware and the software status from last week.? > > > Cheers, > H?kan > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > _________________________________________________________________________________________ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > Gesendet: Donnerstag, 18. Juli 2024 15:47:46 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > > > Dear G?nter, > > > > did I follow this thread correctly that these tests are with 'new' > > hardware, i.e. a setup which has no working reference software? > > > > You have / are using the SIS3316 modules in another physical setup with > > some fairly recent branch in the previous nurdlib repository? > > > > https://gitlab.com/chalmers-subexp/nurdlib.prelgpl21/-/network/master > > > > -- > > > > If so, there are three changes at the same time: > > > > - Nurdlib updates (also split by the repository change). > > > > - The SIS3316 code branch adapted from the previous to the new repository. > > > > - A new hardware setup. > > > > Cheers, > > H?kan > > > > > > > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear H?kan, > > > > > > > > > with diff = 1 the DAQ is running as long as only the VULOM4B is readout. Adding a > > SIS3316 > > > module results in an readout error of that module, followed by a reset of the DAQ. > > > > > > > > > Thus, I am currently unable to test SIS3316_check_hit_reworked_rebased. Sorry :-( > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > From g.weber at hi-jena.gsi.de Fri Jul 19 11:44:11 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Fri, 19 Jul 2024 09:44:11 +0000 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: <38a24224-cff9-f04c-6888-ca3df06c6eda@chalmers.se> References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de>, <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> , <03efc420-d9ff-5ad3-0e5d-eebb91c36a26@chalmers.se> <67d8ae7b46cc4150aef9b212fd757c6e@hi-jena.gsi.de>, , <38a24224-cff9-f04c-6888-ca3df06c6eda@chalmers.se> Message-ID: Dear H?kan, I now started with the software package from ~two months ago and step-by-step replaced it with the most recent versions. Everything is fine until I add the new version of NURDLIB (using the SIS3316_check_hit_reworked_rebased branch). Then I get in R3BFUSER the compile error. Implementing the first fixes suggested by you elimates this error on the RIO4: it looks like with a change of the second parameter of log_callback (both in prototype an definition) of r3bfuser/f_user.c from unsigned to int, But on startup of the DAQ I get a crash. Then we have the second fix: Anyhow, I suspect that if you change in include/nurdlib/crate.h in the prototype of crate_dt_release_set_func to have FUNC_NONNULL((1,2)) instead of FUNC_NONNULL(()) then it might work. This still results in a crash of DAQ, as g_counter_ms in f_user.c is zero at line 981. The immediate crash of DAQ on startup is avoided by a workaround: /* diff = crate_counter_get_diff(g_counter_ms); */ diff = 1; And, (!) contrary to what I thought to having found yesterday (!), with this modifications the DAQ is now running as expected also with a SIS3316 module being enabled. Thus, it looks like that all problems seem to originate from a change in NURDLIB. I hope this helps with fixing the underlying issues. Best greetings G?nter ________________________________ Von: subexp-daq im Auftrag von H?kan T Johansson Gesendet: Donnerstag, 18. Juli 2024 17:39:43 An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER Dear G?nter, thanks! Yes, what I was looking for. r3bfuser - same as new version (so should not be at fault ;) ) Good news (to me) is that the nurdlib is in the same repo. There are changes in sis3316-code in nurdlib between the working c36ae0a and non-working ccac28b which are beyond my understanding. Unless urgent for you, I would suggest that we wait with that until Hans is back from vacation. ;) Meanwhile, if you like, you could of course start out at the working version combination, and update drasi and trloii to current version. One at a time. The interfaces between those and also those and nurdlib are small and should not have seen changes lately, so I would expect any such combinations to compile. Cheers, H?kan On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > Here are the hashes of the (old) software combination that runs without issues: > > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/nurdlib$ git rev-parse --short HEAD > c36ae0a > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/trloii$ git rev-parse --short HEAD > 0020559 > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/drasi$ git rev-parse --short HEAD > 1c08b62 > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ git rev-parse --short HEAD > d09918b > > I hope this is what you were asking for. > > > > Best greetings > G?nter > > _______________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Donnerstag, 18. Juli 2024 16:50:42 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Dear H?kan, > > > > > > we have to DAQ systems with identical hardware. Whenever, there is a new version (TRLOII, > > NURDLIB, DRASI, etc.) from your side that we want to test, I am setting up one of them > > with the most recent software version. > > > > > > So, right now we have a running system that is roughly on the software status of two > > months ago (if I remember corretly, this was after the repository change as we first had > > to ask you to recreate the SIS3316 development branch) with some modifications from our > > side to the SIS3316 code (committed about six weeks ago). > > Just so I follow correctly: both systems are tested able to run with some > (specific) software version? > > Could you send the git hashes of nurdlib/r3bfuser/trloii/drasi of that > working combination? > > > And we have the 'new' system > > that has identical hardware and the software status from last week. > > > Cheers, > H?kan > > > > > > > > > > > Best greetings > > > > G?nter > > > > > > > > > > _________________________________________________________________________________________ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > Gesendet: Donnerstag, 18. Juli 2024 15:47:46 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER > > > > Dear G?nter, > > > > did I follow this thread correctly that these tests are with 'new' > > hardware, i.e. a setup which has no working reference software? > > > > You have / are using the SIS3316 modules in another physical setup with > > some fairly recent branch in the previous nurdlib repository? > > > > https://gitlab.com/chalmers-subexp/nurdlib.prelgpl21/-/network/master > > > > -- > > > > If so, there are three changes at the same time: > > > > - Nurdlib updates (also split by the repository change). > > > > - The SIS3316 code branch adapted from the previous to the new repository. > > > > - A new hardware setup. > > > > Cheers, > > H?kan > > > > > > > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear H?kan, > > > > > > > > > with diff = 1 the DAQ is running as long as only the VULOM4B is readout. Adding a > > SIS3316 > > > module results in an readout error of that module, followed by a reset of the DAQ. > > > > > > > > > Thus, I am currently unable to test SIS3316_check_hit_reworked_rebased. Sorry :-( > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Fri Jul 19 12:22:20 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Fri, 19 Jul 2024 12:22:20 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: References: , <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se>, <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de>, <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de>, <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de>, <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de>, <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> , <03efc420-d9ff-5ad3-0e5d-eebb91c36a26@chalmers.se> <67d8ae7b46cc4150aef9b212fd757c6e@hi-jena.gsi.de>, , <38a24224-cff9-f04c-6888-ca3df06c6eda@chalmers.se> Message-ID: Dear G?nter, that sounds great! Let's check that I got it right: - You are now running with up-to-date (master/main): drasi, trloii, r3bfuser and nurdlib is at the 'newest' SIS3316_check_hit_reworked_rebased (ccac28b) With the following fixes, it runs: - r3bfuser: log_callback - second argument (line number) not 'int' (I've sent a merge request) - nurdlib: FUNC_NONNULL((1,2)) (I've sent a merge request) - r3bfuser: changed: ? ? ? /* diff = crate_counter_get_diff(g_counter_ms); */ diff = 1; This will need some deeper thought to figure what really should be fixed though. Cheers, H?kan On Fri, 19 Jul 2024, Weber, Guenter Dr. wrote: > Dear H?kan, > > > I now started with the software package from ~two months ago and step-by-step replaced it with the most recent versions. Everything is > fine until I add the new version of NURDLIB (using the SIS3316_check_hit_reworked_rebased branch). Then I get in R3BFUSER the compile > error. > > > Implementing the first fixes suggested by you elimates this error on the RIO4: > > > it looks like with a change of the second parameter of log_callback (both > in prototype an definition) of r3bfuser/f_user.c from unsigned to int, > > > But on startup of the DAQ I get a crash. Then we have the second fix: > > > Anyhow, I suspect that if you change in > include/nurdlib/crate.h > in the prototype of crate_dt_release_set_func to have > FUNC_NONNULL((1,2))? instead of? FUNC_NONNULL(()) > then it might work. > > This still results in a crash of DAQ, as g_counter_ms in f_user.c is zero at line 981. The immediate crash of DAQ on startup is avoided > by a workaround: > > > ? ? ? ? /* diff = crate_counter_get_diff(g_counter_ms); */ > ? ? ? ? diff = 1; > > And, (!) contrary to what I thought to having found yesterday (!), with this modifications the DAQ is now running as expected also with > a SIS3316 module being enabled. > > > > > Thus, it looks like that all problems seem to originate from a change in NURDLIB. > > > > I hope this helps with fixing the underlying issues. > > > > > Best greetings > > G?nter > > > > _______________________________________________________________________________________________________________________________________ > Von: subexp-daq im Auftrag von H?kan T Johansson > Gesendet: Donnerstag, 18. Juli 2024 17:39:43 > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > Dear G?nter, > > thanks!? Yes, what I was looking for. > > r3bfuser - same as new version? (so should not be at fault ;) ) > > Good news (to me) is that the nurdlib is in the same repo. > > There are changes in sis3316-code in nurdlib between the working c36ae0a > and non-working ccac28b which are beyond my understanding.? Unless urgent > for you, I would suggest that we wait with that until Hans is back from > vacation.? ;) > > Meanwhile, if you like, you could of course start out at the working > version combination, and update drasi and trloii to current version.? One > at a time.? The interfaces between those and also those and nurdlib are > small and should not have seen changes lately, so I would expect any such > combinations to compile. > > Cheers, > H?kan > > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > > > > Here are the hashes of the (old) software combination that runs without issues: > > > > > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/nurdlib$ git rev-parse --short HEAD > > c36ae0a > > > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/trloii$ git rev-parse --short HEAD > > 0020559 > > > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/drasi$ git rev-parse --short HEAD > > 1c08b62 > > > > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ git rev-parse --short HEAD > > d09918b > > > > I hope this is what you were asking for. > > > > > > > > Best greetings > > G?nter > > > >______________________________________________________________________________________________________________________________________ > _ > > Von: subexp-daq im Auftrag von H?kan T Johansson > > Gesendet: Donnerstag, 18. Juli 2024 16:50:42 > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > Dear H?kan, > > > > > > > > > we have to DAQ systems with identical hardware. Whenever, there is a new version (TRLOII, > > > NURDLIB, DRASI, etc.) from your side that we want to test, I am setting up one of them > > > with the most recent software version. > > > > > > > > > So, right now we have a running system that is roughly on the software status of two > > > months ago (if I remember corretly, this was after the repository change as we first had > > > to ask you to recreate the SIS3316 development branch) with some modifications from our > > > side to the SIS3316 code (committed about six weeks ago). > > > > Just so I follow correctly: both systems are tested able to run with some > > (specific) software version? > > > > Could you send the git hashes of nurdlib/r3bfuser/trloii/drasi of that > > working combination? > > > > > And we have the 'new' system > > > that has identical hardware and the software status from last week.? > > > > > > Cheers, > > H?kan > > > > > > > > > > > > > > > > > > Best greetings > > > > > > G?nter > > > > > > > > > > > > > > > _________________________________________________________________________________________ > > > Von: subexp-daq im Auftrag von H?kan T Johansson > > > > > > Gesendet: Donnerstag, 18. Juli 2024 15:47:46 > > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. > > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER ? > > > > > > Dear G?nter, > > > > > > did I follow this thread correctly that these tests are with 'new' > > > hardware, i.e. a setup which has no working reference software? > > > > > > You have / are using the SIS3316 modules in another physical setup with > > > some fairly recent branch in the previous nurdlib repository? > > > > > > https://gitlab.com/chalmers-subexp/nurdlib.prelgpl21/-/network/master > > > > > > -- > > > > > > If so, there are three changes at the same time: > > > > > > - Nurdlib updates (also split by the repository change). > > > > > > - The SIS3316 code branch adapted from the previous to the new repository. > > > > > > - A new hardware setup. > > > > > > Cheers, > > > H?kan > > > > > > > > > > > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: > > > > > > > > > > > Dear H?kan, > > > > > > > > > > > > with diff = 1 the DAQ is running as long as only the VULOM4B is readout. Adding a > > > SIS3316 > > > > module results in an readout error of that module, followed by a reset of the DAQ. > > > > > > > > > > > > Thus, I am currently unable to test SIS3316_check_hit_reworked_rebased. Sorry :-( > > > > > > > > > > > > > > > > > > > > Best greetings > > > > > > > > G?nter > > > > > > > > > > > > From g.weber at hi-jena.gsi.de Mon Jul 22 15:35:57 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Mon, 22 Jul 2024 13:35:57 +0000 Subject: [subexp-daq] Question on DRASI Message-ID: <0798923247f6411cb82d952e37b592c3@hi-jena.gsi.de> Dear friends, we are currently in a situation where we would like to use the SIS3316 modules like a scope, i. e. once a trigger happens we would like the data out of the DAQ immediately. Would it be possible to modify DRASI in a way that it flushes out the data after each trigger? (Or, maybe easier, to set the minimum flush rate to something like 10 Hz?) Thank you very much! Best greetings G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Wed Jul 24 09:24:51 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Wed, 24 Jul 2024 09:24:51 +0200 Subject: [subexp-daq] Question on DRASI - faster flushing In-Reply-To: <0798923247f6411cb82d952e37b592c3@hi-jena.gsi.de> References: <0798923247f6411cb82d952e37b592c3@hi-jena.gsi.de> Message-ID: <63b559cd-e6c2-1b5c-0089-43cbe364827a@chalmers.se> Dear G?nter, I think I have a dirty fix for this. In drasi and ucesb, use the branch 'quickflush'. -- Please test on some PC not running a DAQ or data transport: Make sure the 'tmux' program is installed. Make three terminals. The first needs to be wide and tall: # First: this sets up a simulated DAQ with 30 Hz triggers. # This runs inside tmux. To exit, press 'C-b d'. cd drasi/ make empty -j 32 scripts/runsim.sh --trigrate=30 --slaves=0 --timesort --trans # Second: takes data from the end of the simulated DAQ chain, and sends # using ext_data interface. cd ucesb/ make empty -j 32 empty/empty --trans=localhost --ntuple=SERVER,dummy # Third: read data using ext_data interface: cd ucesb/ ext_test/ext_reader_h101 localhost # The third should now show a more or less continous stream of updates: # (not be 'chunked') 2880 (d 1): 2 2881 (d 1): 2 2882 (d 1): 2 # The simulated DAQ can be killed with: cd drasi/ scripts/runsim.sh --kill -- To implement this more permanently, I would need to understand again how they pace the data flow... In order to not build more unnecessary options on top of old. Cheers, H?kan On Mon, 22 Jul 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > we are currently in a situation where we would like to use the SIS3316 > modules like a scope, i. e. once a trigger happens we would like the data > out of the DAQ immediately. Would it be possible to modify DRASI in a way > that it flushes out the data after each trigger? (Or, maybe easier, to set > the minimum flush rate to something like 10 Hz?) > > > Thank you very much! > > > > > Best greetings > > G?nter > > > > > From hans.tornqvist at chalmers.se Mon Jul 29 12:36:59 2024 From: hans.tornqvist at chalmers.se (=?UTF-8?Q?Hans_Toshihide_T=C3=B6rnqvist?=) Date: Mon, 29 Jul 2024 12:36:59 +0200 Subject: [subexp-daq] New warning meassage in R3BFUSER In-Reply-To: References: <44dde5be-452f-536c-8ecd-1c131ea928b2@chalmers.se> <52660438655e43db9fbc7114f2c765be@hi-jena.gsi.de> <03b56336-362c-1058-b303-d8109ab0ded0@chalmers.se> <68df3d327d2c427ebdd2ee010719ffe2@hi-jena.gsi.de> <6131887f-9f20-cc67-8334-6de1981b026e@chalmers.se> <02cbf1fe77c24bbcaa95e261efacdbff@hi-jena.gsi.de> <0e5b59c4-3e61-ab58-7870-89d98058400c@chalmers.se> <2be46daaeba0453bb7f0a3380757a68b@hi-jena.gsi.de> <87c210f6-8132-6c33-85b5-ba86c2ef2e0f@chalmers.se> <03efc420-d9ff-5ad3-0e5d-eebb91c36a26@chalmers.se> <67d8ae7b46cc4150aef9b212fd757c6e@hi-jena.gsi.de> <38a24224-cff9-f04c-6888-ca3df06c6eda@chalmers.se> Message-ID: <8c261f0f-7c41-4bd6-9437-d389f319077e@chalmers.se> Dear all, Looks like I went on vacation just before these troubles... I have not been able to give these codes the time they require to be in good shape, apologies. The proposed solutions were fine and are online now. Best regards, Hans On 2024-07-19 12:22, H?kan T Johansson wrote: > > Dear G?nter, > > that sounds great!? Let's check that I got it right: > > - You are now running with up-to-date (master/main): > > ? drasi, > ? trloii, > ? r3bfuser and > > ? nurdlib is at the 'newest' SIS3316_check_hit_reworked_rebased (ccac28b) > > With the following fixes, it runs: > > - r3bfuser: log_callback - second argument (line number) not 'int' > ? (I've sent a merge request) > > - nurdlib: FUNC_NONNULL((1,2)) > ? (I've sent a merge request) > > - r3bfuser: changed: > > ? ? ? ? /* diff = crate_counter_get_diff(g_counter_ms); */ > ??????? diff = 1; > > ? This will need some deeper thought to figure what really should be fixed > ? though. > > Cheers, > H?kan > > > > > On Fri, 19 Jul 2024, Weber, Guenter Dr. wrote: > >> Dear H?kan, >> >> >> I now started with the software package from ~two months ago and >> step-by-step replaced it with the most recent versions. Everything is >> fine until I add the new version of NURDLIB (using the >> SIS3316_check_hit_reworked_rebased branch). Then I get in R3BFUSER the >> compile >> error. >> >> >> Implementing the first fixes suggested by you elimates this error on >> the RIO4: >> >> >> it looks like with a change of the second parameter of log_callback (both >> in prototype an definition) of r3bfuser/f_user.c from unsigned to int, >> >> >> But on startup of the DAQ I get a crash. Then we have the second fix: >> >> >> Anyhow, I suspect that if you change in >> include/nurdlib/crate.h >> in the prototype of crate_dt_release_set_func to have >> FUNC_NONNULL((1,2))? instead of? FUNC_NONNULL(()) >> then it might work. >> >> This still results in a crash of DAQ, as g_counter_ms in f_user.c is >> zero at line 981. The immediate crash of DAQ on startup is avoided >> by a workaround: >> >> >> ? ? ? ? /* diff = crate_counter_get_diff(g_counter_ms); */ >> ? ? ? ? diff = 1; >> >> And, (!) contrary to what I thought to having found yesterday (!), >> with this modifications the DAQ is now running as expected also with >> a SIS3316 module being enabled. >> >> >> >> >> Thus, it looks like that all problems seem to originate from a change >> in NURDLIB. >> >> >> >> I hope this helps with fixing the underlying issues. >> >> >> >> >> Best greetings >> >> G?nter >> >> >> >> _______________________________________________________________________________________________________________________________________ >> Von: subexp-daq im Auftrag von >> H?kan T Johansson >> Gesendet: Donnerstag, 18. Juli 2024 17:39:43 >> An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER >> >> Dear G?nter, >> >> thanks!? Yes, what I was looking for. >> >> r3bfuser - same as new version? (so should not be at fault ;) ) >> >> Good news (to me) is that the nurdlib is in the same repo. >> >> There are changes in sis3316-code in nurdlib between the working c36ae0a >> and non-working ccac28b which are beyond my understanding.? Unless urgent >> for you, I would suggest that we wait with that until Hans is back from >> vacation.? ;) >> >> Meanwhile, if you like, you could of course start out at the working >> version combination, and update drasi and trloii to current version.? One >> at a time.? The interfaces between those and also those and nurdlib are >> small and should not have seen changes lately, so I would expect any such >> combinations to compile. >> >> Cheers, >> H?kan >> >> >> On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: >> >> > >> > Here are the hashes of the (old) software combination that runs >> without issues: >> > >> > >> > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/nurdlib$ git >> rev-parse --short HEAD >> > c36ae0a >> > >> > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/trloii$ git >> rev-parse --short HEAD >> > 0020559 >> > >> > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/drasi$ git >> rev-parse --short HEAD >> > 1c08b62 >> > >> > (base) mbsdaq at atpnbg012:~/mbsrun/rio4/2024_mcalstruck/r3bfuser$ git >> rev-parse --short HEAD >> > d09918b >> > >> > I hope this is what you were asking for. >> > >> > >> > >> > Best greetings >> > G?nter >> > >> >______________________________________________________________________________________________________________________________________ >> _ >> > Von: subexp-daq im Auftrag >> von H?kan T Johansson >> > Gesendet: Donnerstag, 18. Juli 2024 16:50:42 >> > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER >> > >> > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: >> > >> > > >> > > Dear H?kan, >> > > >> > > >> > > we have to DAQ systems with identical hardware. Whenever, there is >> a new version (TRLOII, >> > > NURDLIB, DRASI, etc.) from your side that we want to test, I am >> setting up one of them >> > > with the most recent software version. >> > > >> > > >> > > So, right now we have a running system that is roughly on the >> software status of two >> > > months ago (if I remember corretly, this was after the repository >> change as we first had >> > > to ask you to recreate the SIS3316 development branch) with some >> modifications from our >> > > side to the SIS3316 code (committed about six weeks ago). >> > >> > Just so I follow correctly: both systems are tested able to run with >> some >> > (specific) software version? >> > >> > Could you send the git hashes of nurdlib/r3bfuser/trloii/drasi of that >> > working combination? >> > >> > > And we have the 'new' system >> > > that has identical hardware and the software status from last week. >> > >> > >> > Cheers, >> > H?kan >> > >> > >> > >> > > >> > > >> > > >> > > Best greetings >> > > >> > > G?nter >> > > >> > > >> > > >> > > >> > > >> _________________________________________________________________________________________ >> > > Von: subexp-daq im Auftrag >> von H?kan T Johansson >> > > >> > > Gesendet: Donnerstag, 18. Juli 2024 15:47:46 >> > > An: Discuss use of Nurdlib, TRLO II, drasi and UCESB. >> > > Betreff: Re: [subexp-daq] New warning meassage in R3BFUSER >> > > >> > > Dear G?nter, >> > > >> > > did I follow this thread correctly that these tests are with 'new' >> > > hardware, i.e. a setup which has no working reference software? >> > > >> > > You have / are using the SIS3316 modules in another physical setup >> with >> > > some fairly recent branch in the previous nurdlib repository? >> > > >> > > https://gitlab.com/chalmers-subexp/nurdlib.prelgpl21/-/network/master >> > > >> > > -- >> > > >> > > If so, there are three changes at the same time: >> > > >> > > - Nurdlib updates (also split by the repository change). >> > > >> > > - The SIS3316 code branch adapted from the previous to the new >> repository. >> > > >> > > - A new hardware setup. >> > > >> > > Cheers, >> > > H?kan >> > > >> > > >> > > >> > > On Thu, 18 Jul 2024, Weber, Guenter Dr. wrote: >> > > >> > > > >> > > > Dear H?kan, >> > > > >> > > > >> > > > with diff = 1 the DAQ is running as long as only the VULOM4B is >> readout. Adding a >> > > SIS3316 >> > > > module results in an readout error of that module, followed by a >> reset of the DAQ. >> > > > >> > > > >> > > > Thus, I am currently unable to test >> SIS3316_check_hit_reworked_rebased. Sorry :-( >> > > > >> > > > >> > > > >> > > > >> > > > Best greetings >> > > > >> > > > G?nter >> > > >> > > >> > >> > >> >> > From g.weber at hi-jena.gsi.de Tue Jul 30 16:03:51 2024 From: g.weber at hi-jena.gsi.de (Weber, Guenter Dr.) Date: Tue, 30 Jul 2024 14:03:51 +0000 Subject: [subexp-daq] Question on DRASI and multiple triggers Message-ID: <63a88b058447459c90861676a61a57c6@hi-jena.gsi.de> Dear friends, this night we had the following error in one of our DAQ systems: 5: module/caen_v1n90/caen_v1n90.c:811: FIFO stored=2, but event_diff=1. 5: crate/crate.c:2067: POLARIMETER[3]=CAEN_V1190 readout error=0x00000010, dumping data: 10: crate/crate.c:2083: ---[ Dump begin ]--- 10: crate/crate.c:2083: Start=0x33ede828 Bytes=104=0x68 10: crate/crate.c:2083: 0: 423cc123 08609e20 00484e77 008020c2 00c84626 18609005 09609e20 19609002 10: crate/crate.c:2083: 20: 0a609e20 1a609002 0b609e20 1b609002 800001a3 423cc143 0860ae23 00484b77 10: crate/crate.c:2083: 40: 00801dc2 00c84326 1860a005 0960ae23 1960a002 0a60ae23 1a60a002 0b60ae23 10: crate/crate.c:2083: 60: 1b60a002 800001a3 10: crate/crate.c:2083: ---[ Dump end ]--- 5: crate/crate.c:1554: POLARIMETER: readout failed! 5: crate/crate.c:1598: POLARIMETER: had problems, re-initializing. 10: crate/crate.c:688: crate_deinit(POLARIMETER) { 10: crate/crate.c:712: crate_deinit(POLARIMETER) } 10: crate/crate.c:986: crate_init(POLARIMETER) { 10: crate/crate.c:1010: .Slow-init module[0]=GSI_VULOM. LOG: TRLO: MD5SUM: 0x6e4ba1a9 (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) 10: crate/crate.c:1010: .Slow-init module[1]=CAEN_V785. 10: module/map/map.c:263: ....rd(0x44440000+0x103c/16)=598ns wr(0x44440000+0x103c/16)=433ns. 10: crate/crate.c:1010: .Slow-init module[2]=CAEN_V785. 10: module/map/map.c:263: ....rd(0x11110000+0x103c/16)=630ns wr(0x11110000+0x103c/16)=470ns. 10: crate/crate.c:1010: .Slow-init module[3]=CAEN_V1190. 10: module/map/map.c:263: ...rd(0x22220000+0x1028/32)=635ns wr(0x22220000+0x1028/32)=458ns. 10: crate/crate.c:1063: .Fast-init module[0]=GSI_VULOM. 10: crate/crate.c:1063: .Fast-init module[1]=CAEN_V785. 10: crate/crate.c:1063: .Fast-init module[2]=CAEN_V785. 10: crate/crate.c:1063: .Fast-init module[3]=CAEN_V1190. 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 51504652 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 51504652 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 51504652 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. 8: lwroc_triva_state.c:2399: Master: deadtime: 1. Status: 0x10 (IN_READOUT). EC: 51504652 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0. 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... 10: crate/crate.c:1160: crate_init(POLARIMETER) } 5: f_user.c:1257: had readout error, ret=0x10, trigger=1, prev=1 After this error the DAQ recovered and just continued. The obtained data (so far) looks fine. To my understanding, the only possibility to get two events in the FIFO of the TDC module is that the TDC module receives a second trigger before it is cleared. However, in our setup the TDC is triggered by a signal generated by the VULOM upon acceptance of a DAQ readout trigger. And after each readout the TDC should get cleared. Thus, two consecutive triggers of the TDC module before it is readout an cleared should never happen. And, indeed it almost doesn't happen. But once in a while (after millions and millions of events), it does happen. Do you guys know a scenario where the observed behaviour is to be expected? And it it possible that this is connected somehow to the DRASI settings of the conversion time or something else? Thanks a lot! Best greetings from Jena G?nter -------------- next part -------------- An HTML attachment was scrubbed... URL: From f96hajo at chalmers.se Tue Jul 30 16:37:01 2024 From: f96hajo at chalmers.se (=?ISO-8859-15?Q?H=E5kan_T_Johansson?=) Date: Tue, 30 Jul 2024 16:37:01 +0200 Subject: [subexp-daq] Question on DRASI and multiple triggers In-Reply-To: <63a88b058447459c90861676a61a57c6@hi-jena.gsi.de> References: <63a88b058447459c90861676a61a57c6@hi-jena.gsi.de> Message-ID: <8931d211-7acf-c48f-8769-9617d092a9b9@chalmers.se> Dear G?nter, That is indeed not wanted or expected. I think the fast clear time or conversion time should not be the culprits here. The start of the deadtime signal issued by the TRIVA should not depend on their length, but come rather soon after the trigger signals reach it. With your setting of 'accept_window_len = 100 ns;' that ought to be well before the 'fast_busy_len = 1000ns;' goes away. The data dump looks like two events, which are almost even identical? I do not know what the V1190 does if it gets a double-signal (i.e. close-by, say order of 100 ns). Does it then duplicate the actual hits into two events perhaps, with some time difference, corresponding to the difference in time between those two signals? To make debugging easier, perhaps it is possible to provoke the behaviour with a high-rate, preferably random, trigger? E.g. something like dest <= PRNG_POISSON(1); PRNG_POISSON(1).period = 100 k/s; Cheers, H?kan On Tue, 30 Jul 2024, Weber, Guenter Dr. wrote: > > Dear friends, > > > this night we had the following error in one of our DAQ systems: > > > 5: module/caen_v1n90/caen_v1n90.c:811: FIFO stored=2, but event_diff=1. > 5: crate/crate.c:2067: POLARIMETER[3]=CAEN_V1190 readout error=0x00000010, dumping data: > 10: crate/crate.c:2083: ---[ Dump begin ]--- > 10: crate/crate.c:2083: Start=0x33ede828? Bytes=104=0x68 > 10: crate/crate.c:2083:???? 0: 423cc123 08609e20 00484e77 008020c2 00c84626 18609005 09609e20 19609002 > 10: crate/crate.c:2083:??? 20: 0a609e20 1a609002 0b609e20 1b609002 800001a3 423cc143 0860ae23 00484b77 > 10: crate/crate.c:2083:??? 40: 00801dc2 00c84326 1860a005 0960ae23 1960a002 0a60ae23 1a60a002 0b60ae23 > 10: crate/crate.c:2083:??? 60: 1b60a002 800001a3 > 10: crate/crate.c:2083: ---[? Dump end? ]--- > 5: crate/crate.c:1554: POLARIMETER: readout failed! > 5: crate/crate.c:1598: POLARIMETER: had problems, re-initializing. > 10: crate/crate.c:688: crate_deinit(POLARIMETER) { > 10: crate/crate.c:712: crate_deinit(POLARIMETER) } > 10: crate/crate.c:986: crate_init(POLARIMETER) { > 10: crate/crate.c:1010: .Slow-init module[0]=GSI_VULOM. > LOG: TRLO: MD5SUM: 0x6e4ba1a9 (CT: 63bb1d44 = 2023-01-08 19:45:08 UTC) > 10: crate/crate.c:1010: .Slow-init module[1]=CAEN_V785. > 10: module/map/map.c:263: ....rd(0x44440000+0x103c/16)=598ns wr(0x44440000+0x103c/16)=433ns. > 10: crate/crate.c:1010: .Slow-init module[2]=CAEN_V785. > 10: module/map/map.c:263: ....rd(0x11110000+0x103c/16)=630ns wr(0x11110000+0x103c/16)=470ns. > 10: crate/crate.c:1010: .Slow-init module[3]=CAEN_V1190. > 10: module/map/map.c:263: ...rd(0x22220000+0x1028/32)=635ns wr(0x22220000+0x1028/32)=458ns. > 10: crate/crate.c:1063: .Fast-init module[0]=GSI_VULOM. > 10: crate/crate.c:1063: .Fast-init module[1]=CAEN_V785. > 10: crate/crate.c:1063: .Fast-init module[2]=CAEN_V785. > 10: crate/crate.c:1063: .Fast-init module[3]=CAEN_V1190. > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 51504652 > 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 51504652 > 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 51504652 > 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 8: lwroc_triva_state.c:2028: Master TRIVA/MI no progress last second, and in deadtime. > 8: lwroc_triva_state.c:2399: Master: deadtime: 1.? Status: 0x10 (IN_READOUT).? EC: 51504652 > 10: lwroc_triva_state.c:2428: [EB lyserv:7000] EB: Status: 0x0. > 8: lwroc_triva_state.c:2488: Node(s) busy in readout, waiting... > 10: crate/crate.c:1160: crate_init(POLARIMETER) } > 5: f_user.c:1257: had readout error, ret=0x10, trigger=1, prev=1 > > After this error the DAQ recovered and just continued. The obtained data (so far) looks fine. > > > To my understanding, the only possibility to get two events in the FIFO of the TDC module is that the TDC module receives a second trigger before it is > cleared. However, in our setup the TDC is triggered by a signal generated by the VULOM upon acceptance of a DAQ readout trigger. And after each readout > the TDC should get cleared. Thus, two consecutive triggers of the TDC module before it is readout an cleared should never happen. And, indeed it almost > doesn't happen. But once in a while (after millions and millions of events), it does happen. > > > Do you guys know a scenario where the observed behaviour is to be expected? And it it possible that this is connected somehow to the DRASI settings of the > conversion time or something else? > > > > > Thanks a lot! > > > > > > Best greetings from Jena > > G?nter > > > > > > > >