Page History

...

...

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

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:  

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 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 

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: 2802/1005/2020 

Oggetto: Plot dei rawData su dafne.lnf.infn.it non visibile con errremodificato DEVIL205 (per utilizzo con il nuovo DCT Agilent Ethernet) 

ID: 2020102820200502.1 

Autore: PA.CS. 

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 aggiornata. 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: 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: 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: 20191009ID: 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). 

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: 0227/0509/20202019 

Oggetto: modificato DEVIL205 (per utilizzo con il nuovo DCT Agilent Ethernet)VNC display del DEVIL675 nero e DEVIL dead 

ID: 2020050220190927.1 

Autore: A.S. 

Descrizione: 

DEVIL 675 - Virtual machine 032 - VNC display 75  

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". 

• 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: 2517/0407/20202019 

Oggetto: modificato file di configurazione del DUMPER /u2/dcs/prefs/DMP/serverConfigFile.confModifica script per avvio/reset VNC per devil serie 7 

ID: 2020042520190717.1 

Autore: AP.SC. 

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 

...

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.) 

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. 

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: 2103/0104/20202019 

Oggetto: Cambio permessi su shares NFSconfigurazione porte switches vLAN Apple 

ID: 2020012120190403.13 

Autore: PA.CS. 

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. 

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: 2003/0104/20202019 

Oggetto: Sostituzione dafneswitch con moxa in sala strumentazione per seriali target solarisProblema riavvio CPU force e DAFNE dovute a server NFS krunc spento 

ID: 2020012020190403.12 

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 

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/ 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_quadrupolesC_skewLamb.cnf 

/u2/dcs/space/uniDatabase/saveAreasfunctionalAreas/MRe/MRe_correctors_quadrupolesC_skewLamb.cnf 

/u2/dcs/space/uniDatabase/functionalAreassaveAreas/MRe/MRe_correctors_quadrupolesC_skewLamb.cnf 

QSKES100CDVES101 

QSKEL107CDVES201 

CDVEL101 

CDVEL201 

/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/ 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. 

Descrizione: 

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

Dopo attenta analisi, si è notato che la finestra - a fronte di un comando di set partendo dai MeV - inviava i comandi relativi ai due elementi sempre e solo al devil identificato dall’element index relativo all’elemento selezionato invece di discriminare in base all’elemento da controllare (con un devil che gestiva tutti e due gli elementi il problema non si poteva notare facilmente; da quando ci sono i due devil 682 e 683 però la finestra ha smesso di funzionare correttamente). Si è provveduto a sanare il bug ed a certificare il corretto funzionamento della nuova versione. In concomitanza di questo intervento, sono state richieste altre due modifiche: una con la sostituzione del selettore 100pC - 800pc inserendo un campo di testo libero (inserita con criterio insieme a Foggetta); una cambiando i calcoli fatti sui primi ed ultimi 4 “beam index” in quanto veniva divisa la carica sia dal devil che dalla finestra ed il grafico risultante non era corretto. 

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 

ID: 20190122.1 

Autore: P.C. 

Descrizione: 

Si installa sulle seguenti VM il software VIPM ed il modulo MODBUS (tutte queste sono LabVIEW 2102 SP1) con i seguenti dettagli da segnalare: 

Labview non partiva. Il reboot della VM si è bloccato con un kernel panic dovuto ad alcuni moduli labview; Dopo un Power Off e Power On della VM dall’interfaccia oVirt, tutto è tornato funzionante: 

vldantedev023 (192.168.198.123) - vldantedev029 (192.168.198.129) 

Labview non partiva. Dopo un reboot della VM tutto è tornato funzionante: 

vldantedev027 (192.168.198.127) - vldantedev028 (192.168.198.128) - vldantedev032 (192.168.198.132) 
 

Nessun Problema: 

vldantedev015 (192.168.198.115) - vldantedev020 (192.168.198.120) - vldantedev021 (192.168.198.121) 

vldantedev022 (192.168.198.122) - vldantedev024 (192.168.198.124) - vldantedev025 (192.168.198.125) 

vldantedev026 (192.168.198.126) - vldantedev030 (192.168.198.130) - vldantedev031 (192.168.198.131) 

vldantedev033 (192.168.198.133) - vldantedev034 (192.168.198.134) - vldantedev035 (192.168.198.135) 

vldantedev036 (192.168.198.136) - vldantedev038 (192.168.198.138) 

Su alcune macchine, aprendo labview 2012 SP1 da VIPM (utente root) appare un popup di errore, ma come utente dante non è successo. Restano le seguenti macchine senza VIPM: 

LabVIEW 2010: vldantedev001 (192.168.198.101) - vldantedev014 (192.168.198.114) 

LabVIEW 2012: vldantedev101 (192.168.198.150) 

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

Data: 09/11/2018 

Oggetto: QUATM002, QUATM003 fuori comunicazione 

ID: 20181109.1 

Autore: A.S. 

Descrizione: 

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

Si risolve sempre smanettando il monchino+DB9 sulla porta 5 dl MOXA .40 

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 

ID: 20171204.1 

Autore: A.S. 

Descrizione: 

Il file fast.stat risultava malformato per errore nel descrittore di formato scritto nel file: 

/u2/dcs/prefs/DMP/serverConfigFile.conf 

Si veda rapporto completo su: 

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 

ID: 20170525.2 

Autore: A.S., P.C. 

Descrizione: 

problema con seriali DEVIL642 su vldantedev032 

Il devil gira velocissimo. Guardando sul MOXA si vede che le porte vengono prese dall'IP giusto ma non c'è traffico (neanche in trasmissione). 

1. si riavvia il DEVIL: Nessun miglioramento 

1. si riavvia il MOXA: Nessun miglioramento 

1. si riavvia la vm: Nessun miglioramento 

1. si passa da VISA a native: Nessun miglioramento 

1. si mette in run il DEVIL su un'altra vm (che ha lo stesso MOXA configurato): Nessun miglioramento 

1. si riavvia NUOVAMENTE la vm: OK 

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 

ID: 20170525.1 

Autore: A.S. 

Descrizione: 

La versione _newOCEM_3.2 richiede le seguenti configurazioni: 

DEVIL6XX.DBSta: 

timeouts = 10, 10, 400 

serialType = 1 (native) 

DEVIL6XX.pref:  

idleTime = 100 

Con il simbolo SW si indicano gli alimentatori che commutano durante lo switch di macchina. 

Con il simbolo [!C] si indicano i DEVILs potenzialmente sostituibili con CU !CHAOS e DEVIL7XX 

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. 

Descrizione: 

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

Dopo attenta analisi, si è notato che la finestra - a fronte di un comando di set partendo dai MeV - inviava i comandi relativi ai due elementi sempre e solo al devil identificato dall’element index relativo all’elemento selezionato invece di discriminare in base all’elemento da controllare (con un devil che gestiva tutti e due gli elementi il problema non si poteva notare facilmente; da quando ci sono i due devil 682 e 683 però la finestra ha smesso di funzionare correttamente). Si è provveduto a sanare il bug ed a certificare il corretto funzionamento della nuova versione. In concomitanza di questo intervento, sono state richieste altre due modifiche: una con la sostituzione del selettore 100pC - 800pc inserendo un campo di testo libero (inserita con criterio insieme a Foggetta); una cambiando i calcoli fatti sui primi ed ultimi 4 “beam index” in quanto veniva divisa la carica sia dal devil che dalla finestra ed il grafico risultante non era corretto. 

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 

ID: 20190122.1 

Autore: P.C. 

Descrizione: 

Si installa sulle seguenti VM il software VIPM ed il modulo MODBUS (tutte queste sono LabVIEW 2102 SP1) con i seguenti dettagli da segnalare: 

Labview non partiva. Il reboot della VM si è bloccato con un kernel panic dovuto ad alcuni moduli labview; Dopo un Power Off e Power On della VM dall’interfaccia oVirt, tutto è tornato funzionante: 

vldantedev023 (192.168.198.123) - vldantedev029 (192.168.198.129) 

Labview non partiva. Dopo un reboot della VM tutto è tornato funzionante: 

vldantedev027 (192.168.198.127) - vldantedev028 (192.168.198.128) - vldantedev032 (192.168.198.132) 
 

Nessun Problema: 

vldantedev015 (192.168.198.115) - vldantedev020 (192.168.198.120) - vldantedev021 (192.168.198.121) 

vldantedev022 (192.168.198.122) - vldantedev024 (192.168.198.124) - vldantedev025 (192.168.198.125) 

vldantedev026 (192.168.198.126) - vldantedev030 (192.168.198.130) - vldantedev031 (192.168.198.131) 

vldantedev033 (192.168.198.133) - vldantedev034 (192.168.198.134) - vldantedev035 (192.168.198.135) 

vldantedev036 (192.168.198.136) - vldantedev038 (192.168.198.138) 

Su alcune macchine, aprendo labview 2012 SP1 da VIPM (utente root) appare un popup di errore, ma come utente dante non è successo. Restano le seguenti macchine senza VIPM: 

LabVIEW 2010: vldantedev001 (192.168.198.101) - vldantedev014 (192.168.198.114) 

LabVIEW 2012: vldantedev101 (192.168.198.150) 

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

Data: 09/11/2018 

Oggetto: QUATM002, QUATM003 fuori comunicazione 

ID: 20181109.1 

Autore: A.S. 

Descrizione: 

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

Si risolve sempre smanettando il monchino+DB9 sulla porta 5 dl MOXA .40 

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 

ID: 20171204.1 

Autore: A.S. 

Descrizione: 

Il file fast.stat risultava malformato per errore nel descrittore di formato scritto nel file: 

/u2/dcs/prefs/DMP/serverConfigFile.conf 

Si veda rapporto completo su: 

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 

ID: 20170525.2 

Autore: A.S., P.C. 

Descrizione: 

problema con seriali DEVIL642 su vldantedev032 

Il devil gira velocissimo. Guardando sul MOXA si vede che le porte vengono prese dall'IP giusto ma non c'è traffico (neanche in trasmissione). 

1. si riavvia il DEVIL: Nessun miglioramento 

1. si riavvia il MOXA: Nessun miglioramento 

1. si riavvia la vm: Nessun miglioramento 

1. si passa da VISA a native: Nessun miglioramento 

1. si mette in run il DEVIL su un'altra vm (che ha lo stesso MOXA configurato): Nessun miglioramento 

1. si riavvia NUOVAMENTE la vm: OK 

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 

ID: 20170525.1 

Autore: A.S. 

Descrizione: 

La versione _newOCEM_3.2 richiede le seguenti configurazioni: 

DEVIL6XX.DBSta: 

timeouts = 10, 10, 400 

serialType = 1 (native) 

DEVIL6XX.pref:  

idleTime = 100 

Con il simbolo SW si indicano gli alimentatori che commutano durante lo switch di macchina. 

Con il simbolo [!C] si indicano i DEVILs potenzialmente sostituibili con CU !CHAOS e DEVIL7XX 

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 

...