 Sun Jul 14 16:52:28 2024, TD, S181 R7_38-44 7x
|
| |
|
Sun Jul 14 14:37:53 2024, TD, S181 R6_375-380 6x
|
| |
|
Thu Sep 8 12:31:25 2022, NH, Retrying AIDA DataAcq v10
|
Startup AIDA with ribbon cable connected to aida03 and aida07 for noise
Setup and run with waveforms enabled. Discriminators ADC power etc as default
|
|
Fri Mar 22 13:47:32 2019, NH, Resolution Checks
|
Pulser widths of AIDA modules, resolution is fairly typical. AIDA09 still noisier than other DSSD channels.
Figure 1: Picture of pulser peaks
Figure 2: Raw waves (AIDA01 did not calibrate, so AIDA02 used instead as "non DSSD module") |
|
Mon Nov 4 13:17:12 2019, NH, Report: aida10 database corruption
|
Often aida10 database seems to get corrupted (ASIC values are all 0xad)
Unsure why it's only aida10, might be related to weird alpha rate behaviour at the moment.
|
 Tue Nov 5 10:02:45 2019, NH PJCS, Report: aida10 database corruption
|
This looks like the Options not the ASIC data. That will be in the CONTENTS file of the FEE64 named directory within the dated EXPERIMENT directory.
Looks like the latest is at /MIDAS/DB/EXPERIMENTS/AIDA/2019Oct31-13.24.23/aida10 ?
A quick look at this file and it looks normal , not all 0xad ? |
|
Tue Nov 5 10:32:21 2019, NH PJCS, Report: aida10 database corruption
|
Hi, see the attached files in the original comment. I think the BACKUPCorrupt is quite old now.
The Options data gets corrupted and for example the ASIC folder gets set to 'undefined' which I think is why the ASIC data loads incorrectly.
|
|
Tue Nov 5 11:15:41 2019, NH PJCS, Report: aida10 database corruption
|
If ypou now check the actual values in the aida10 Options screen are the correct ?
It can happen that corruptions once loaded are propagated when Options are generally saved.
Looking at the dates the files were modified does that make sense to you. It doesn't look as if the corrupted database was changed except |
|
Mon Feb 17 09:48:34 2020, NH, Report: aida09 Kernel Panic & Lost WR
|
aida09 crashed over the weekend and automatically rebooted.
After the reboot the WR timestamp sent to the merger is in the future and hence incorrect
|
|
Wed Feb 19 10:58:29 2020, NH, PJCS, Report: aida09 Kernel Panic & Lost WR
|
> aida09 crashed over the weekend and automatically rebooted.
> After the reboot the WR timestamp sent to the merger is in the future and hence incorrect
>
|
|
Mon Apr 22 09:03:54 2024, TD, Report: aida04 stops producing data
|
09.14 aida04 stopped producing data - system console output - attachment 1
|
|
Mon Mar 9 12:47:18 2020, NH, Report: Unusual AIDA Timestamp Error
|
Noted using my AIDA event builder code, a timewarp was reported and I noticed the ADC event had a different timestamp LSB to the "WR" markers preceding
it, which I didn't think was possible in the merger as it stands
|
|
Wed Apr 3 12:42:57 2024, NH, Report aida02 WR errors
|
The WR error counter for aida02 seems to consantly rise
Tried reseating cable on both ends, no change
However clock status passed, aida02 has a correct WR timestamp and no FIFO/PLL errors seen |
|
Thu Dec 19 10:11:59 2019, TD, Report - medium - FEE64 panics during boot
|
Some of the FEE64s aida01 .. aida12 panic during boot
|
|
Thu Dec 19 14:07:38 2019, TD, Report - low - aida08 ADC spectrum size 32k cf. 64k channels expcted using layout 6x
|
Note that aida08 spectrum 1.8.L size is (shown as) 32k channels cf. 64k channels expected using layout - attachment 1 - 5
Layout configuration - attachment 6
Why?
|
|
Fri Feb 21 12:16:06 2020, TD, NH, Report - high - unusual FEE64 crash during startup
|
| |
|
Wed Apr 3 12:09:47 2024, NH, Report - aida06 frequently fails to boot first time (PHY error)
|
When booting up AIDA aida06 usually crashes the first time, it fails to get IP from DHCP
After 180 seconds it reboots and seems to connect fine
Log file attached, key part (to me) is this: |
|
Wed Jan 8 10:46:50 2025, TD, Report - aida06 -boot fail due to network issue
|
8:01:25/11:42:48|0x000000d00000-0x000000fe0000 : "user_kernel"
08:01:25/11:42:48|0x000000fe0000-0x000001000000 : "env_variables"
08:01:25/11:42:48|xilinx-xps-spi 81400400.hd-xps-spi: at 0x81400400 mapped to 0xD1028400, irq=20
|
|
Wed Apr 10 14:53:50 2019, NH, Report - FEE stops sending data 6x
|
it seems a FEE somtimes enters a confusing state and stops sending data
the current merger requires all FEEs to be active and so this stops the entire system from proceeding.
On MIDAS the page reports the module is "undefined" |
|
Fri Apr 12 15:15:33 2019, NH, Report - FEE Kernel Panics (Update on 48)
|
Update on issue #48 - the "confusing state" is that the FEE has restarted and hence is undefined again.
An attached TTY log from the pi shows that the module is kernel panicking.
I have seen a couple of FEEs panic with the same error now. |