Page History

...

Messi in bypass su DBFile del DEVIL628 gli elementi DHSTB002, QUATB003 e QUATB004. 

...

...

Messi in bypass su DBFile del DEVIL628 gli elementi DHSTB002, QUATB003 e QUATB004. 

...

...

La data predefinita nei salvataggio dei dataset di una barra dante che girava sulla dante003 era errata (1987). 

...

Impostata data a mano e riavviato di nuovo il servizio ntp da utente root

...

Il client ntp era spento perché la data impostata era troppo distante da quella fornita dall'ntp server. La batteria della force003 è scarica quindi la data si resetta ad ogni riavvio.
Lanciando il comando ps -fe | grep ntp infatti si nota che sulla macchina dante003 il client ntp non sta girando mentre sulle altre force si (lanciando il comando ntpq -c peers si nota che sulle altre force l’output è una lista di server ntp mentre sulla dante003 viene stampato un messaggio di errore). 
Dal log /var/adm/messages si nota che ntp ha riscontrato una discrepanza di data troppo grande e si è chiuso.

Si provvede a rilanciare il client ntp sulla dante003 da utente root con il comando /usr/lib/inet/xntpd e si controlla che il client ntp sia configurato per partire all’avvio della macchina (in effetti è presente lo script /etc/rc2.d/S74xntpd su tutte le force).

Con il comando date si controlla che la data sia corretta e con il comando ntpq -c peers l’output è correttamente una lista di server ntp.

Data: 21/01/2021 
Oggetto: Data errata su dante003 (ntp spento) 
ID: 20210121.1 
Autore: P.C. 
Problema: La data predefinita nei salvataggio dei dataset di una barra dante che girava sulla dante003 era errata (1987) 
Soluzione: Il client ntp era spento. Lanciato di nuovo da utente root con il comando /usr/lib/inet/xntpd 
Descrizione:  

Un operatore ha aperto il ticket http://www.lnf.infn.it/acceleratori/public/trouble/updateList.php?id=5730 descrivendo un problema di data errata durante il salvataggio di un dataset. 

 A.S. ha trovato in effetti la data errata sulla macchina dante003 e l’ha reimpostata manualmente da utente root con il comando date mmddHHMMyyyy (dove mm è il mese a due digit, dd il giorno a due digit, HH è l'ora in formato 24 ore a due digit, MM i minuti a due digit e yyyy l’anno a quattro digit).

Lanciando il comando ps -fe | grep ntp si nota però che sulla macchina dante003 il client ntp non sta girando (lanciando il comando ntpq -c peers si nota che sulle altre force l’output è una lista di server ntp mentre sulla dante003 viene stampato un messaggio di errore), mentre sulle altre force si. 

Si provvede quindi a rilanciare il client ntp sulla dante003 da utente root con il comando /usr/lib/inet/xntpd e si controlla che il client ntp sia configurato per partire all’avvio della macchina (in effetti è presente lo script /etc/rc2.d/S74xntpd su tutte le force). 

Si controlla che il client ntp sia configurato per partire all’avvio della macchina (in effetti è presente lo script /etc/rc2.d/S74xntpd su tutte le force). 

Con il comando date si controlla che la data sia corretta e con il comando ntpq -c peers l’output è correttamente una lista di server ntp. 

Data: 15/01/2021 

Oggetto: Valori del vuoto e rawData vuoti o a zero (0) 

ID: 20210115.1 

Autore: P.C. 

Problema: Dati del vuoto assenti o uguali a zero. Idem per la pagina rawData 

Soluzione: fermare in ordine devil 205, 203, 202; Chiudere devil 203; Riaprire devil 203 con “Manual Management” da sysreset; far partire in ordine devil 202, 203 e 205. 

Descrizione:  

Sandro De Biase segnala che i valori del vuoto dalla sala controllo si vedono, mentre dalla pagina web di dafne http://dafne.lnf.infn.it/cgi-bin/vs.csh no (restano tutti a zero). Ho notato che quel grafico del vuoto viene generato dallo script /space/daq/status/dafnePlots.csh che a sua volta lancia più generateJPEG con diversi parametri. Visto che gli UDPServer su dafne girano senza problemi ed il problema sembra nella parte che genera i dati, ho fatto le seguenti operazioni:  

• Ho provato a far riavviare il devil202 ma non ha sortito effetto; 

• Sono entrato in VNC sulla console in sala controllo ed ho notato che stoppando il devil203 e riavviandolo apparivano dei warning nel campo log del devil (segnalando una discrepanza di tempo). Allora l’ho chiuso e riaperto col tool “Manual Management” della SysReset ed ho fermato in ordine il devil205, 203 e 202. Ho aspettato 10 secondi ed ho fatto ripartire prima il devil202, poi il 203 (stavolta non sono apparsi warning) ed infine il 205. 

Rilanciando a mano il comando /space/daq/status/dafnePlots.csh ho notato che le immagini finalmente contengono i dati, di conseguenza il problema è risolto. 

Data: 23/11/2020 

Oggetto: Font di LabVIEW in sala controllo più grandi (su solaris) dopo riavvio sunray server 

ID: 20201123.1 

Autore: P.C. 

Descrizione:  

Dopo un riavvio del sunray server (per consumo eccessivo di ram), le barre dante in sala controllo avevano i font “sballati” (più grandi del solito, con conseguente disallineamento delle righe degli elementi nei mag terminal e nei menù delle applicazioni LabVIEW). Per risolvere la problematica, ho dovuto modificare la dimensione dei font (Application Font, System Font, Etc) dalle opzioni di labview (Tools -> Options… -> Fonts) che era diventata 10 invece di essere 9. Dopo averla reimpostata correttamente, ho chiuso labview, fatto logout dalla sunray e riloggato. I font ora sono corretti e tutto funziona senza problemi (unica nota: il menu’ dell’applicazione con il disegno di dafne è diventato in grassetto, ma si vede bene). 

NOTA: probabilmente, il file di configurazione delle preferenze di labview in qualche modo si è corrotto. La prossima volta che dovesse ricapitare una cosa simile, provare prima a ripristinare il file delle pref al path /u1/dafne/.labviewrc con il suo backup presente in /u1/dafne/.labviewrc.20201123.save 

Data: 28/10/2020 

Oggetto: Plot dei rawData su dafne.lnf.infn.it non visibile con errre 

ID: 20201028.1 

Autore: P.C. 

Descrizione:  

Dal vuoto si segnala che alla url http://dafne.lnf.infn.it/cgi-bin/rawData quando si prova a “plottare” un elemento appare un errore. 

Dopo diagnosi, si è scoperto che la cartella /space/daq/www/scratch era dell’utente daq e del gruppo dcs, mentre il web server gira come nobody:nobody. Di conseguenza, la pagina web che chiamava lo script /space/daq/www/cgi-bin/generateJPEG dava errore perché questo script provava a salvare l’immagine generata nella cartella scratch ma non ne aveva i permessi. 

La cartella è stata reimpostata a nobody:nobody con permessi in rwx per tutti gli utenti e la pagina non ha più avuto problemi. 

Data: 30/06/2020 

Oggetto: modifica a IPTable.DBFile 

ID: 20200630.1 

Autore: A.S. 

Descrizione:  

Inserito DEVIL671 nel file IPTable.DBFile per test alimentatori BTF2. Documentazione su Confluence aggiornata. 

Data: 05/05/2020 

Oggetto: http://dafne.lnf.infn.it/cgi-bin/rawData modificato per visualizzare dati di vecchi elementi non in linea 

ID: 20200505.2 

Autore: P.C. 

Descrizione:  

La pagina

Data: 21/01/2021 

Oggetto: Data errata su dante003 (ntp spento) 

ID: 20210121.1 

Autore: P.C. 

Problema: La data predefinita nei salvataggio dei dataset di una barra dante che girava sulla dante003 era errata (1987) 

Soluzione: Il client ntp era spento. Lanciato di nuovo da utente root con il comando /usr/lib/inet/xntpd 

Descrizione:  

Un operatore ha aperto il ticket http://www.lnf.infn.it/acceleratori/public/trouble/updateList.php?id=5730 descrivendo un problema di data errata durante il salvataggio di un dataset. 

 A.S. ha trovato in effetti la data errata sulla macchina dante003 e l’ha reimpostata manualmente da utente root con il comando date mmddHHMMyyyy (dove mm è il mese a due digit, dd il giorno a due digit, HH è l'ora in formato 24 ore a due digit, MM i minuti a due digit e yyyy l’anno a quattro digit).

Lanciando il comando ps -fe | grep ntp si nota però che sulla macchina dante003 il client ntp non sta girando (lanciando il comando ntpq -c peers si nota che sulle altre force l’output è una lista di server ntp mentre sulla dante003 viene stampato un messaggio di errore), mentre sulle altre force si. 

Si provvede quindi a rilanciare il client ntp sulla dante003 da utente root con il comando /usr/lib/inet/xntpd e si controlla che il client ntp sia configurato per partire all’avvio della macchina (in effetti è presente lo script /etc/rc2.d/S74xntpd su tutte le force). 

Si controlla che il client ntp sia configurato per partire all’avvio della macchina (in effetti è presente lo script /etc/rc2.d/S74xntpd su tutte le force). 

Con il comando date si controlla che la data sia corretta e con il comando ntpq -c peers l’output è correttamente una lista di server ntp. 

Data: 15/01/2021 

Oggetto: Valori del vuoto e rawData vuoti o a zero (0) 

ID: 20210115.1 

Autore: P.C. 

Problema: Dati del vuoto assenti o uguali a zero. Idem per la pagina rawData 

Soluzione: fermare in ordine devil 205, 203, 202; Chiudere devil 203; Riaprire devil 203 con “Manual Management” da sysreset; far partire in ordine devil 202, 203 e 205. 

Descrizione:  

Sandro De Biase segnala che i valori del vuoto dalla sala controllo si vedono, mentre dalla pagina web di dafne http://dafne.lnf.infn.it/cgi-bin/vs.csh no (restano tutti a zero). Ho notato che quel grafico del vuoto viene generato dallo script /space/daq/status/dafnePlots.csh che a sua volta lancia più generateJPEG con diversi parametri. Visto che gli UDPServer su dafne girano senza problemi ed il problema sembra nella parte che genera i dati, ho fatto le seguenti operazioni:  

• Ho provato a far riavviare il devil202 ma non ha sortito effetto; 

• Sono entrato in VNC sulla console in sala controllo ed ho notato che stoppando il devil203 e riavviandolo apparivano dei warning nel campo log del devil (segnalando una discrepanza di tempo). Allora l’ho chiuso e riaperto col tool “Manual Management” della SysReset ed ho fermato in ordine il devil205, 203 e 202. Ho aspettato 10 secondi ed ho fatto ripartire prima il devil202, poi il 203 (stavolta non sono apparsi warning) ed infine il 205. 

Rilanciando a mano il comando /space/daq/status/dafnePlots.csh ho notato che le immagini finalmente contengono i dati, di conseguenza il problema è risolto. 

Data: 23/11/2020 

Oggetto: Font di LabVIEW in sala controllo più grandi (su solaris) dopo riavvio sunray server 

rawData (user: dafne, pass: 1033lumi) permette di interrogare i dati raw del sistema di controllo di dafne. Il problema è che se un elemento ha cambiato nome durante la sua vita e lo si cerca con il nome nuovo, i vecchi dati non si visualizzano più. E’ stata realizzata una patch per permettere di vedere anche i vecchi dati dei tre elementi che hanno cambiato nome: 
 

• DCTEL001 rinominato in DCTEL002 dal 25/04/2020 (ticket ID: 20200425.1); 
• DCTPS001 rinominato in DCTPS002 dal 25/04/2020 (ticket ID: 20200425.1);
• RDS42001 rinominato in RDS42002 dal 26/02/2020 (ticket ID: 20200226.1); 

 
Di conseguenza, se si cerca uno di questi elementi nuovi per una data antecedente al loro essere rinominati, la pagina si occupa di cercare il vecchio nome al posto del nuovo. 
 

ATTENZIONE: Se non si utilizza la pagina ma si modifica a mano la URL per avere dati più velocemente, ricordarsi che la patch permette di cercare i nomi nuovi per date antecedenti alla modifica del nome, ma se si cerca con il nome vecchio per date successive al cambio del nome, lo script non fa nulla e di conseguenza non si otterranno dati. 

Data: 05/05/2020 

Oggetto: dante002 riavviata 

ID: 20200505ID: 20201123.1 

Autore: P.C. 

Descrizione:  

Dopo un riavvio del sunray server (per consumo eccessivo di ram), le barre dante in sala controllo avevano i font “sballati” (più grandi del solito, con conseguente disallineamento delle righe degli elementi nei mag terminal e nei menù delle applicazioni LabVIEW). Per risolvere la problematica, ho dovuto modificare la dimensione dei font (Application Font, System Font, Etc) dalle opzioni di labview (Tools -> Options… -> Fonts) che era diventata 10 invece di essere 9. Dopo averla reimpostata correttamente, ho chiuso labview, fatto logout dalla sunray e riloggato. I font ora sono corretti e tutto funziona senza problemi (unica nota: il menu’ dell’applicazione con il disegno di dafne è diventato in grassetto, ma si vede bene). 

NOTA: probabilmente, il file di configurazione delle preferenze di labview in qualche modo si è corrotto. La prossima volta che dovesse ricapitare una cosa simile, provare prima a ripristinare il file delle pref al path /u1/dafne/.labviewrc con il suo backup presente in /u1/dafne/.labviewrc.20201123.save 

Data: 28/10/2020 

Oggetto: Plot dei rawData su dafne.lnf.infn.it non visibile con errre 

ID: 20201028.1 

La console Force dante002 non risponde più sulla seriale anche se risponde in ssh. 
Si tenta un reboot da ssh ma la macchina non risale (probabilmente è caduta a prompt ok). 
Si fa un reset fisico sulla Force (fatto da Giampiero) che riparte. La seriale torna a funzionare. 

 
ATTENZIONE: inaspettatamente, insieme alla dante002  si riavvia anche la dante004 (da investigare se c'è un errore di configurazione di ponticelli o di qualche parametro in vram che causano il riavvio su sysreset. Da notare che le altre Force NON si sono riavviate). 

Data: 02/05/2020 

Oggetto: modificato DEVIL205 (per utilizzo con il nuovo DCT Agilent Ethernet) 

ID: 20200502.1 

Autore: A.SAutore: P.C. 

Descrizione:  

Dal vuoto si segnala che alla url http://dafne.lnf.infn.it/cgi-bin/rawData quando si prova a “plottare” un elemento appare un errore. 

Dopo diagnosi, si è scoperto che la cartella /space/daq/www/scratch era dell’utente daq e del gruppo dcs, mentre il web server gira come nobody:nobody. Di conseguenza, la pagina web che chiamava lo script /space/daq/www/cgi-bin/generateJPEG dava errore perché questo script provava a salvare l’immagine generata nella cartella scratch ma non ne aveva i permessi. 

La cartella è stata reimpostata a nobody:nobody con permessi in rwx per tutti gli utenti e la pagina non ha più avuto problemi. 

Modificato DEVIL205 (DDDCtrl, InitHWICM, ICMCtrl) come segue: 

I VIs .../DCT/console/readCurrent e readCurrentFast (identici fra loro) che leggono il DCT con voltmetro HP (VME) 

sono stati sostituiti dal VI .../DCT/console/memcached/readCurrent_mc.vi che legge il volmetro Agilent (ETH). 

NOTA: il VI readCurrent_mc.vi viene inizializzato due volte: nella InitHWICM e nel frame di init della DDDCtrl. Questo non crea alcun problema perchè la modalità "init" del VI non fa altro che recuperare il mcConnectionID dalla globale e quindi non interferisce con le altre istanze del VI che eventualmente stanno già girando in modalità "run". 

Data: 3025/0604/2020 

Oggetto: modifica a IPTable.DBFilemodificato file di configurazione del DUMPER /u2/dcs/prefs/DMP/serverConfigFile.conf 

ID: 2020063020200425.1 

Autore: A.S. 

Descrizione:  

Inserito DEVIL671 nel Nel file IPTable.DBFile per test alimentatori BTF2. Documentazione su Confluence aggiornataserverConfigFile.conf, gli elementi DCTEL001 e DCTPS001 sono stati cambiati con DCTEL002 e DCTPS002 per far pervenire sul file fast.stat i dati relativi al nuovo DEVIL eth che controlla i nuovi DCT Ethernet Agilent dei monitor di corrente degli anelli. 

Data: 0526/0502/2020 

Oggetto: http://dafne.lnf.infn.it/cgi-bin/rawData modificato per visualizzare dati di vecchi elementi non in lineamodificato file di configurazione del DUMPER /u2/dcs/prefs/DMP/serverConfigFile.conf 

ID: 2020050520200226.21 

Autore: PA.CS. 

Descrizione:  

La pagina http://dafne.lnf.infn.it/cgi-bin/rawData (user: dafne, pass: 1033lumi) permette di interrogare i dati raw del sistema di controllo di dafne. Il problema è che se un elemento ha cambiato nome durante la sua vita e lo si cerca con il nome nuovo, i vecchi dati non si visualizzano più. E’ stata realizzata una patch per permettere di vedere anche i vecchi dati dei tre elementi che hanno cambiato nome: 
 

• DCTEL001 rinominato in DCTEL002 dal 25/04/2020 (ticket ID: 20200425.1); 
• DCTPS001 rinominato in DCTPS002 dal 25/04/2020 (ticket ID: 20200425.1);
• RDS42001 rinominato in RDS42002 dal 26/02/2020 (ticket ID: 20200226.1); 

 
Di conseguenza, se si cerca uno di questi elementi nuovi per una data antecedente al loro essere rinominati, la pagina si occupa di cercare il vecchio nome al posto del nuovo. 
 

ATTENZIONE: Se non si utilizza la pagina ma si modifica a mano la URL per avere dati più velocemente, ricordarsi che la patch permette di cercare i nomi nuovi per date antecedenti alla modifica del nome, ma se si cerca con il nome vecchio per date successive al cambio del nome, lo script non fa nulla e di conseguenza non si otterranno dati. 

Data: 05/05/2020 

Oggetto: dante002 riavviata 

Nel file serverConfigFile.conf, l'elemento RDS42001 è stato cambiato in RDS42002 per far pervenire sul file fast.stat i dati relativi al nuovo DEVIL eth che controlla il generatore di frequenza. 

Data: 21/01/2020 

Oggetto: Cambio permessi su shares NFS 

ID: 20200121.1 

Autore: P.C. 

Descrizione: 

Sono stati cambiati i permessi sulle shares NFS da gruppo wheel a gruppo dcs (presente su tutti gli host: target solaris, vmic, macchine virtuali, sun ray server e server con servizi). 

Monitorare come va il sistema di controllo. 

Data: 20/01/2020 

Oggetto: Sostituzione dafneswitch con moxa in sala strumentazione per seriali target solaris 

ID: 20200120ID: 20200505.1 

Autore: P.C. 

Descrizione:  

La console Force dante002 non risponde più sulla seriale anche se risponde in ssh. 
Si tenta un reboot da ssh ma la macchina non risale (probabilmente è caduta a prompt ok). 
Si fa un reset fisico sulla Force (fatto da Giampiero) che riparte. La seriale torna a funzionare. 

 
ATTENZIONE: inaspettatamente, insieme alla dante002  si riavvia anche la dante004 (da investigare se c'è un errore di configurazione di ponticelli o di qualche parametro in vram che causano il riavvio su sysreset. Da notare che le altre Force NON si sono riavviate). 

Data: 02/05/2020 

Oggetto: modificato DEVIL205 (per utilizzo con il nuovo DCT Agilent Ethernet) 

ID: 20200502.1 

Autore: A.S. 

Descrizione:  

Modificato DEVIL205 (DDDCtrl, InitHWICM, ICMCtrl) come segue: 

I VIs .../DCT/console/readCurrent e readCurrentFast (identici fra loro) che leggono il DCT con voltmetro HP (VME) 

sono stati sostituiti dal VI .../DCT/console/memcached/readCurrent_mc.vi che legge il volmetro Agilent (ETH). 

NOTA: il VI readCurrent_mc.vi viene inizializzato due volte: nella InitHWICM e nel frame di init della DDDCtrl. Questo non crea alcun problema perchè la modalità "init" del VI non fa altro che recuperare il mcConnectionID dalla globale e quindi non interferisce con le altre istanze del VI che eventualmente stanno già girando in modalità "run". 

Data: 25/04/2020 

Oggetto: modificato file di configurazione del DUMPER /u2/dcs/prefs/DMP/serverConfigFile.conf 

Visto che ogni volta c’era un problema di accesso al dafneswitch via rete, si è deciso di sostituire il CMS con un moxa da 8 porte in sala strumentazione. Il moxa è stato configurato sul NUC in sala controllo (dove gira caronte) ed è stata creata la pagina wiki per illustrare come connettersi alle force: 

http://wiki.infn.it/strutture/lnf/da/dafne/sistema_di_controllo/sviluppatori/forceconsole 

NOTE Hardware: Sono stati realizzati dei cavetti da RJ45 a RS-232 con RX e TX invertiti (per parlare con le force). Sono connessi sulle porte 3-7 del moxa in questione ed hanno sopra di loro una scritta con pennarello ROSSO. Solo uno di questi connettori, connesso alla porta 2, ha una scritta di colore BLU (Moxa RS232): questo non inverte i segnali di RX e TX (è dritto). Difatti è connesso con un secondo cavetto che converte una DB9 ad una DB25 ed inverte RX e TX, ed è connesso alla dante002. 

Data: 09/10/2019 

Oggetto: Connettore seriale su DHRTT001 sembra inaffidabile 

ID: 20191009.1 

Autore: P.C. 

Descrizione:  

Viene segnalato che il connettore seriale del cavo che arriva al DHRTT001 (Sala Modulatori) è lento e provoca falsi contatti. Valutare se da sostituire o comunque da tenere d’occhio. 

Data: 27/09/2019 

Oggetto: VNC display del DEVIL675 nero e DEVIL dead 

ID: 20190927ID: 20200425.1 

Autore: A.S. 

Descrizione:  

Nel file serverConfigFile.conf, gli elementi DCTEL001 e DCTPS001 sono stati cambiati con DCTEL002 e DCTPS002 per far pervenire sul file fast.stat i dati relativi al nuovo DEVIL eth che controlla i nuovi DCT Ethernet Agilent dei monitor di corrente degli anelli. 

Data: 26/02/2020 

Oggetto: modificato file di configurazione del DUMPER /u2/dcs/prefs/DMP/serverConfigFile.conf 

ID: 20200226.1 

Autore: A.S. 

Descrizione:  

Nel file serverConfigFile.conf, l'elemento RDS42001 è stato cambiato in RDS42002 per far pervenire sul file fast.stat i dati relativi al nuovo DEVIL eth che controlla il generatore di frequenza. 

DEVIL 675 - Virtual machine 032 - VNC display 75 

• kill -9 <PID dell'XVnc del DEVIL675> 
• restart del DEVIL675 

Si riportano a seguito i comandi utili per una diagnosi (da eseguire sulla vm interessata): 

$ more /home/dafne/.vnc/vldantedev032:75.log 

$ ls -l /tmp/.X11-unix il display X75 non compare 

$ vncserver -list il display :75 non compare 

$ ps -fe | grep labview il LabVIEW con -display vldantedev032:75 non compare 

$ ps -fe | grep Xvnc il processo XVnc :75 e DEVIL675 compare! 

Data: 2117/0107/20202019 

Oggetto: Cambio permessi su shares NFS Modifica script per avvio/reset VNC per devil serie 7 

ID: 2020012120190717.1 

Autore: P.C. 

Descrizione: 

Per abilitare l’utilizzo dei devil serie 7, si è resa necessaria la modifica degli script per il calcolo del display VNC. Sono stati cambiati i permessi sulle shares NFS da gruppo wheel a gruppo dcs (presente su tutti gli host: target solaris, vmic, macchine virtuali, sun ray server e server con servizi). 

Monitorare come va il sistema di controllo. 

Data: 20/01/2020 

Oggetto: Sostituzione dafneswitch con moxa in sala strumentazione per seriali target solaris 

ID: 20200120.1 

Autore: P.C. 

Descrizione: 

Visto che ogni volta c’era un problema di accesso al dafneswitch via rete, si è deciso di sostituire il CMS con un moxa da 8 porte in sala strumentazione. Il moxa è stato configurato sul NUC in sala controllo (dove gira caronte) ed è stata creata la pagina wiki per illustrare come connettersi alle force: 

http://wiki.infn.it/strutture/lnf/da/dafne/sistema_di_controllo/sviluppatori/forceconsole 

NOTE Hardware: Sono stati realizzati dei cavetti da RJ45 a RS-232 con RX e TX invertiti (per parlare con le force). Sono connessi sulle porte 3-7 del moxa in questione ed hanno sopra di loro una scritta con pennarello ROSSO. Solo uno di questi connettori, connesso alla porta 2, ha una scritta di colore BLU (Moxa RS232): questo non inverte i segnali di RX e TX (è dritto). Difatti è connesso con un secondo cavetto che converte una DB9 ad una DB25 ed inverte RX e TX, ed è connesso alla dante002. 

Data: 09/10/2019 

Oggetto: Connettore seriale su DHRTT001 sembra inaffidabile 

ID: 20191009.1 

Autore: P.C. 

Descrizione:  

Viene segnalato che il connettore seriale del cavo che arriva al DHRTT001 (Sala Modulatori) è lento e provoca falsi contatti. Valutare se da sostituire o comunque da tenere d’occhio. 

Data: 27/09/2019 

Oggetto: VNC display del DEVIL675 nero e DEVIL dead 

ID: 20190927.1 

Autore: A.S. 

Descrizione: 

DEVIL 675 - Virtual machine 032 - VNC display 75 

• kill -9 <PID dell'XVnc del DEVIL675> 
• restart del DEVIL675 

Si riportano a seguito i comandi utili per una diagnosi (da eseguire sulla vm interessata): 

$ more /home/dafne/.vnc/vldantedev032:75.log 

$ ls -l /tmp/.X11-unix il display X75 non compare 

$ vncserver -list il display :75 non compare 

$ ps -fe | grep labview il LabVIEW con -display vldantedev032:75 non compare 

$ ps -fe | grep Xvnc il processo XVnc :75 e DEVIL675 compare! 

Data: 17/07/2019 

Oggetto: Modifica script per avvio/reset VNC per devil serie 7 

ID: 20190717.1 

Autore: P.C. 

Descrizione: 

Per abilitare l’utilizzo dei devil serie 7, si è resa necessaria la modifica degli script per il calcolo del display VNC. Sono stati modificati i seguenti files: 

• /u2/dcs/script_linux/devil_mngr.sh per aggiungere il parametro -name DEVIL$devil_number all'avvio del display VNC; Così facendo, la finestra VNC mostra il nome del devil e lanciando il comando ps -fe | grep Xvnc si possono vedere quali devil girano su quali display; 
• /var/www/html/devil_manager/index.php su danteweb per calcolare il display VNC come resto della divisione intera per 100 del numero del devil (così funziona anche per i devil della serie 7, 8, etc.) 

NOTA: Ci sono altri controlli sul numero del devil: ad oggi vengono accettati devil della serie 6 e 7! Nel caso si volessero aggiungere altre serie di devil, riaprire lo script /u2/dcs/script_linux/devil_mngr.sh ed aggiungere le nuove serie nei controlli sul numero del devil; 

Data: 03/04/2019 

Oggetto: configurazione porte switches vLAN Apple 

ID: 20190403.3 

Autore: A.S. 

Descrizione: 

Le porte degli switches dove sono connessi tutti i devils Apple non avevano più la configurazione per: 10 Mbps, no autonegotiation, half-duplex. Pensiamo che questo possa essere la causa del problema di perdita di connessione dei devils Apple e di Caron (AKA Console100) dal server Bible che stiamo sperimentando ultimamente (forse da quando Spigone ha riconfigurato gli switches del controllo). 

Richiesta riconfigurazione delle porte degli switches che sono configurati per avere dei devil connessi su di loro: 

SWDAFNE4B Porte 11-16 

SWDAFNE2C Porta 48 

SWDAFNE1 Porta 44 

SWALIMDAFNE Porte 7-12 

SWMACC Porte 7-10 

SWMOD1 Porte 7-10 

SWBTF Porte 9-10 

Data: 03/04/2019 

Oggetto: Problema riavvio CPU force e DAFNE dovute a server NFS krunc spento 

ID: 20190403.2 

Autore: P.C. 

Descrizione: 

Dopo un blackout, le FORCE non ripartivano. Rimanevano bloccate con il messaggio di errore: 

Setting default IPv4 interface for multicast:add net 224.0/4: gateway dante00[2-7] 

Il problema era dovuto al fatto che nel file /etc/vfstab dei vari target veniva montato il seguente path via NFS: 

krunc:/runcond/slow/global /u2/kloe 

ed il server krunc non è più raggiungibile (KLOE Spento). Di conseguenza la sequenza di boot si fermava in attesa della risorsa NFS. 

Commentando quella riga, le force sono ripartite senza problemi. 

Per sicurezza, anche sul server DAFNE le righe relative ai mount dei folder da kloe sono state commentate ed è stato effettuato un umount delle stesse: 

krunc:/runcond/slow/global /kloe 

krunc:/runcond/slow/curr/stat /kloenano 

krunc:/runcond/slow/trg /kloelumi 

NOTA: Mentre si debuggava l’errore del boot, abbiamo notato un messaggio di errore nella configurazione della porta ethernet dei target. Si è provveduto a modificare i files di configurazione dei target come riportato nella tabella seguente (nel file della prima scheda era presente solo il nome del target, mentre ci doveva essere l’IP seguito dalla netmask). Ora i target si avviano senza messaggi di  errore per quanto riguarda la parte ethernet. 

Data: 03/04/2019 

Oggetto: Lextel 23 spenta 

ID: 20190403.1 

Autore: A.S. 

Descrizione: 

In uno dei crate VME di livello 2, è presente la Lextel 23 spenta. Questa era utilizzata dall'ex devil Apple 361 che gestiva le flags. Adesso le Flags sono gestite dal DEVIL661 che gira su VMIC. La Lextel è una ottica "pura" e quindi non da problemi di rumore se la compagna a livello 3 è spenta e non manda il carrier. Si può togliere. 

Data: 26/03/2019 

Oggetto: QUATM002, QUATM003 intervento definitivo per ripetuti problemi di fuori comunicazione 

ID: 20190326.1 

Autore: A.S. 

Descrizione: 

Riguardo la problematica del 10/04/2017 e del 12/11/2015 descritta nel ticket ID: 20151112.1 

Si sostituisce il monchino+DB9 sulla porta 5 dl MOXA .40 

Si testa muovendo i connettori mentre si osserva sul posto il driver di comunicazione: connessione stabile. 

Data: 19/03/2019 

Oggetto: Modifiche DBFile per ripartenza marzo 2019 

ID: 20190319.1 

Autore: A.S. 

DEVIL 646 

rimossi quadrupoli skew QSKPL107, QSKPS100 e sostituiti con canali DUMMY011, DUMMY012 in bypass 

Le altre back-leg erano messe in local su DBFile: rimesse in remote. 

DEVIL 640 

rimossi quadrupoli skew QSKES100, QSKEL107 e sostituiti con canali DUMMY010, DUMMY013 in bypass 

Le altre back-leg erano messe in local su DBFile: rimesse in remote. 

Create le directories 

AAA_OLD_DEVIL640_20190311 

AAA_OLD_DEVIL646_20190311 

e copiatici dentro i DBFiles di prima della modifica 

Rimossi da 

modificati i seguenti files: 

• /u2/dcs/script_linux/devil_mngr.sh per aggiungere il parametro -name DEVIL$devil_number all'avvio del display VNC; Così facendo, la finestra VNC mostra il nome del devil e lanciando il comando ps -fe | grep Xvnc si possono vedere quali devil girano su quali display; 
• /var/www/html/devil_manager/index.php su danteweb per calcolare il display VNC come resto della divisione intera per 100 del numero del devil (così funziona anche per i devil della serie 7, 8, etc.) 

NOTA: Ci sono altri controlli sul numero del devil: ad oggi vengono accettati devil della serie 6 e 7! Nel caso si volessero aggiungere altre serie di devil, riaprire lo script /u2/dcs/script_linux/devil_mngr.sh ed aggiungere le nuove serie nei controlli sul numero del devil; 

Data: 03/04/2019 

Oggetto: configurazione porte switches vLAN Apple 

ID: 20190403.3 

Autore: A.S. 

Descrizione: 

Le porte degli switches dove sono connessi tutti i devils Apple non avevano più la configurazione per: 10 Mbps, no autonegotiation, half-duplex. Pensiamo che questo possa essere la causa del problema di perdita di connessione dei devils Apple e di Caron (AKA Console100) dal server Bible che stiamo sperimentando ultimamente (forse da quando Spigone ha riconfigurato gli switches del controllo). 

Richiesta riconfigurazione delle porte degli switches che sono configurati per avere dei devil connessi su di loro: 

SWDAFNE4B Porte 11-16 

SWDAFNE2C Porta 48 

SWDAFNE1 Porta 44 

SWALIMDAFNE Porte 7-12 

SWMACC Porte 7-10 

SWMOD1 Porte 7-10 

SWBTF Porte 9-10 

Data: 03/04/2019 

Oggetto: Problema riavvio CPU force e DAFNE dovute a server NFS krunc spento 

ID: 20190403.2 

Autore: P.C. 

Descrizione: 

Dopo un blackout, le FORCE non ripartivano. Rimanevano bloccate con il messaggio di errore: 

Setting default IPv4 interface for multicast:add net 224.0/4: gateway dante00[2-7] 

Il problema era dovuto al fatto che nel file /etc/vfstab dei vari target veniva montato il seguente path via NFS: 

krunc:/runcond/slow/global /u2/kloe 

ed il server krunc non è più raggiungibile (KLOE Spento). Di conseguenza la sequenza di boot si fermava in attesa della risorsa NFS. 

Commentando quella riga, le force sono ripartite senza problemi. 

Per sicurezza, anche sul server DAFNE le righe relative ai mount dei folder da kloe sono state commentate ed è stato effettuato un umount delle stesse: 

krunc:/runcond/slow/global /kloe 

krunc:/runcond/slow/curr/stat /kloenano 

krunc:/runcond/slow/trg /kloelumi 

NOTA: Mentre si debuggava l’errore del boot, abbiamo notato un messaggio di errore nella configurazione della porta ethernet dei target. Si è provveduto a modificare i files di configurazione dei target come riportato nella tabella seguente (nel file della prima scheda era presente solo il nome del target, mentre ci doveva essere l’IP seguito dalla netmask). Ora i target si avviano senza messaggi di  errore per quanto riguarda la parte ethernet. 

Data: 03/04/2019 

Oggetto: Lextel 23 spenta 

ID: 20190403.1 

Autore: A.S. 

Descrizione: 

In uno dei crate VME di livello 2, è presente la Lextel 23 spenta. Questa era utilizzata dall'ex devil Apple 361 che gestiva le flags. Adesso le Flags sono gestite dal DEVIL661 che gira su VMIC. La Lextel è una ottica "pura" e quindi non da problemi di rumore se la compagna a livello 3 è spenta e non manda il carrier. Si può togliere. 

Data: 26/03/2019 

Oggetto: QUATM002, QUATM003 intervento definitivo per ripetuti problemi di fuori comunicazione 

ID: 20190326.1 

Autore: A.S. 

Descrizione: 

Riguardo la problematica del 10/04/2017 e del 12/11/2015 descritta nel ticket ID: 20151112.1 

Si sostituisce il monchino+DB9 sulla porta 5 dl MOXA .40 

Si testa muovendo i connettori mentre si osserva sul posto il driver di comunicazione: connessione stabile. 

Data: 19/03/2019 

Oggetto: Modifiche DBFile per ripartenza marzo 2019 

ID: 20190319.1 

Autore: A.S. 

 DEVIL 646 

rimossi quadrupoli skew QSKPL107, QSKPS100 e sostituiti con canali DUMMY011, DUMMY012 in bypass 

Le altre back-leg erano messe in local su DBFile: rimesse in remote. 

 DEVIL 640 

rimossi quadrupoli skew QSKES100, QSKEL107 e sostituiti con canali DUMMY010, DUMMY013 in bypass 

Le altre back-leg erano messe in local su DBFile: rimesse in remote. 

 Create le directories 

AAA_OLD_DEVIL640_20190311 

AAA_OLD_DEVIL646_20190311 

e copiatici dentro i DBFiles di prima della modifica 

 Rimossi da 

/u2/dcs/space/uniDatabase/elementaryAreas/MRe/MRe_quadrupoles_skew.cnf 

/u2/dcs/space/uniDatabase/saveAreas/MRe/MRe_quadrupoles_skew.cnf 

/u2/dcs/space/uniDatabase/functionalAreas/MRe/MRe_quadrupoles_skew.cnf 

QSKES100 

QSKEL107 

/u2/dcs/space/uniDatabase/elementaryAreas/MRp/MRp_quadrupoles_skew.cnf 

/u2/dcs/space/uniDatabase/saveAreas/MRp/MRp_quadrupoles_skew.cnf 

/u2/dcs/space/uniDatabase/functionalAreas/MRp/MRp_quadrupoles_skew.cnf 

QSKPL107 

QSKPS100 

Nuovi correttori MRs 

Rimossi DEVILs 

636 

637 

643 

645 

Rimpiazzati da 664 e 665 

Rimosse le seguenti Main Units 

(nella finestra MRCorrectorsMainUnit, rimangono solo le due SIM che pilotano le back-legs) 

SIMEL101, SIMES101, SIMES102, SIMPL201, SIMPS101, SIMEL201, SIMPL202, SIMPS201 

DEVIL602 

Create directory 

AAA_OLD_DEVIL602_20190318 

e copiatici dentro i DBFiles di prima della modifica 

Modificati files DBSta e DBDyn: rimessi in linea QUAI1023 (Add 00) e QUAI1014 (Add 07). 

Aggiunti QUAI1023 e QUAI1014 in 

/u2/dcs/space/uniDatabase/elementaryAreas/IR/IR_quadrupoles.cnf 

/u2/dcs/space/uniDatabase/functionalAreas/IR/IR_quadrupoles.cnf 

/u2/dcs/space/uniDatabase/saveAreas/MRe/MRe_quadrupoles.cnf 

/u2/dcs/space/uniDatabase/saveAreas/MRp/MRp_quadrupoles.cnf 

DEVIL619 

MRe 

MRe_correctors_C_Lamb 

Creata directory: 

AAA_OLD_DEVIL619_20190319 

e copiatici dentro i DBFiles dei DEVIL 619 di prima della modifica. 

 /u2/dcs/space/uniDatabase/elementaryAreas/ MReMRp/MReMRp_correctors_quadrupolesC_skewLamb.cnf 

/u2/dcs/space/uniDatabase/saveAreasfunctionalAreas/MReMRp/MReMRp_correctors_quadrupolesC_skewLamb.cnf 

/u2/dcs/space/uniDatabase/functionalAreassaveAreas/MReMRp/MReMRp_correctors_quadrupolesC_skewLamb.cnf 

QSKES100CDVPS101 

QSKEL107CDVPS201 

CDVPL101 

CDVPL201 

/u2/dcs/space/uniDatabase/elementaryAreas/MRp/MRp_quadrupoles_skew.cnf 

/u2/dcs/space/uniDatabase/saveAreas/MRp/MRp_quadrupoles_skew.cnf 

/u2/dcs/space/uniDatabase/functionalAreas/MRp/MRp_quadrupoles_skew.cnf 

QSKPL107 

QSKPS100 

Nuovi correttori MRs 

Rimossi DEVILs 

636 

637 

643 

645 

Rimpiazzati da 664 e 665 

Rimosse le seguenti Main Units 

(nella finestra MRCorrectorsMainUnit, rimangono solo le due SIM che pilotano le back-legs) 

SIMEL101, SIMES101, SIMES102, SIMPL201, SIMPS101, SIMEL201, SIMPL202, SIMPS201 

DEVIL602 

CDHPS101 

CDHPS201 

CDHPL101 

CDHPL201 

CVVPI201 

CVVPI102 

CVVPI202 

CVVPI101 

CHHPI201 

CHHPI102 

CHHPI202 

CHHPI101 

DEVIL618 

MRe 

MRe_correctors_C_Lamb 

Creata directory:Create directory 

AAA_OLD_DEVIL602DEVIL618_2019031820190319 

e copiatici dentro i DBFiles dei DEVIL 618 di prima della modifica. 

Modificati files DBSta e DBDyn: rimessi in linea QUAI1023 (Add 00) e QUAI1014 (Add 07). 

Aggiunti QUAI1023 e QUAI1014 in 

/u2/dcs/space/uniDatabase/elementaryAreas/IR/IR_quadrupolesMRe/MRe_correctors_C_Lamb.cnf 

/u2/dcs/space/uniDatabase/functionalAreas/IR/IR_quadrupolesMRe/MRe_correctors_C_Lamb.cnf 

/u2/dcs/space/uniDatabase/saveAreas/MRe/MRe_quadrupolescorrectors_C_Lamb.cnf /u2/dcs/space/uniDatabase/saveAreas/MRp/MRp_quadrupoles.cnf

CDVES101 

CDVES201  

CDVEL101  

DEVIL619CDVEL201 

MReCDHES101 MRe_correctors_C_Lamb

CDHES201 

CDHEL101  

...

CDHEL201 

...

CVVEI201 

...

CVVEI102 

...

CVVEI202 

...

CVVEI101 

...

CHHEI201 

...

CHHEI102 

...

CHHEI202 

...

CHHEI101 

...

Data: 07/02/2019  

Creata directory: 

AAA_OLD_DEVIL619_20190319 

e copiatici dentro i DBFiles dei DEVIL 619 di prima della modifica. 

/u2/dcs/space/uniDatabase/elementaryAreas/ MRp/MRp_correctors_C_Lamb.cnf 

/u2/dcs/space/uniDatabase/functionalAreas/MRp/MRp_correctors_C_Lamb.cnf 

/u2/dcs/space/uniDatabase/saveAreas/MRp/MRp_correctors_C_Lamb.cnf 

CDVPS101 

CDVPS201 

CDVPL101 

CDVPL201 

CDHPS101 

CDHPS201 

CDHPL101 

CDHPL201 

CVVPI201 

CVVPI102 

CVVPI202 

CVVPI101 

CHHPI201 

CHHPI102 

CHHPI202 

CHHPI101 

DEVIL618 

MRe 

MRe_correctors_C_Lamb 

Creata directory: 

AAA_OLD_DEVIL618_20190319 

e copiatici dentro i DBFiles dei DEVIL 618 di prima della modifica. 

/u2/dcs/space/uniDatabase/elementaryAreas/MRe/MRe_correctors_C_Lamb.cnf 

/u2/dcs/space/uniDatabase/functionalAreas/MRe/MRe_correctors_C_Lamb.cnf 

/u2/dcs/space/uniDatabase/saveAreas/MRe/MRe_correctors_C_Lamb.cnf 

CDVES101 

CDVES201 

CDVEL101 

CDVEL201 

CDHES101 

CDHES201 

CDHEL101 

CDHEL201 

CVVEI201 

CVVEI102 

CVVEI202 

CVVEI101 

CHHEI201 

CHHEI102 

CHHEI202 

CHHEI101 

Data: 07/02/2019 

Oggetto: Nuova versione finestra Odoscopio.vi (da 1.94 a 1.95) 

ID: 20190207.1 

Autore: P.C. 

Oggetto: Nuova versione finestra Odoscopio.vi (da 1.94 a 1.95) 

ID: 20190207.1 

Autore: P.C. 

Descrizione: 

A seguito di più ticket aperti dalla sala controllo si interviene per valutare il malfunzionamento della finestra. 

...

Resta da verificare la corretta calibrazione della finestra (calcolata su di una macchina a 500 MeV mentre ora è ben al di sopra per PADME) che si farà in seguito con Foggetta e Di Giulio.  

Data: 22/01/2019 

Oggetto: Installazione VIPM e modulo MODBUS su VMs del controllo 

...

LabVIEW 2015: vldantedev701 (192.168.198.210) - vldantedev702 (192.168.198.211)  

Data: 09/11/2018 

Oggetto: QUATM002, QUATM003 fuori comunicazione 

...

Si ri-confermana quindi la precarietà del "monchino" o del connettore del cavo seriale lato MOXA (falsi contatti o crimpatura difettosa). CONTROLLARE connettore e SOSTITUIRE monchino. 

Data: 04/12/2017 

Oggetto: file fast.stat generato dal DUMPER malformato 

...

smb://nasda.lnf.infn.it/control/docs/2_purgatory/Dumper/dumper\ ConfigFile\ analisi.docx 

Data: 25/05/2017 

Oggetto: situazione installazione versione newOCEM_x.x alla data attuale 

...

Dopo due riavvii ha funzionato tutto correttamente… restano i dubbi sul perché si sia comportato così, visto che sulla stessa macchina c’era in run un altro devil che andava sullo stesso MOXA e funzionava correttamente, sia prima che dopo i riavvii.  

Data: 25/05/2017 

Oggetto: situazione installazione versione newOCEM_x.x alla data attuale 

...

Data: 16/05/2017 

Oggetto: fermata di maggio - fase 2 lavori cablaggio alimentatori OCEM 

...

Data: 16/05/2017 

Oggetto: fermata di maggio - calendario 

...

Data: 14/04/2017 

Oggetto: Connessione difettosa alimentatore OCEM 

...

Messi VI _newOCEM in DEVIL697. Nessun errore di comunicazione/protocollo nel periodo osservato (~ 30'). 

Modalità seriale: native  

Data: 10/04/2017 

Oggetto: connessione difettosa alimentatore OCEM 

...

Il cavo difettoso è quello del nuovo cablaggio singolo alimentatore.  

Data: 10/04/2017 

Oggetto: QUATM002, QUATM003 fuori comunicazione 

...

Si confermano quindi i dubbi sul "monchino" o sul connettore del cavo seriale lato MOXA (falsi contatti o crimpatura difettosa). SOSTITUIRE connettore e monchino. 

Data: 21/03/2017 

Oggetto: Nuovo cablaggio alimentatori in sala modulatori 

...

Creato script eseguibile “switch_chaos_dafne.sh” dentro /u2/dcs/db/DBFiles_3/CPU_LINUX_eth/ che cambia le configurazioni tra chaos e dafne (sia come DBFile che come IPTable) 

Data: 12/01/2017 

Oggetto: sostituzione DEVIL361 con DEVIL661 

...

Prossimo step (dopo collaudo e uso senza problemi del nuovo sistema FATTO ): rimozione DEVIL Apple, lextel da livello 3 e 2, riconfigurazione del sysreset-VMICReset per funzionare come unico processore sul bus.  

Data: 07/12/2016 

Oggetto:  

...

E' stato rimpiazzato da due MOXA 8 porte (192.168.192.33 per QSK elettroni e 192.168.192.34 per QSK positroni). Aggiornato file di configurazione nella macchina virtuale  e documentazione Excel. 

Data: 05/12/2016 

Oggetto: Rottura moxa 16 porte ( 192.168.190.46) corretori skew e+ e- 

...

Devil 651 e 657 bloccati, entrati in sala Dafne, trovato moxa 16p spento 192.168.190.46 e non recuperabile, abbiamo sostituito HW con un moxa 16p 192.168.190.45 e rimpiazzata l’entry nel driver moxa. 

Data: 10/11/2016 

Oggetto:  

...

Dato che gli errori si verificano su tutti, il problema sembra essere sul MOXA o sul cavo o sullo SWITCH 

Data: 24/10/2016 

Oggetto:  

...

currRead,0.004273,0.0,0.0,280.0,0.5 (era 0.1),1.0 (era 0.5)  

Data: 24/10/2016 

Oggetto: Controllo magneti OCEM lento - DEVIL625 

...

La situazione è migliorata apprezzabilmente anche se ,nel caso più comandi arrivino sullo stesso DEVIL, i contextual checks causano sempre un rallentamento della control.  

Data: 14/09/2016 

Oggetto: Problema con SCHES101_INT - non riesce ad andare in OPER 

...

1. Problema gia verificato in data 04/11/2014.

...

Data: 13/09/2016 

Oggetto: Corruzione firmware NI-cDAQ-918X 

...

# NOTA: Non è mai stato eseguito hard-reset del cDAQ che in parte può spiegare il comportamento inusuale del device sulla rete  

Data: 12/09/2016 

Oggetto: Bug di Caronte 

...

Soluzione temporanea: riavviare Caronte con il VI di inizializzazione aperto e con breakpoint; Alla chiamata del VI di init, quando entra il breakpoint, fare RUN, togliere a mano l'errore in uscita e sganciare. Attenzione: il VI di init viene chiamato due volte e l'operazione deve essere fatta entrambe le volte. Poi rimuovere il breakpoint e richiudere tutto. 

Da fissare!  

Data: 06/09/2016 

Oggetto: problema su migrazione VMs fra hosts con HW/performances diversi 

...

Facendo prove di migrazione di VM da host più performanti tipo M620 verso M610, i devil time critical, ovvero quelli che usano drivers per la comunicazione con gli alimentatori, mostrano problemi di timeout sulla comunicazione con gli alimentatori stessi. La migrazione inversa (VM da M610 -> M620) non evidenza lo stesso problema. Di fatto il problema può essere associato a come la VM calcola il proprio tempo al primo bootstrap, ereditando variabile di sistema dall’host fisico. Host diversi impongo alle VM variabili di sistema diversi quindi tempi macchina diversi che possono influenzare il timeout imposti al devil. La possibile soluzione su cluster XEN non omogenei è avere l’emulazione del VCPU conforme con tutte le CPU oppure imporre al KERNEL della VM il ricalcolo del tempo a seguito di una migrazione.  

Data: 31/08/2016 

Oggetto: modifica DBFiles DEVILs 647 e 650 

...

Al momento quindi, i links NON DEVONO essere rediretti sui DBFiles ".CHAOS". 

Data: 12/08/2016 

Oggetto:  

...

Documentazione dettagliata su nasda nel file /control/docs/3_hell/DEVIL_eth program/changelog DEVIL  

Data: 12/08/2016 

Oggetto:  

...

Documentazione dettagliata su nasda nei files control/docs/0_classes/XXX/changelog XXX  

Data: 29/06/2016 

Oggetto: Sostituita vmic dante074 con dante055 (devil 622, kicker positroni) 

...

Il DEVIL622 viene segnalato come morto. Si riavvia la VMIC dante074 con il tappo da 50ohm in sala strumentazione ma non sortisce alcun effetto. Si entra in sala e la VMIC non da segni di vita se non nel led verde del POWER ON. Si sostituisce con la dante055 (batteria cambiata e BIOS riconfigurato) e si prepara sul server beatrix il file system della VMIC nuova per lanciare i devil al suo avvio. Modificato anche l’IPtable.DBFile per associare il DEVIL622 alla vmic dante055. 

Data: 20/06/2016 

Oggetto: problema GPIB-ENET/1000 kickers lato elettroni 

...

Riavvio della vm 192.168.198.131: tutto ok, GPIB Explorer ok. 

Data: 15/06/2016 

Oggetto: problema GPIB-ENET/1000 kickers lato elettroni 

...

AGGIORNAMENTO: nell'ipotesi che  il GPIB-ENET/1000 sia colpito da radiazione proveniente dalla TL e-, è stato spostato sopra il rack.  

Data: 14/03/2016 

Oggetto: Sostituzione GPIB-ENET/1000 kickers lato elettroni 

...

Il DEVIL690 risultava bloccato sull’initHW. E’ stato riavviato più volte ma la situazione non cambiava. E’ stata riavviata anche la macchina virtuale ma continuava a non funzionare. Si è deciso di andare a vedere i 4 GPIB controllati da quel devil ed è stato trovato quello in posizione kickers elettroni con l’errore 11 (firmware danneggiato). E’ stato quindi sostituito ed è stata avviata la pratica per l’invio in riparazione di quello rimosso. E’ già la seconda volta che un oggetto di questo tipo si rompe, sempre in quella posizione (se dovesse ripresentarsi lo stesso problema conviene anche sostituire l’alimentatore del GPIB-ENET e studiarne una nuova posizione nei limiti consentiti dal cavo GPIB).  

Data: 09/11/2015 

Oggetto: errore "local error" sul crate delle LEXTEL dell'orbita 

...

Si fa un riavvio di livello 2: ok. 

Test dell'orbita: ok.  

Data: 19/11/2015 

Oggetto: down del SunRay server 

...

(1) vedi paragrafo "Particolarità del DBFile nel caso MG1 - E642". 

(2) BUG 01 - 22/10/2015: la serialConfigure, dopo i primi due elementi (subID2 = 8 e 9) rilascia tutti handlers uguali a 0. Il risultato è che da console, i comandi su un elemento viene eseguito anche su molti altri. 
Forse è un caso ma subito dopo 8 e 9 cominciano gli hex A, B, E, F, C, D... 
INOLTRE: dopo un po di debugging e un paio di stop/start, il DEVIL è crashato (come era successo durante lo sviluppo). BUG SOLVED 
 

Note sui timeouts 

Le nuove routines seriali "....._multi.vi" utilizzano 2 input di timeout: 

• uno è quello che esisteva anche sulle routine VISA e che riguarda il timeout sull'operazione di lettura (serve ad assorbire eventuali frammentazioni della risposta proveniente dal dispositivo) 
• l'altro (waitBeforeFirstRead [ms]) è un ritardo che la funzione di read osserva prima di accedere al buffer di input (serve ad assorbire eventuali latenze iniziali della risposta proveniente dal dispositivo) 

Il valore assegnato al nuovo timeout waitBeforeFirstRead viene messo nel DBSta nel campo subID1 (prima inutilizzato). 

!!! WARNING !!! il campo subID1 è interpretato come HEX e quindi il valore di timeout in millisecondi che viene scritto nel DBFile deve essere scritto come HEX. 

(1) vedi paragrafo "Particolarità del DBFile nel caso MG1 - E642". 

(2) BUG 01 - 22/10/2015: la serialConfigure, dopo i primi due elementi (subID2 = 8 e 9) rilascia tutti handlers uguali a 0. Il risultato è che da console, i comandi su un elemento viene eseguito anche su molti altri. 
Forse è un caso ma subito dopo 8 e 9 cominciano gli hex A, B, E, F, C, D... 
INOLTRE: dopo un po di debugging e un paio di stop/start, il DEVIL è crashato (come era successo durante lo sviluppo). BUG SOLVED 
 

Note sui timeouts 

Le nuove routines seriali "....._multi.vi" utilizzano 2 input di timeout: 

• uno è quello che esisteva anche sulle routine VISA e che riguarda il timeout sull'operazione di lettura (serve ad assorbire eventuali frammentazioni della risposta proveniente dal dispositivo) 
• l'altro (waitBeforeFirstRead [ms]) è un ritardo che la funzione di read osserva prima di accedere al buffer di input (serve ad assorbire eventuali latenze iniziali della risposta proveniente dal dispositivo) 

Il valore assegnato al nuovo timeout waitBeforeFirstRead viene messo nel DBSta nel campo subID1 (prima inutilizzato). 

Nel caso di un DBFile di classe MG1 - protocollo E642 (ovvero alimentatori OCEM), il file viene come nell'esempio seguente: 

• i due timeout convenzionali (read e write), nel record HCI, sono 40 ms  (tarati per OCEM) sia per VISA che per native; 
• il campo genericSerialBoardType (0 = VISA, 1 = native), evidenziato in rosso nell'esempio; 
• waitBeforeFirstRead, messo nella posizione di subID1 = 0x64 = 100 ms  (tarato per OCEM) 
  WARNING (vedi ticket 20160906.1): waitBeforeFirstRead dovrebbe essere di 40 ms ma viene tenuto a 100 perchè se si migra a caldo una vm fra due hosts con diverse prestazioni, la durata dei tickcounts non è più reale (la taratura viene fatta a boot della vm (vedi p.es. il file /proc/cpuinfo). Questo è un problema di carattere generale e vale anche per altri parametri (p.es. cache, bogomips, etc...). 

Caso native 

#SER15002 

@HCI(S)[DI32,(DBL),A32S,DU32,DU32,A32S,DU32,DU32,(DBL):6] 

1,SER15002,E02FE000,1024,40,E02FE800,1024,40,QUATE001:QUATE002:QUATP001:QUATP002:QUATP003:QUATP004 

@GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),A16M,HU32,HU32] 

1,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerChan2,E3FF4000,64,0C (subID1 indifferente nel caso VISA) 

!!! WARNING !!! il campo subID1 è interpretato come HEX e quindi il valore di timeout in millisecondi che viene scritto nel DBFile deve essere scritto come HEX. 

Particolarità del DBFile nel caso MG1 - E642Probus 

Nel caso di un DBFile di classe MG1 - protocollo E642 Probus (ovvero alimentatori OCEMper QSK), il file viene come nell'esempio seguente: 

...

seguente: 

Caso nativeVISA 

#SER15002#SER68001 

@HCI(S)[DI32,(DBL),A32SHU32,DU32,DU32,A32SHU32,DU32,DU32,(DBL):61] 

10,SER15002SER68001,E02FE000E02FF000,1024,40100,E02FE800E02FF800,1024,40,QUATE001:QUATE002:QUATP001:QUATP002:QUATP003:QUATP004100,QSKEL106 

@GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),A16MHU32,HU32,HU32] 

10,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerChan2SerCh001,E3FF4000,640,0C5 (subID1 indifferente nel caso VISA) 

Particolarità del DBFile nel caso MG1 - Probus 

Nel caso di un DBFile di classe MG1 - protocollo Probus (ovvero alimentatori per QSK), il file viene come nell'esempio seguente: 

Caso VISAnative 

#SER68001 

@HCI(S)[DI32,(DBL),HU32,DU32,DU32,HU32,DU32,DU32,(DBL):1] 

0,SER68001,E02FF000,1024,10050,E02FF800,1024,10050,QSKEL106QSKPS101 

@GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),HU32,HU32,HU32] 

01,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerCh001,E3FF4000,0,5 (subID1 indifferente nel caso VISA) 

Caso native 

#SER68001 

@HCI(S)[DI32,(DBL),HU32,DU32,DU32,HU32,DU32,DU32,(DBL):1] 

0,SER68001,E02FF000,1024,50,E02FF800,1024,50,QSKPS101 

@GSC(S)[DU16,DI32,DU16,DU16,DU16,DU16,TF,TF,HU16,HU16,TF,TF,TF,TF,HU16,HU16,HU16,HU16,HU16,(DBL),HU32,HU32,HU32] 

1,9600,8,0,0,1024,0,0,0,0,0,0,0,0,0,0,0,0,0,SerCh001,E3FF4000,50,5 (subID1 = 50 nel caso native) 

Data: 18/05/2015 

Oggetto: messa in produzione la switchDAFNE_COMBO.vi ver 3.3 

ID: 20150518.1 

Autore: A.S. & P.C. 

Descrizione:  

Dopo un week-end di utilizzo senza problemi, è stata messa in produzione la versione 3.3, build 20150511-1540 del programma switchDAFNE_COMBO.vi. 

La versione che è stata in run sino ad oggi è la 3.22, build 20141201-1433 

Data: 23/03/2015 

Oggetto: Ripristino linea seriale BTF (post Test CHAOS) 

ID:20150323 

Autore: F.G., P.C. 

Descrizione: Ripristinata linea seriale BTF (Test CHAOS -> Dafne); trovati connettori seriali con torrette lente (girano a vuoto le femmine) e non tutte le viti prendono nel modo corretto, determinando un’inaffidabilita’ e stabilita’ del connettore stesso (suggerisco di fare spezzoni di adattamento con viti lunghe per corretto serraggio e affidabilita’ della connessione). 

ATTENZIONE: Etichettatura, relativa alla vecchia linea seriale dipolo BTF, insufficiente (potrebbe indurre in errore). 

,0,SerCh001,E3FF4000,50,5 (subID1 = 50 nel caso native) 

Data: 18/05/2015 

Oggetto: messa in produzione la switchDAFNE_COMBO.vi ver 3.3 

ID: 20150518.1 

Autore: A.S. & P.C. 

Descrizione:  

Dopo un week-end di utilizzo senza problemi, è stata messa in produzione la versione 3.3, build 20150511-1540 del programma switchDAFNE_COMBO.vi. 

La versione che è stata in run sino ad oggi è la 3.22, build 20141201-1433 

Data: 23/03/2015 

Oggetto: Ripristino linea seriale BTF (post Test CHAOS) 

ID:20150323 

Autore: F.G., P.C. 

Descrizione: Ripristinata linea seriale BTF (Test CHAOS -> Dafne); trovati connettori seriali con torrette lente (girano a vuoto le femmine) e non tutte le viti prendono nel modo corretto, determinando un’inaffidabilita’ e stabilita’ del connettore stesso (suggerisco di fare spezzoni di adattamento con viti lunghe per corretto serraggio e affidabilita’ della connessione). 

ATTENZIONE: Etichettatura, relativa alla vecchia linea seriale dipolo BTF, insufficiente (potrebbe indurre in errore). 

Data: 17/03/2015 

Oggetto: Ripetute perdite di connessione con sistemi CompactDAQ della RF

ID:20150317

Autore: A.S., R.G.

Our setup (see fig. 1) consists of three CompactDAQ crates connected to a dedicated VLan and controlled by a LabVIEW 2012 program running on a Windows computer, which is connected to the same VLan.

Image Added

Fig. 1 - CompactDAQ crates connection layout

With this setup, we are suffering frequent connection drops between the Windows computer and the CompactDAQ modules (random disconnections of one or more modules installed into one or more crates). When this happens, we have to:

• stop the LabVIEW program
• recover the lost connection/s with MAX start the LabVIEW program again 

At first, we deeply checked the network health and performance and it turned out to be ok.
Then — looking at our Nagios monitoring system — we looked for any correlation between the disconnection events and the Windows machine parameters logged by Nagios and we found a strict and repetitive concurrence between the connection drops and the Windows system time synchronisation events.

Image Added

Fig. 2 - Plot of the Windows System Time Offset (respect to our ntp server) from the Nagios monitoring system 

Looking at the Nagios “system time offset” plot (see fig. 2), three different regimes can be identified:

1. Until the 5th day of week 09

   The synchronisation period is set to 24 hours.

   The System Time drifts of few seconds per day (respect to the ntp server ) and then it re-synchronises. We didn’t experience connection drops in this condition;

2. From the 5th day of week 09 up to the mid 6th day of week 11

   The synchronisation period is set to 1 week.

   The System Time drifts of about 30 s per week and then it re-syncs. We had two connection drops in correspondence of the two big re-syncs;

3. From the mid 6th day of week 11 onwards

   The synchronisation period is set to 1 hour.

   The System Time doesn’t significantly drift. We didn’t experience connection drops in this condition.

We guess that something happens about the CompactDAQ connection management when contiguous TCP/IP packets have their timestamps mixed up due to the sharp time reset. 

Data: 27/01/2015 

Oggetto: Finestra dell’orbita in OVERSAMPLING senza nessun dato e DEVIL366 fuori comunicazione 

...