ID |
Date |
Author |
Topic |
Subject |
2640
|
02 Dec 2023 |
Pavel Murat | Forum | run number from an external (*SQL) db? | >
> If you go in this direction, there is an alternative to what Ben wrote: Use the sequencer to start a run.
> The sequencer script can obtain a new run number from a central instance (e.g. by calling a shell script
> like 'curl ...' to obtain the new run number, then put it into /Runinfo/Run number as Ben wrote. This has
> the advantage that the run is _started_ already with the correct number, so the history system is fine.
>
Hi Stefan, this sounds like a perfect solution - thanks! - and leads to another, more technical, question:
- how does one communicate with an external shell script from MSL ? I looked at the MIDAS Sequencer page
https://daq00.triumf.ca/MidasWiki/index.php/Sequencer
and didn't find an immediately obvious candidate among the MSL commands.
The closest seems to be
'SCRIPT script [, a, b, c, ...]'
but I couldn't easily figure how to propagate the output of the script back to MIDAS.
Let say, the script creates an ASCII file with the next run number. What is the easiest
way to import the run number into ODB? - Should an external script spawn a [short-lived]
MIDAS client ? - That would work, but I'm almost sure there is a more straightforward solution.
Of course, the assumption that the 'SCRIPT' command provides the solution could be wrong.
-- thanks again, regards, Pasha |
2642
|
03 Dec 2023 |
Pavel Murat | Forum | run number from an external (*SQL) db? | > - how does one communicate with an external shell script from MSL ?
trying to answer my own question, as I didn't find a clear answer in the forum archive :
1. one could have a MSL script with a 'SCRIPT ./myscript.sh' command in it -
that would run a shell script named 'myscript.sh'
[that was not obvious from the documentation on MIDAS wiki, and adding a couple of clarifying
sentences there would go long ways]
2. if a script produces an ascii file with a known name, for example, 'a.odb', with the following two lines:
--------------------------------------- a.odb
[/Runinfo]
Run number = INT32 : 105
--------------------------------------- end a.odb
one can use the 'odbload' MSL command :
odbload a.odb
and get the run number set to 105. It works, but I'm curious if that is the right (envisaged)
way of interacting with the shell scripts, or one could do better than that.
-- thanks, regards, Pasha |
2643
|
04 Dec 2023 |
Stefan Ritt | Forum | run number from an external (*SQL) db? | > - how does one communicate with an external shell script from MSL ? I looked at the MIDAS Sequencer page
>
> https://daq00.triumf.ca/MidasWiki/index.php/Sequencer
>
> and didn't find an immediately obvious candidate among the MSL commands.
> The closest seems to be
>
> 'SCRIPT script [, a, b, c, ...]'
>
> but I couldn't easily figure how to propagate the output of the script back to MIDAS.
> Let say, the script creates an ASCII file with the next run number. What is the easiest
> way to import the run number into ODB? - Should an external script spawn a [short-lived]
> MIDAS client ? - That would work, but I'm almost sure there is a more straightforward solution.
The output of the SCRTIP command is stored in the variable $SCRIPT_RESULT. Please pull midas to get this
new functionality.
Stefan |
2644
|
04 Dec 2023 |
Stefan Ritt | Forum | run number from an external (*SQL) db? | > [that was not obvious from the documentation on MIDAS wiki, and adding a couple of clarifying
> sentences there would go long ways]
I added a sentence there. Please have a look. If you like more info, please write it yourself and send it to me.
It's always better if that comes from users than from me.
> 2. if a script produces an ascii file with a known name, for example, 'a.odb', with the following two lines:
Use $SCRIPT_RESULT as described before.
Best,
Stefan |
1143
|
24 Nov 2015 |
Robert Pattie | Forum | rpc_client_dispatch error | I'm trying to set up an experiment with 2 frontends for the first time. When I
start the remote frontend I get the following errors:
first time (odd attempt):
[MCS_Frontend_203,ERROR] [midas.c:9678:rpc_server_connect,ERROR] mserver
subprocess could not be started (check path)
[MCS_Frontend_203,ERROR] [mfe.c:2696:mainFE,ERROR] Cannot connect to experiment
'Default' on host 'ucntau-daq.lanl.gov', status 503
second time (even attempt):
MCS6A_frontend: src/midas.c:9085: rpc_client_dispatch: Assertion `n ==
sizeof(NET_COMMAND_HEADER) + 4 * sizeof(INT)' failed.
On the local host I'm running : mlogger, a frontend, an analzer, mhttp, and
mserver. I followed the instructions for adding the remote computer to the
RPC_ALLOWED list and I do see that the remote frontend was able to edit the
local odb equipment list. At present I'm not running an event builder I just
wanted to get the frontends connected to start. Do I need to have the mserver
running on both computers? Any suggestions on where to start troubleshooting this?
Thanks |
1144
|
25 Nov 2015 |
Konstantin Olchanski | Forum | rpc_client_dispatch error | Not clear on what you are doing, so here is the brief description:
- you have two machines - say "midas" and "frontend"
- you run mttpd, mlogger, etc on "midas"
- you want to run some frontend on "frontend"
Do this:
- on "midas", open a new terminal, run "mserver -p 7071"
- on "frontend", open a new terminal, run "odbedit -h midas:7071"
If you did follow all the online instruction correctly, at this point, your odbedit on "frontend" would have
connected and all commands would work same as if run locally on "midas".
If I understand you correctly, you got this far.
Next do this:
- on "frontend", open a new terminal, run "your_frontend.exe -h midas:7071"
If all is good, the frontend would start, would connect to midas, you would see
it in odbedit "scl" and on the midas status page and you would be able to stop
it from the midas "programs" page. (this last bit is important).
I guess this is where things go wrong and you do not get anything working.
Do this:
a) cut and paste all the output from the terminal window where you are running the mserver (including the
command you used to start the mserver)
b) cut and paste all the output from the terminal window where you are starting the frontemd (again,
including the command you used to start the frontend)
c) cut and paste the contents of midas.log (in the experiment directory) from the time you started the
mserver until the very end.
Paste all this as reply to this message or email it to me at olchansk@triumf.ca
With this additional information we should be able to get you going (and hopefully improve the
documentation so the next person does not run into the same problem - whatever the problem turns out to
be).
K.O.
> I'm trying to set up an experiment with 2 frontends for the first time. When I
> start the remote frontend I get the following errors:
>
> first time (odd attempt):
>
> [MCS_Frontend_203,ERROR] [midas.c:9678:rpc_server_connect,ERROR] mserver
> subprocess could not be started (check path)
> [MCS_Frontend_203,ERROR] [mfe.c:2696:mainFE,ERROR] Cannot connect to experiment
> 'Default' on host 'ucntau-daq.lanl.gov', status 503
>
> second time (even attempt):
>
> MCS6A_frontend: src/midas.c:9085: rpc_client_dispatch: Assertion `n ==
> sizeof(NET_COMMAND_HEADER) + 4 * sizeof(INT)' failed.
>
> On the local host I'm running : mlogger, a frontend, an analzer, mhttp, and
> mserver. I followed the instructions for adding the remote computer to the
> RPC_ALLOWED list and I do see that the remote frontend was able to edit the
> local odb equipment list. At present I'm not running an event builder I just
> wanted to get the frontends connected to start. Do I need to have the mserver
> running on both computers? Any suggestions on where to start troubleshooting this?
>
> Thanks |
424
|
05 Feb 2008 |
qinzeng peng | Forum | rpc timeout, related to event_size and watch dog? need help | Dear all,
I'm trying to write a simulation code on midas. What I did is just modify the
frontend.c(pp) from experiment samples and made some parameters change on midas.h .
Because my simulation ask for about 4.5MB for each event, so I increase the
MAX_EVENT_SIZE and max_event_size accordingly.
in midas.h :
#define MAX_EVENT_SIZE 0xa00000 //0x400000 /**< maximum event size 4MB*/
#define BANKLIST_MAX 640 //64 /**< max # of banks in event */
#define DEFAULT_RPC_TIMEOUT 60000 //10000
#define WATCHDOG_INTERVAL 5000 //1000
#define DEFAULT_WATCHDOG_TIMEOUT 60000 /**< Watchdog */
in frontend.cpp :
BOOL frontend_call_loop = TRUE;
INT max_event_size = 5 * 1024 * 1024;
INT max_event_size_frag = 2* max_event_size;
INT event_buffer_size = 2 * max_event_size;
EQUIPMENT equipment[] = {
{"WFD_SIMU", /* equipment name */
{1, 0, /* event ID, trigger mask */
"SYSTEM", /* event buffer */
#ifdef USE_INT
EQ_INTERRUPT, /* equipment type */
#else
EQ_POLLED, /* equipment type */
#endif
LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */
"MIDAS", /* format */
TRUE, /* enabled */
RO_RUNNING, // | /* read only when running */
// RO_ODB, /* and update ODB */
5000, /* poll for 500ms */
0, /* stop run after this event limit */
0, /* number of sub events */
0, /* don't log history */
"", "", "",},
read_simu_event, /* readout routine */
},
......
}
INT frontend_loop()
{
/* if frontend_call_loop is true, this routine gets called when
the frontend is idle or once between every event */
ss_sleep(100);
return SUCCESS;
}
Compilation OK and running mlogger, odbedit, frontend is OK.
start the run -> no problem ( but there is a long waiting time in frontend if
starting the run. Before the run begins, frontend terminal popping up messages
frequently, say, every 10 seconds. When run starts, frontend terminal hang on
for a couple of minutes before popping up next bunch of messages.)
stop the run -> Problem -> rpc timeout
message from odbedit:
[qzpeng@phy2-dhcp140 simu]$ odbedit -s 10000000
12:54:27 [WFD Simu,INFO] Program WFD Simu on host phy2-dhcp140 started
12:54:37 [Logger,INFO] Program Logger on host phy2-dhcp140 started
[local:simu:S]/>start
Run number [1]: 7
Are the above parameters correct? ([y]/n/q):
Starting run #7
Run #7 started
[local:simu:R]/>stop
[midas.c:9231:rpc_client_call,ERROR] rpc timeout, routine = "rc_transition",
host = "phy2-dhcp140.bu.edu"
Error: Unknown error 504 from client 'WFD Simu' on host phy2-dhcp140.bu.edu
[local:simu:R]/>
runing message from frontend:
[qzpeng@phy2-dhcp140 simu]$ ./frontend
Frontend name : WFD Simu
Event buffer size : 10485760
System max event size : 10485760
User max event size : 5242880
User max frag. size : 10485760
# of events per buffer : 2
Connect to experiment...
OK
Init hardware...
...... |
425
|
06 Feb 2008 |
Stefan Ritt | Forum | rpc timeout, related to event_size and watch dog? need help | Most likely you changed the maximal event size in midas.h, but you did not re-compile all programs. The maximal event size goes into the size of the shared memory buffer, so all participating programs have to have the same setting, especially the mserver program. So do the following:
- update to the latest midas version, which is revision 4116
- modify in your midas.h only MAX_EVENT_SIZE. The other settings you modified might have bad side effects. If you increase the RPC timeout, the error will still happen, just later. It comes from the fact that you sent too big events the the server (or the logger), which refuses to take the big events or simply crashes, so the RPC call never returns and after the timeout you get the error.
- recompile all midas programs, don't forget the mserver program
- run the standard demo frontend from the distribution
I tried the above and it just worked fine for me. |
426
|
06 Feb 2008 |
qinzeng peng | Forum | rpc timeout, related to event_size and watch dog? need help |
Stefan Ritt wrote: | Most likely you changed the maximal event size in midas.h, but you did not re-compile all programs. |
Every time I changed midas.h or system header files, I did the re-compile with following procedure:
ipcrm
rm .*.SHM
mcleanup
make clean
make
su
make install
Stefan Ritt wrote: | The maximal event size goes into the size of the shared memory buffer, so all participating programs have to have the same setting, especially the mserver program. |
Question here:
How to compile mserver seperately? I think make and make install under midas directory already did the job.
Stefan Ritt wrote: | update to the latest midas version, which is revision 4116 |
I used latest svn version, so I believe I'm using the latest version 4116.
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/midas/trunk midas
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/mxml/trunk mxml
I followed your instructions and did the following:
1)
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/midas/trunk midas
svn co svn+ssh://svn@savannah.psi.ch/afs/psi.ch/project/meg/svn/mxml/trunk mxml
2)
changed two parameters in midas.h
#define MAX_EVENT_SIZE 0xa00000 //0x400000 /**< maximum event size 4MB->10MB*/
#define BANKLIST_MAX 640 //64 /**< max # of banks in event, I need 356 */
3) make
su
make install
I don't know if I need compile mserver seperately.
4) running only two programs:
odbedit -s 10000000
./frontend
And I still got the same problem as before.
[qzpeng@phy2-dhcp140 simu]$ odbedit -s 10000000
[local:simu:S]/>ls
System
Programs
Experiment
Logger
Runinfo
Alarms
[local:simu:S]/>mkdir Equipment
12:44:12 [WFD Simu,INFO] Program WFD Simu on host phy2-dhcp140 started
[local:simu:S]/>start
Run number [1]:
Are the above parameters correct? ([y]/n/q):
Starting run #1
Run #1 started
[local:simu:R]/>stop
[midas.c:9231:rpc_client_call,ERROR] rpc timeout, routine = "rc_transition", host = "phy2-dhcp140.bu.edu"
Error: Unknown error 504 from client 'WFD Simu' on host phy2-dhcp140.bu.edu
[local:simu:R]/>
And I know that the run stopped after a while on frontend, but after the eroor message showed above. If I tried to stop again in odb after a while, it did stopped.
[local:simu:R]/>stop
Run #1 stopped
By the way, thanks for the quick response. I've been working on this for a couple of weeks and I am a newbie.
I also attached my frontend.cpp code and output of make with warning message but comilation completed. Thanks in advance.
In frontend.cpp I only use simulation and don't need any hardware realted issue or function calls but I jsut leave some of them there. |
Attachment 1: frontend.cpp
|
/********************************************************************\
Name: frontend.c
Created by: Stefan Ritt
Contents: Experiment specific readout code (user part) of
Midas frontend. This example simulates a "trigger
event" and a "scaler event" which are filled with
CAMAC or random data. The trigger event is filled
with two banks (ADC0 and TDC0), the scaler event
with one bank (SCLR).
$Id: frontend.c 3384 2006-10-21 04:29:18Z amaudruz $
Modifed by: qp Jan/20/2008 for simulation
Jan 21, add on ROOT
method: keep old C functions in extern "C" {}
define new c++ funcions with ROOT
read pulse shape from pulseTemplate#.txt
\********************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <time.h>
#include "midas.h"
//#include "mcstd.h"
#include "experim.h"
#include <string.h>
/* ROOT include */
#include "TSystem.h"
#include "TROOT.h"
#include "TFile.h"
#include "TH1.h"
#include "TH2.h"
#include "WFDIndex.h"
WFDIndex *myWFDIndex;
/* for WFD Simu */
const INT n_fills=5000; /*** number of fills per segment from ODB ***/
const INT n_pulses_max=30;
INT n_pulses = 30; /*** number of muons decayed in one fill ***/
const int N_WFD=340;
const int N_SHAPE=2400;
const int N_ISLAND=24;
int N_STEP = N_SHAPE/N_ISLAND;
int debug = 1; // 0 for no message, 1 for message, 2 for verbose message
typedef struct {
char ADC[24];
DWORD separator;
DWORD time;
} ISLAND;
static ISLAND island, island_random;
ISLAND gIsland[N_WFD][n_fills*n_pulses_max+1];
INT gCount[N_WFD];
float gShape[N_WFD][N_SHAPE];
INT gPeak[N_WFD];
TFile *f, *fout;
char histname0[80], histname[80];
/* make frontend functions callable from the C framework */
#ifdef __cplusplus
extern "C" {
#endif
#include "mcstd.h"
/*-- Globals -------------------------------------------------------*/
/* The frontend name (client name) as seen by other MIDAS clients */
char *frontend_name = "WFD Simu"; //"Sample Frontend";
/* The frontend file name, don't change it */
char *frontend_file_name = __FILE__;
/* frontend_loop is called periodically if this variable is TRUE */
BOOL frontend_call_loop = TRUE;
/* a frontend status page is displayed with this frequency in ms */
INT display_period = 3000;
/* maximum event size produced by this frontend */
INT max_event_size = 5 * 1024 * 1024;
/* maximum event size for fragmented events (EQ_FRAGMENTED) */
INT max_event_size_frag = 2* max_event_size;
/* buffer size to hold events */
INT event_buffer_size = 2 * max_event_size;
/* number of channels */
#define N_ADC 4
#define N_TDC 4
#define N_SCLR 4
/* CAMAC crate and slots */
#define CRATE 0
#define SLOT_IO 23
#define SLOT_ADC 1
#define SLOT_TDC 2
#define SLOT_SCLR 3
/*-- Function declarations -----------------------------------------*/
INT frontend_init();
INT frontend_exit();
INT begin_of_run(INT run_number, char *error);
INT end_of_run(INT run_number, char *error);
INT pause_run(INT run_number, char *error);
INT resume_run(INT run_number, char *error);
INT frontend_loop();
INT read_simu_event(char *pevent, INT off);
INT read_scaler_event(char *pevent, INT off);
void register_cnaf_callback(int debug);
INT poll_event(INT source, INT count, BOOL test);
INT interrupt_configure(INT cmd, INT source, POINTER_T adr);
/*-- Equipment list ------------------------------------------------*/
#undef USE_INT
EQUIPMENT equipment[] = {
{"WFD_SIMU", /* equipment name */
{1, 0, /* event ID, trigger mask */
"SYSTEM", /* event buffer */
#ifdef USE_INT
EQ_INTERRUPT, /* equipment type */
#else
EQ_POLLED, /* equipment type */
#endif
LAM_SOURCE(0, 0xFFFFFF), /* event source crate 0, all stations */
"MIDAS", /* format */
TRUE, /* enabled */
RO_RUNNING, // | /* read only when running */
// RO_ODB, /* and update ODB */
5000, /* poll for 500ms */
0, /* stop run after this event limit */
0, /* number of sub events */
0, /* don't log history */
"", "", "",},
read_simu_event, /* readout routine */
},
{"Scaler", /* equipment name */
{2, 0, /* event ID, trigger mask */
"SYSTEM", /* event buffer */
EQ_PERIODIC | EQ_MANUAL_TRIG, /* equipment type */
0, /* event source */
"MIDAS", /* format */
TRUE, /* enabled */
RO_RUNNING | RO_TRANSITIONS | /* read when running and on transitions */
RO_ODB, /* and update ODB */
10000, /* read every 10 sec */
0, /* stop run after this event limit */
0, /* number of sub events */
0, /* log history */
"", "", "",},
read_scaler_event, /* readout routine */
},
{""}
};
#ifdef __cplusplus
}
#endif
INT wfd_get_shape(void);
INT wfd_get_hist(void);
double wfd_get_random(int sn, int choice);
/********************************************************************\
Callback routines for system transitions
These routines are called whenever a system transition like start/
stop of a run occurs. The routines are called on the following
occations:
frontend_init: When the frontend program is started. This routine
should initialize the hardware.
frontend_exit: When the frontend program is shut down. Can be used
to releas any locked resources like memory, commu-
nications ports etc.
begin_of_run: When a new run is started. Clear scalers, open
rungates, etc.
end_of_run: Called on a request to stop a run. Can send
end-of-run event and close run gates.
pause_run: When a run is paused. Should disable trigger events.
resume_run: When a run is resumed. Should enable trigger events.
\********************************************************************/
/*-- Frontend Init -------------------------------------------------*/
INT frontend_init()
{
/* hardware initialization */
cam_init();
cam_crate_clear(CRATE);
cam_crate_zinit(CRATE);
/* enable LAM in IO unit */
camc(CRATE, SLOT_IO, 0, 26);
/* enable LAM in crate controller */
cam_lam_enable(CRATE, SLOT_IO);
/* reset external LAM Flip-Flop */
camo(CRATE, SLOT_IO, 1, 16, 0xFF);
camo(CRATE, SLOT_IO, 1, 16, 0);
/* register CNAF functionality from cnaf_callback.c with debug output */
register_cnaf_callback(1);
/* print message and return FE_ERR_HW if frontend should not be started */
wfd_get_hist();
wfd_get_shape();
myWFDIndex = new WFDIndex();
return SUCCESS;
}
/*-- Frontend Exit -------------------------------------------------*/
INT frontend_exit()
{
return SUCCESS;
}
/*-- Begin of Run --------------------------------------------------*/
INT begin_of_run(INT run_number, char *error)
{
/* put here clear scalers etc. */
island.ADC[0] = 5;
island.ADC[1] = 6;
island.ADC[2] = 7;
island.ADC[3] = 5;
island.ADC[4] = 7;
island.ADC[5] = 20;
island.ADC[6] = 30;
island.ADC[7] = 50;
island.ADC[8] = 90;
island.ADC[9] = 120;
island.ADC[10] = 150;
island.ADC[11] = 200;
island.ADC[12] = 165;
island.ADC[13] = 130;
island.ADC[14] = 110;
island.ADC[15] = 90;
island.ADC[16] = 30;
island.ADC[17] = 10;
island.ADC[18] = 7;
island.ADC[19] = 4;
island.ADC[20] = 6;
island.ADC[21] = 5;
island.ADC[22] = 3;
island.ADC[23] = 6;
//island.ADC[24] = 7;
//island.ADC[25] = 6;
//island.ADC[26] = 6;
//island.ADC[27] = 7;
//island.ADC[28] = 5;
//island.ADC[29] = 5;
//island.ADC[30] = 6;
//island.ADC[31] = 5;
island.separator = 0x0;
island.time = 0x00010001;
// wfd_get_hist();
return SUCCESS;
}
INT wfd_get_hist(void)
{
gROOT->Reset();
char filename0[] = "IslandParameters";
char runname[] = "57140-57170";
... 338 more lines ...
|
Attachment 2: make-output.txt
|
[qzpeng@phy2-dhcp140 midas]$ make
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/midas.o src/midas.c
src/midas.c: In function ¡Æbm_open_buffer¡Ç:
src/midas.c:4020: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/midas.c: In function ¡Ærpc_server_connect¡Ç:
src/midas.c:8259: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/midas.c:8261: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/midas.c:8263: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/midas.c:8376: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
src/midas.c:8378: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
src/midas.c:8380: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
src/midas.c: In function ¡Ærpc_register_server¡Ç:
src/midas.c:10533: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/midas.c: In function ¡Ærpc_server_accept¡Ç:
src/midas.c:11230: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
src/midas.c:11239: warning: pointer targets in passing argument 3 of ¡Ægetpeername¡Ç differ in signedness
src/midas.c: In function ¡Ærpc_client_accept¡Ç:
src/midas.c:11493: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/system.o src/system.c
src/system.c: In function ¡Æss_suspend_init_ipc¡Ç:
src/system.c:2948: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/system.c: In function ¡Æss_suspend¡Ç:
src/system.c:3416: warning: pointer targets in passing argument 6 of ¡Ærecvfrom¡Ç differ in signedness
src/system.c:3443: warning: pointer targets in passing argument 6 of ¡Ærecvfrom¡Ç differ in signedness
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mrpc.o src/mrpc.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/odb.o src/odb.c
src/odb.c: In function ¡Ædb_open_database¡Ç:
src/odb.c:891: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/odb.c: In function ¡Ædb_lock_database¡Ç:
src/odb.c:1441: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/ybos.o src/ybos.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/ftplib.o src/ftplib.c
src/ftplib.c: In function ¡Æftp_data¡Ç:
src/ftplib.c:288: warning: pointer targets in passing argument 3 of ¡Ægetsockname¡Ç differ in signedness
src/ftplib.c:310: warning: pointer targets in passing argument 3 of ¡Æaccept¡Ç differ in signedness
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mxml.o ../mxml/mxml.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/cnaf_callback.o src/cnaf_callback.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/history.o src/history.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/alarm.o src/alarm.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/elog.o src/elog.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/strlcpy.o ../mxml/strlcpy.c
rm -f linux/lib/libmidas.a
ar -crv linux/lib/libmidas.a linux/lib/midas.o linux/lib/system.o linux/lib/mrpc.o linux/lib/odb.o linux/lib/ybos.o linux/lib/ftplib.o linux/lib/mxml.o linux/lib/cnaf_callback.o linux/lib/history.o linux/lib/alarm.o linux/lib/elog.o linux/lib/strlcpy.o
a - linux/lib/midas.o
a - linux/lib/system.o
a - linux/lib/mrpc.o
a - linux/lib/odb.o
a - linux/lib/ybos.o
a - linux/lib/ftplib.o
a - linux/lib/mxml.o
a - linux/lib/cnaf_callback.o
a - linux/lib/history.o
a - linux/lib/alarm.o
a - linux/lib/elog.o
a - linux/lib/strlcpy.o
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mana.o src/mana.c
g++ -DUSE_ROOT -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -pthread -m32 -I/usr/root/include -o linux/lib/rmana.o src/mana.c
cc -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/mfe.o src/mfe.c
src/mfe.c: In function ¡Æscheduler¡Ç:
src/mfe.c:1869: warning: pointer targets in passing argument 5 of ¡Ædb_get_value¡Ç differ in signedness
src/mfe.c:2042: warning: pointer targets in passing argument 5 of ¡Ædb_get_value¡Ç differ in signedness
src/mfe.c:2051: warning: pointer targets in passing argument 5 of ¡Ædb_get_value¡Ç differ in signedness
g++ -Dextname -DMANA_LITE -c -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/lib/fal.o src/fal.c
src/fal.c:106: warning: non-local variable ¡Æ<anonymous struct> out_info¡Ç uses anonymous type
src/fal.c: In function ¡ÆINT midas_log_open(LOG_CHN*, INT)¡Ç:
src/fal.c:1194: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/fal.c: In function ¡ÆINT dump_log_open(LOG_CHN*, INT)¡Ç:
src/fal.c:1582: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/fal.c: In function ¡ÆINT ascii_log_open(LOG_CHN*, INT)¡Ç:
src/fal.c:1803: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/fal.c: At global scope:
src/fal.c:3064: warning: non-local variable ¡Æ<anonymous struct> eb¡Ç uses anonymous type
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mserver src/mserver.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhttpd src/mhttpd.c src/mgd.c linux/lib/libmidas.a -lutil -lpthread -lz -lm
g++ -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mlogger src/mlogger.c linux/lib/libmidas.a -L/usr/root/lib -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -pthread -lm -ldl -rdynamic -Wl,-rpath,/usr/root/lib -lutil -lpthread -lz
src/mlogger.c: In function ¡ÆINT midas_log_open(LOG_CHN*, INT)¡Ç:
src/mlogger.c:1094: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/mlogger.c: In function ¡ÆINT dump_log_open(LOG_CHN*, INT)¡Ç:
src/mlogger.c:1530: warning: dereferencing type-punned pointer will break strict-aliasing rules
src/mlogger.c: In function ¡ÆINT ascii_log_open(LOG_CHN*, INT)¡Ç:
src/mlogger.c:1750: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/odbedit src/odbedit.c src/cmdedit.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mtape utils/mtape.c linux/lib/libmidas.a -lutil -lpthread -lz
utils/mtape.c: In function ¡Ætape_dir¡Ç:
utils/mtape.c:84: warning: dereferencing type-punned pointer will break strict-aliasing rules
utils/mtape.c:87: warning: dereferencing type-punned pointer will break strict-aliasing rules
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhist utils/mhist.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mstat utils/mstat.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mcnaf utils/mcnaf.c drivers/camac/camacrpc.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mdump utils/mdump.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/lazylogger src/lazylogger.c linux/lib/libmidas.a -lutil -lpthread -lz
g++ -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mhdump utils/mhdump.cxx
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mchart utils/mchart.c linux/lib/libmidas.a -lutil -lpthread -lz
cp -f utils/stripchart.tcl linux/bin/.
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/webpaw utils/webpaw.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/odbhist utils/odbhist.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/melog utils/melog.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/mlxspeaker utils/mlxspeaker.c linux/lib/libmidas.a -lutil -lpthread -lz
cc -g -O3 -Wall -Wuninitialized -Iinclude -Idrivers -I../mxml -Llinux/lib -DINCLUDE_FTPLIB -D_LARGEFILE64_SOURCE -DHAVE_ROOT -pthread -m32 -I/usr/root/include -DHAVE_ZLIB -DOS_LINUX -fPIC -Wno-unused-function -o linux/bin/dio utils/dio.c
[qzpeng@phy2-dhcp140 midas]$
|
427
|
06 Feb 2008 |
Stefan Ritt | Forum | rpc timeout, related to event_size and watch dog? need help | First of all, I would appreciate if you do not post your entry ten times. Each time you edit it, you produce an email notification going to everybody, so people might get annoyed to receive too many emails from you. Think what you want to write and then post once.
Second, I told you to use the frontend from the distribution, but you used your own code. Since I successfully ran the demo frontend with the large event size, the origin of your problem must be "in between". So start with the demo frontend, try it, then modify its buffer size in frontend.c, then try again. When I told to to recompile midas, I meant you should also recompile your front-end each time you change midas.h. The mserver is automatically recompiled when you recompile and install midas (just check the /usr/local/bin/mserver date and time to confirm that it got updated during your last "make install"). Then add things from your specific front-end program step by step to see at which step the problem occurs the first time. This gives you some hint where the real cause lies. |
1075
|
23 Jul 2015 |
Konstantin Olchanski | Info | rootana lz4 support, mlogger improvements | > A set of improvements to mlogger is in:
> b) test version of LZ4 high speed compression, support for bzip2 and pbzip2
rootana TMidasFile now supports reading .mid.lz4 compressed files via pipe through the "lz4" utility ("yum install lz4", "apt-get install liblz4-tool").
In MIDAS, the lz4 libraries are included with the MIDAS distribution, we are considering the same for ROOTANA.
(Support for reading mid.bz2 files via pipe through the bzip2 utility existed for a very long time).
https://bitbucket.org/tmidas/rootana/commits/e06bb7296a466b4178c7768bbc2470be361b2c72
K.O. |
2840
|
13 Sep 2024 |
Konstantin Olchanski | Bug Fix | rootana bitbucket build fixed | rootana bitbucket build is fixed, only a few minor build problems. I am using the
root official docker image (which turned out to not work right out of the box
becuase of missing libvdt-dev package). K.O. |
1507
|
28 Mar 2019 |
Gennaro Tortone | Bug Fix | rmlogger events - double counting |
Hi,
I realized that if I use 'rmlogger' to write events in ROOT format,
each event is counted twice;
to fix the problem I commented line 3446 of mlogger.cxx (inside root_write
function):
//log_chn->statistics.events_written++;
Regards,
Gennaro |
1512
|
28 Mar 2019 |
Konstantin Olchanski | Bug Fix | rmlogger events - double counting | > I realized that if I use 'rmlogger' to write events in ROOT format,
> each event is counted twice;
>
> to fix the problem I commented line 3446 of mlogger.cxx (inside root_write
> function):
>
> //log_chn->statistics.events_written++;
>
I confirm this problem - event counter is incremented by root_write() and by log_write() after calling
root_write() through the WriterRoot::wr_write().
I will try to fix this for the next release of midas, keep an eye on it here:
https://bitbucket.org/tmidas/midas/issues/177
BTW, I do not think the ROOT writer (and rmlogger) get much use these days, as most experiments we do
today have data in binary formats that do not fit naturally for storage into ROOT TTree objects. We mostly
record digitized waveforms and such and they are best stored in binary midas files. The ROOT analyzer
would read them using the midasio.h classes from the ROOTANA package.
BTW2, for recording MIDAS data, ROOT I/O uses the wrong compression - they compress using gzip,
which is too slow compared to LZ4 on one side and does not compress as well as BZIP2 on the other side.
K.O. |
Draft
|
29 Mar 2019 |
Gennaro Tortone | Bug Fix | rmlogger events - double counting | Hi,
> I confirm this problem - event counter is incremented by root_write() and by log_write() after calling
> root_write() through the WriterRoot::wr_write().
>
> I will try to fix this for the next release of midas, keep an eye on it here:
> https://bitbucket.org/tmidas/midas/issues/177
thanks !
> BTW, I do not think the ROOT writer (and rmlogger) get much use these days, as most experiments we do
> today have data in binary formats that do not fit naturally for storage into ROOT TTree objects. We mostly
> record digitized waveforms and such and they are best stored in binary midas files. The ROOT analyzer
> would read them using the midasio.h classes from the ROOTANA package.
yes, I agree with you about this, but to have a "quick and dirty" plot on some ADC channels
can be a very nice "temporary" solution when you are developing your software DAQ...
Regards,
Gennaro
> BTW2, for recording MIDAS data, ROOT I/O uses the wrong compression - they compress using gzip,
> which is too slow compared to LZ4 on one side and does not compress as well as BZIP2 on the other side.
>
> K.O. |
1515
|
29 Mar 2019 |
Gennaro Tortone | Bug Fix | rmlogger events - double counting | Hi,
> I confirm this problem - event counter is incremented by root_write() and by log_write() after calling
> root_write() through the WriterRoot::wr_write().
>
> I will try to fix this for the next release of midas, keep an eye on it here:
> https://bitbucket.org/tmidas/midas/issues/177
thanks !
> BTW, I do not think the ROOT writer (and rmlogger) get much use these days, as most experiments we do
> today have data in binary formats that do not fit naturally for storage into ROOT TTree objects. We mostly
> record digitized waveforms and such and they are best stored in binary midas files. The ROOT analyzer
> would read them using the midasio.h classes from the ROOTANA package.
yes, I agree with you that ROOT files are not suitable to store "first level" data, but this is a very
useful solution when you are developing a software DAQ and you need some (quick) spectra in order
to verify some code...
Regards,
Gennaro |
1518
|
29 Mar 2019 |
Konstantin Olchanski | Bug Fix | rmlogger events - double counting | >
> > BTW, I do not think the ROOT writer (and rmlogger) get much use these days ...
>
> yes, I agree with you that ROOT files are not suitable to store "first level" data, but this is a very
> useful solution when you are developing a software DAQ and you need some (quick) spectra in order
> to verify some code...
>
I confirm that we are keeping the ROOT writer, sometimes it is useful.
Also sorry about all the bugs in that code, it pretty much gets no testing this days, other than by people who try to use it.
K.O. |
1508
|
28 Mar 2019 |
Gennaro Tortone | Bug Report | rmlogger - bk_swap( ) |
Hi,
if I use 'rmlogger' to write ROOT event files after few seconds from
START rmlogger fails with this:
*** Break *** segmentation violation
I realized that removing bk_swap(...) from line 3364 of mlogger.cxx
it works fine...
Regards,
Gennaro |
1510
|
28 Mar 2019 |
Konstantin Olchanski | Bug Report | rmlogger - bk_swap( ) | > if I use 'rmlogger' to write ROOT event files after few seconds from
> START rmlogger fails with this:
>
> *** Break *** segmentation violation
>
> I realized that removing bk_swap(...) from line 3364 of mlogger.cxx
> it works fine...
Please post a stack trace from this crash. Thanks.
K.O. |
1511
|
28 Mar 2019 |
Konstantin Olchanski | Bug Report | rmlogger - bk_swap( ) | > > if I use 'rmlogger' to write ROOT event files after few seconds from
> > START rmlogger fails with this:
> >
> > *** Break *** segmentation violation
> >
> > I realized that removing bk_swap(...) from line 3364 of mlogger.cxx
> > it works fine...
>
> Please post a stack trace from this crash. Thanks.
>
bk_swap() should not activate normally. (Unless you are sending events from a big-endian
machine. Hmm... maybe you do. What are you running on and where are you generating
events, what CPU is there "cat /proc/cpuinfo").
there is also possibility of malformed event.
please print the value of pbh->flags, in hex. (if you can print the value of all the other data
fields in pbh, that would be good, too).
K.O. |
|