<!-- Title: Eve shift. Sat Apr 14, 2001 -->
<!-- SciCo: Steve Tether -->
<!-- DAQAce: Vladimir Nagaslaev -->
<!-- MonAce: Ben Kilminster -->
<!-- CO: Youngdo Oh -->
<!-- OpManager: Doug Benjamin -->
<!-- Notes: -->
<pre>We get to try calibrations again. What fun. After that and a Rick run we're supposed to take cosmics using 1X8_END_1[7,101] and [7,102] with L2 and Si in. 
</pre>


<!-- Date: Sat Apr 14 16:36:59 2001 -->
<pre>The run hangs with state 14 error. Running scrips: 
Info: Alpha is okay. Currently at spot 7: Started Handshake with TSI 
 TSI handshake bits are 4fff0009 
 TSI startload bits are 10101b4 
 TSI MODDONE bits are 4007ffff 
 Number of words for TL2D, buffer 0: 6c000000 
 Number of words for TL2D, buffer 1: 6c000000 
 Number of words for TL2D, buffer 2: 6c000000 
 Number of words for TL2D, buffer 3: 6c000000 
 Address for DMA buffer 0 is 500090 
 Address for DMA buffer 1 is 500100 
 Address for DMA buffer 2 is 500600 
 Address for DMA buffer 3 is 500fa0 
 Address for DMA buffer 4 is 504580 
 Address for DMA buffer 5 is 508d80 
 Address for DMA buffer 6 is 100000 
 Address for DMA buffer 7 is 100000 
 Address for DMA buffer 8 is 100000 
 Address for DMA buffer 9 is 100000 
 Executable name is l2exe/INTEGRATION_TABLE_CAL_1_v-2_B0L2PR00 
  
  
   Offset? [00003010] (hex):  300c 
                 [00000009] Change to: 
   Offset? [0000300C] (hex): 
                 [00000009]  Change to:   
</pre>
<!-- Author: Vladimir -->
<!-- Comment: Sat Apr 14 20;36;36 comment by...Stephen Miller -->
<pre>Make sure to read register 3010 before switching to
register 300c.
</pre>

<!-- Date: Sat Apr 14 16:55:16 2001 -->
<pre>Ilya is currently studying the reformatter errors to do with the  
byte count from silicon.</pre>
<!-- Author: Ben -->


<!-- Date: Sat Apr 14 17:13:14 2001 -->
<pre>Ilya made a change to reformatter code. 
Now, after 10 K events, we see reformatter error: 
 
(MLE) b0l3gate2.fnal.gov:main:5:08:34 PM->Error on L3 node b0l3035 (partition 0) 
Sat Apr 14 17:08:30 2001 l3_node 
  in refoInt_reformatProc (l3_refevt.c:610) 
  @L3_REFORMAT_ERROR 
 
RAWREF Error - UTILSILDEC - with code 38 -- START 
 Line -  299 in: src/library/rr_rawevt.c 
 Buffer position: 293 
 Error count: 1 of 1 
 Reject rate: 0.223 percent 
 
 Detector ID not known (yet?). 
 FIB id found: 
  0xc4fa3264 
 
 Error location code: 0x00000020 
 
 
 Crate Id?: 0x00000000 
 
 Error during scanning MINI structure! 
 Last Unit prob. worked on (all counts from 0): 
  SCPU: 0 
  VRB : 0 
  LINK: 2 
  MINI: 0 
 
 Buffer (273 until posi+2=295) 
 0xbfffaff1  0xaaf0bfff  0xbfffbfff  0xaff100ff  0xbfffbfff  0xbfffaaf0 
 0x00ffbfff  0xbfffaff1  0xaaf0bfff  0xbfffbfff  0xaff100ff  0xbfffbfff 
 0xbfffaaf0  0x00ffbfff  0xbfffaff1  0xaaf0bfff  0xbfffbfff  0xaff100ff 
 0xbfffbfff  0xbfffaaf0  0x6432fac4  0xfca0dffc  0xdfa0ff00 
 
 
 NOTE: Event rejected! 
 
 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112056' target=_top>112056</a>) -->


<!-- Date: Sat Apr 14 17:30:25 2001 -->
<pre>   The original problem when all events with L00 were rejected 
by reformatter is understood, our patch to reformatter has  
worked. The reformatter complaints described in the previous 
entry is something else. Mary Bishai says she approximately 
knows what the problem is. 
 </pre>
<!-- Author: Ilya -->


<!-- Date: Sat Apr 14 17:37:40 2001 -->
<pre>Ran QIE calibrations. Data appeared in the DB. 
West plug is off (in use by D.Cauz).</pre>
<!-- Author: Vladimir :: (run <a href='/cgi-bin/runSummaryRun.cgi?112057' target=_top>112057</a>) -->


<!-- Date: Sat Apr 14 17:40:42 2001 -->
<pre>
LED calibrations. Ended with no errors, but data is not going to 
the DB. Noticed that during the setup transition RC gives 
error messages in the console (not in the Error display!): 
 
 
2001.04.14 17:35:05 ** Column PINPED has crazy index 2 [0] 
2001.04.14 17:35:05 *** Error FLASHPED no channel 771 component CEM 
2001.04.14 17:35:05 ** Column PINPED_SIG has crazy index 3 [0] 
2001.04.14 17:35:05 *** Error FLASHPED no channel 770 component CEM 
2001.04.14 17:35:05 ** Column PMTPED has crazy index 0 [0] 
2001.04.14 17:35:05 *** Error FLASHPED no channel 770 component CEM 
2001.04.14 17:35:05 ** Column PMTPED_SIG has crazy index 1 [0] 
2001.04.14 17:35:05 *** Error FLASHPED no channel 770 component CEM 
2001.04.14 17:35:05 ** Column PINPED has crazy index 2 [0] 
2001.04.14 17:35:05 *** Error FLASHPED no channel 770 component CEM 
2001.04.14 17:35:05 ** Column PINPED_SIG has crazy index 3 [0] 
2001.04.14 17:35:05 *** Error FLASHPED no channel 773 component CEM 
.............................. 
.............................. 
Could it be the same problem yesterday with COT, XEF and SMX calibrations?  
</pre>
<!-- Author: Vladimir :: (run <a href='/cgi-bin/runSummaryRun.cgi?112059,112061' target=_top>112059,112061</a>) -->
<!-- Comment: Sat Apr 14 18;18;45 comment by...Vladimir -->
<pre>112061 eventually succeeded to go to the DB. I don't see why the others did not. They were just several attempts.
</pre>
<!-- Date: Sat Apr 14 17:44:38 2001 -->
<pre>Now we run with FIB 01, 02, 05, 06. 
 
After ~ 2 K events, we get BUSY CONDITIONS from VRB header errors: 
 
(MLE) b0l3gate1.fnal.gov:main:5:30:35 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P0-E-EventIdMismatch: VRB ID for event 3717 is 0 instead of 5 (slot 16). 
(MLE) b0l3gate1.fnal.gov:main:5:30:35 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P0-E-VrbHeader: Dump of header words for event 3717 from VRB in slot 16: 
0x00800000 0x01be0096 0x02a4009e 0x00000000 0x00000000 0xe1600000 0x831c2efc 0x821c0004 
30'44" 1 crate/s: b0svx02(112),  busy.[RXPT]                                                                    
 
 
Now a HRR:  
 
(MLE) b0l3gate1.fnal.gov:main:5:31:23 PM->Host b0eb20.fnal.gov, task tRec_0 
SCPU-P0-E-BadVrbByteCount: Event 5377 total byte count is lt 32, gt 65528, or not divisible by 8 for VRB in slot 12. 
Count = 326. 
(MLE) b0l3gate1.fnal.gov:main:5:31:23 PM->Host b0eb20.fnal.gov, task tRec_0 
SCPU-P0-E-VrbHeader: Dump of header words for event 5377 from VRB in slot 12: 
0x01460264 0xe3506dfc 0x83040002 0x82044405 0x450646f3 0x7e037f07 0xa10400f3 0x06030707 
31'31" 1 crate/s: b0svx02(112),  busy.[RXPT]     
 
 
And another HRR 
 
   (MLE) b0l3gate1.fnal.gov:main:5:33:20 PM->Host b0eb21.fnal.gov, task tRec_0 
SCPU-P0-E-BadVrbByteCount: Event 10902 total byte count is lt 32, gt 65528, or not divisible by 8 for VRB in slot 12. 
Count = 316. 
(MLE) b0l3gate1.fnal.gov:main:5:33:20 PM->Host b0eb21.fnal.gov, task tRec_0 
SCPU-P0-E-VrbHeader: Dump of header words for event 10902 from VRB in slot 12: 
0x013c016e 0xe4500144 0x831900fc 0x01050004 0x03010206 0x05030406 0x07070605 0x09070804                                                                                     
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112060' target=_top>112060</a>) -->


<!-- Date: Sat Apr 14 18:01:30 2001 -->
<pre>Now several attempt later, 
after a few more COLDSTARTS, FIB 02  fails to COLDSTART. 
 
ABT+RST.   this time  FIB 02 goes through.  Strange ...</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112066' target=_top>112066</a>) -->


<!-- Date: Sat Apr 14 18:02:24 2001 -->
When running with HEVB and Si alone every 1K events getting 
SCPU errors where the number of bytes is not divisible by 8. 
Since the number of bytes comes from the VRB header. It seems 
to be a VRB header problem. But system works fine in standalone 
mode so where are the VRB headers being corrupted?.  
Also of course no such complaints from previous attempts 
with SEVB. The VRBs it has complained about are B0svx02 16 
B0svx03 12 B0svx06 slot 10. Decided to take Silicon out 
of integration until Monday. Powered all wedges OFF. 
 
Are we sure that the SCPU is reading the right word for the 
byte count? Is there an offset?
<!-- Author: Mary Bishai -->
<!-- Comment: Sat Apr 14 19;18;46 comment by...ST -->
To take the last two questions in order: (1) Yes. (2) No.
<!-- Date: Sat Apr 14 18:02:41 2001 -->
<pre>Reformatter errors during silicon integration tests 
are crippling runs and we are conceding that we must 
exclude them for the time being.</pre>
<!-- Author: Ben -->


<!-- Date: Sat Apr 14 18:04:44 2001 -->
<pre>I looked into ccal09. Crate map says there are NO CARDS in 
slots 13-21! But the crate configuration (and the cardEditor) 
show ADMEMS in slots 16-21. Experts, why is this? 
</pre>
<!-- Author: Vladimir -->


<!-- Date: Sat Apr 14 18:09:21 2001 -->
<pre>COT Calibration. 
Entry is in DBANA.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112055' target=_top>112055</a>) -->


<!-- Date: Sat Apr 14 18:10:14 2001 -->
<pre>Muon calibration. 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112067' target=_top>112067</a>) -->



<!-- Date: Sat Apr 14 18:25:29 2001 -->
XEF ped calibrations 
<!-- Author: Vladimir :: (run <a href='/cgi-bin/runSummaryRun.cgi?112071' target=_top>112071</a>) -->


<!-- Date: Sat Apr 14 18:39:20 2001 -->
<pre>TOF calibration.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112076' target=_top>112076</a>) -->


<!-- Date: Sat Apr 14 18:41:37 2001 -->
<pre>Problems turning on XEF flasher HV.</pre>
<!-- Author: Ben -->
<!-- Comment: Sat Apr 14 18;58;10 comment by...Vladimir -->
Call Steve Hahn. He finally suggested to skip this calibration.


<!-- Date: Sat Apr 14 19:02:28 2001 -->
SMX calibrations. West plug is off.
<!-- Author: Vladimir :: (run <a href='/cgi-bin/runSummaryRun.cgi?112085' target=_top>112085</a>) -->


<!-- Date: Sat Apr 14 19:17:54 2001 -->
SMX data is not going to the DB. I tried again- 112093, 
and then once more, after stop/start the consumer- 112096
<!-- Author: Vladimir :: (run <a href='/cgi-bin/runSummaryRun.cgi?112096' target=_top>112096</a>) -->



<!-- Date: Sat Apr 14 19:21:13 2001 -->
<pre>Mary is still  here. 
 
We are reading out FIBS 1,2,5,6 in READOUT all mode. 
 
This should give us a reformatter error on the order of ~150 
Kevents.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112094' target=_top>112094</a>) -->


<!-- Date: Sat Apr 14 19:31:02 2001 -->
<pre>Weird VRB error after 130 K events. 
 
 
(MLE) b0l3gate1.fnal.gov:main:7:26:08 PM->Host b0eb19.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 18 for event 126679. 
VRB_BUS_ERROR: Alignment or VME bus error. 
Transferred 8 bytes before the error. 
26'13" 1 crate/s: b0svx02(112),  busy.[RXPT] 
(MLE) b0tsi02:Messenger:7:26:18 PM->BUSY timeout 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112094' target=_top>112094</a>) -->


<!-- Date: Sat Apr 14 19:40:33 2001 -->
<pre>After HRR and another 100 K events, we see this problem: 
 
(RC) Run -> ACTIVE 
(MLE) b0l3gate1.fnal.gov:main:7:38:20 PM->Host b0eb19.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 16 for event 219841. 
VRB_BUS_ERROR: Alignment or VME bus error. 
Transferred 8 bytes before the error. 
(MLE) b0l3gate1.fnal.gov:main:7:38:21 PM->Host b0eb25.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 10 for event 219849. 
The VRB had no event. 
(MLE) b0l3gate1.fnal.gov:main:7:38:21 PM->Host b0eb20.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 12 for event 219849. 
The VRB had no event. 
(MLE) b0l3gate1.fnal.gov:main:7:38:21 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 16 for event 219849. 
The VRB had no event. 
(MLE) b0l3gate1.fnal.gov:main:7:38:21 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 16 for event 219849. 
The VRB had no event. 
(MLE) b0l3gate1.fnal.gov:main:7:38:21 PM->Host b0eb21.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 12 for event 219849. 
The VRB had no event. 
(MLE) b0l3gate1.fnal.gov:main:7:38:21 PM->Host b0eb24.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 13 for event 219849. 
The VRB had no event. 
(MLE) b0l3gate1.fnal.gov:main:7:38:22 PM->Host b0eb25.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 12 for event 219849. 
The VRB had no event. 
(MLE) b0l3gate1.fnal.gov:main:7:38:22 PM->Host b0eb20.fnal.gov, task tRec_0 
SCPU-P6-E-VrbReadFailed: Error reading VRB in slot 16 for event 219849. 
The VRB had no event. 
38'26" 1 crate/s: b0svx02(112),  busy.[RXPT] 
(M</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112094' target=_top>112094</a>) -->


<!-- Date: Sat Apr 14 19:52:15 2001 -->
<pre>This is an analysis of the SCPU error recorded on Fri 13th 16:36:51 in 
b0svx02 slot 16: 
 
At that point we were trying to run integrated with Silicon in readall 
mode and the error was that the byte count was 3618. This is much less 
than the total byte count from the readout of a whole wedge but is 
exactly the byte count from a layer 4 ladder in read all mode: 
 
4 bytes from fib header + 14chips X 2bytes for chipid and cellid 
+14chips X (128channels+128adccounts) + 2 bytes fib end of readout. 
  
This number is the last word in the VRB header dumped, the word 
preceeding being also consistant with the byte count from the next to 
last channel. I can't recognize any known patterns in the following 
words in the dump - looks completely alien to me. So why is the SCPU 
picking up the last word instead of the first word which is the true 
total byte count?  The SVX vrbs total up the byte count in each 
channel which is dependent on the data and is not necessarily 
divisible by 8 and then pad extra words so that the total byte count 
is divisible by 8. 
 
Incidentally the VRBs where this error occurs seem to be the  
only the ones where the bottom 5 channels have data 
 
The errors seem to occur at a much higher frequency when  
data is sparsified. Could this be a speed issue? Are the SCPUs 
pulling things out of the VRB output fifos too fast ? 
 
How about the latest firmware fix to the SVX VRBs to solve nibble 
shifting problems? The fix involved an extra clock when clocking input 
buffers to output fifo ( I think )? Just as we sometimes got things 
off by a nibble could we now be clocking things too far ? 
 
Tried to reproduce errors on Friday running in readall mode with an extra 
ISL wedge on the east. At around the same number of events instead 
of getting wrong byte counts, got bus errors - VRB misaligned - see 
Bens entries. 
</pre>
<!-- Author: Mary Bishai -->


<!-- Date: Sat Apr 14 19:58:57 2001 -->
<pre>HRR does not work this time: 
We try a few - and just get 4 events each time before  
a BUSY condition from b0svx02 ticks in. 
 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112094' target=_top>112094</a>) -->


<!-- Date: Sat Apr 14 20:00:52 2001 -->
<pre>new run -> switch to real trigger. 
        ->  integrate just about everything. 
 
BUSY TIMEOUT after 457 events: 
 
Partition:6 Run number: 112103 (0x1b5e7) 
(RC) Config -> READY 
(RC) Activate -> ACTIVE 
57'14" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:07:37 2001 -->
<pre>HRR  ... 15 K more events and then the error:  
 
(MLE) b0l3gate1.fnal.gov:main:8:05:02 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P6-E-EventIdMismatch: VRB ID for event 14975 is 0 instead of 15 (slot 16). 
(MLE) b0l3gate1.fnal.gov:main:8:05:02 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 14975 from VRB in slot 16: 
0x02300000 0x00000000 0x00000000 0xe06176fc 0x850e0003 0x02040306 0x04f363f3 0x64 
066501 
5'7" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:13:12 2001 -->
<pre>HRR ... 8 K more events. 
 
(RC) Run -> ACTIVE 
(MLE) b0l3gate1.fnal.gov:main:8:10:58 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P6-E-EventIdMismatch: VRB ID for event 23185 is 0 instead of 1 (slot 16). 
(MLE) b0l3gate1.fnal.gov:main:8:10:58 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 23185 from VRB in slot 16: 
0x02880000 0x00000000 0x00000000 0xe0614afc 0x85130004 0x84138313 0x7df37e07 0x7f 
06a213 
11'5" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:17:49 2001 -->
<pre>HRR ... 10 K more events and then ... 
(RC) Run -> ACTIVE 
(MLE) b0l3gate1.fnal.gov:main:8:16:07 PM->Host b0eb19.fnal.gov, task tRec_0 
SCPU-P6-E-BadVrbByteCount: Event 34423 total byte count is lt 32, gt 65528, or no 
t divisible by 8 for VRB in slot 16. 
Count = 132. 
(MLE) b0l3gate1.fnal.gov:main:8:16:07 PM->Host b0eb19.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 34423 from VRB in slot 16: 
0x00840000 0x00000138 0x015e01ae 0x015e00bc 0x01240000 0xe2600384 0x830496fc 0x05 
020001 
16'15" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:26:06 2001 -->
<pre>HRR   ...  20 K  events more and then ... 
 
(RC) Run -> ACTIVE 
18'50" 
(MLE) b0cot02:Messenger:8:23:04 PM->Runtime Error 1, Event 53651: data truncated 
(MLE) b0cot03:Messenger:8:23:04 PM->Runtime Error 1, Event 53651: data truncated 
(MLE) b0cot01:Messenger:8:23:03 PM->Runtime Error 1, Event 53651: data truncated 
(MLE) b0l3gate1.fnal.gov:main:8:23:08 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P6-E-EventIdMismatch: VRB ID for event 53979 is 232 instead of 11 (slot 16). 
(MLE) b0l3gate1.fnal.gov:main:8:23:08 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 53979 from VRB in slot 16: 
0x00b000e8 0x0156012a 0x03000000 0x00000000 0x00000000 0xe1606afc 0x83250006 0x01 
080201 
23'15" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:28:37 2001 -->
<pre>HRR ... 2 K more events , then ... 
 
 
(MLE) b0l3gate1.fnal.gov:main:8:26:45 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P6-E-EventIdMismatch: VRB ID for event 55786 is 136 instead of 10 (slot 16). 
(MLE) b0l3gate1.fnal.gov:main:8:26:45 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 55786 from VRB in slot 16: 
0x03980188 0x00000000 0x00000000 0xe0610000 0x851d2cfc 0x01060007 0x841d0204 0x7e 
077d03 
26'51" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:30:34 2001 -->
<pre>HRR ...   50 events more and then ... 
(MLE) b0l3gate1.fnal.gov:main:8:29:23 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P6-E-BadVrbByteCount: Event 55851 total byte count is lt 32, gt 65528, or no 
t divisible by 8 for VRB in slot 16. 
Count = 172. 
(MLE) b0l3gate1.fnal.gov:main:8:29:23 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 55851 from VRB in slot 16: 
0x00ac0092 0x010800ee 0x02840000 0x00000000 0x00000000 0xe1604dfc 0x83200003 0x15 
031605 
(RC) Run -> ACTIVE 
29'30" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:34:21 2001 -->
<pre>HRR ... 10 K more events and then ... 
 
(MLE) b0l3gate1.fnal.gov:main:8:33:11 PM->Host b0eb21.fnal.gov, task tRec_0 
SCPU-P6-E-BadVrbByteCount: Event 66134 total byte count is lt 32, gt 65528, or no 
t divisible by 8 for VRB in slot 12. 
Count = 274. 
(MLE) b0l3gate1.fnal.gov:main:8:33:11 PM->Host b0eb21.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 66134 from VRB in slot 12: 
0x01120160 0xe45001c2 0x830573fc 0x1b010004 0x1d031c05 0x3c053bf3 0x65f33df3 0x67 
016606 
33'18" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:36:06 2001 -->
<pre>HRR ... 1 K events more and then ... 
 
(MLE) b0l3gate1.fnal.gov:main:8:34:59 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P6-E-BadVrbByteCount: Event 67143 total byte count is lt 32, gt 65528, or no 
t divisible by 8 for VRB in slot 16. 
Count = 654. 
(MLE) b0l3gate1.fnal.gov:main:8:34:59 PM->Host b0eb17.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 67143 from VRB in slot 16: 
0x028e0000 0x00000000 0x00000000 0xe06141fc 0x85150006 0x01038415 0x5d015e05 0x5f 
f37e02 
35'8" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->



<!-- Date: Sat Apr 14 20:38:15 2001 -->
<pre>HRR ... 3 K more events and then ... 
 
(MLE) b0l3gate1.fnal.gov:main:8:37:10 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P6-E-EventIdMismatch: VRB ID for event 70837 is 0 instead of 5 (slot 16). 
(MLE) b0l3gate1.fnal.gov:main:8:37:10 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 70837 from VRB in slot 16: 
0x00a80000 0x013200bc 0x020c00e4 0x00000000 0x00000000 0xe1600000 0x83160cfc 0x01 
06000a 
37'18" 1 crate/s: b0svx02(112),  busy.[RXPT] 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:44:41 2001 -->
<pre>HRR   ...  20 K events more ... and then ... 
 
(MLE) b0l3gate1.fnal.gov:main:8:43:49 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P6-E-EventIdMismatch: VRB ID for event 93132 is 0 instead of 12 (slot 16). 
(MLE) b0l3gate1.fnal.gov:main:8:43:49 PM->Host b0eb18.fnal.gov, task tRec_0 
SCPU-P6-E-VrbHeader: Dump of header words for event 93132 from VRB in slot 16: 
0x00c00000 0x020600f4 0x027800f4 0x00000000 0x00000000 0xe1600000 0x830f2ffc 0x01070007 
 </pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:46:13 2001 -->
<pre>I am putting an end to this now.  Hopefully,  there is something 
to be learned from me beating these errors to death ... 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112103' target=_top>112103</a>) -->


<!-- Date: Sat Apr 14 20:59:02 2001 -->
<pre>Rick Run  (INTEGRATION TABLE SUM ET 5,  all CAL crates, 30 K events) 
 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112104' target=_top>112104</a>) -->


<!-- Date: Sat Apr 14 21:02:53 2001 -->
<pre>If you get a chance, Please run with the L2_RATE_TEST physics 
table again with the alpha not in tagging mode. 
This test last night had immediate state 14 errors, but this 
afternoon it took 20K events with a high L1A rate and a reduced 
L2A rate with the L2 trigger rejecting most events. 
There was no change to the L2 crate or code, so it would  
be useful to find out if there is some other system configuration 
that leads to the problem or if it is a random error. 
 
Run # 112034 was the successful run from today. The Run summary 
should have the list of crates used for that run. It would 
be useful to compare the performance with those crates versus 
the full system.</pre>
<!-- Author: Stephen Miller -->
<!-- Comment: Sat Apr 14 21;08;51 comment by...Stephen -->
<pre>Note: To take the alpha out of tagging mode,
run ~jsm/alpha/alphatag_linux  on an online linux machine.</pre>


<!-- Date: Sat Apr 14 21:16:52 2001 -->
<pre>It's Miller time. 
 
L2_RATE_TEST 
 
DO Timeout after 50 events from XTRP. 
 
HRR works...</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112105' target=_top>112105</a>) -->
<!-- Comment: Sat Apr 14 21;17;50 comment by...Ben -->
<pre>After 1500 events,  there is another DO Timeout from XTRP 00.</pre>


<!-- Date: Sat Apr 14 21:21:51 2001 -->
<pre>Logging into XTRP 00, this is the error that comes by : 
 
 
FISION: S_errno_EIO (0x5): VME BERR received! 
TRIG_readOutFormat: detected 1 read errors 
TRACER_enableDone: Front End Fatal Error (-1): Tracer done not set 
VISION read failed in slot 16 
Monitor: interval 6000, state ACTIVE for partition 6 
Monitor: Evts sent/readout/triggered 1895/1895/1895 
Monitor: Error state:    0, VRB_Busy:    0, TV count: 0 
Monitor: readout/sent rate      6.7 Hz /      6.7 Hz, cur evt is 1460 bytes 
 
No new event ... 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112105' target=_top>112105</a>) -->


<!-- Date: Sat Apr 14 21:24:12 2001 -->
<pre>Can't find anything in the log to suggewst XTRP should be bad. 
Rebooting XTRP 00.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112105' target=_top>112105</a>) -->


<!-- Date: Sat Apr 14 21:39:09 2001 -->
<pre>After rebooting, and trying to start again ... 
XTRP is complaining ... 
  
b0xtrp00-> Messenger: processStatechange Config [0] 
Slot  2: 0017 001 TRACER__V2.1A 
  
data access 
Exception current instruction address: 0x002362f4 
Machine Status Register: 0x0000b130 
Data Access Register: 0x6f636573 
Condition Register: 0x44000048 
Data storage interrupt Register: 0x0000b130 
Task: 0xced4f0 "Messenger"    
 
 
Yes,  the Messenger task is suspended. 
 
b0xtrp00-> i 
  
  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY 
---------- ------------ -------- --- ---------- -------- -------- ------- ----- 
tExcTask   excTask        eff098   0 PEND         29f490   efefc0       0     0 
tNetTask   netTask        edf638   1 PEND         27f1bc   edf588       0     0 
tPortmapd  portmapd       eda8b0   1 PEND         27f1bc   eda740      16     0 
tRlogOutTasrlogOutTask    c213d8   2 PEND         27f1bc   c21250       0     0 
tRlogInTaskrlogInTask     c1fe48   2 PEND         27f1bc   c1fc20       0     0 
tShell     shell          ed2290   5 READY        282b80   ed1258  1c0001     0 
tRlogind   rlogind        edbe40  15 PEND         27f1bc   edba80       0     0 
tRdbTask   rdbTask        ed9320  20 PEND         27f1bc   ed91c0   d0003     0 
tAioIoTask1aioIoTask      ef09d0  50 PEND         27f630   ef0928       0     0 
tAioIoTask0aioIoTask      ee97c8  50 PEND         27f630   ee9720       0     0 
tAioWait   aioWaitTask    ef7bd8  51 PEND         27f1bc   ef7a80       0     0 
rshelld    ebac48         ebfef8 100 PEND         27f1bc   ebfd90 ffffffff     0t1         VISIONserver   eb9e68 100 PEND         27f1bc   eb9d10       0     0 
t2         ROBINserver    eb4e40 100 PEND         27f1bc   eb4d00       0     0 
t3         httpDaemon     eafe18 100 PEND         27f1bc   eafc00       0     0 
Messenger  FER_messenge   ced4f0 200 SUSPEND      2362f4   cecc68  1c0001     0 
Mon_III    FER_monitorI   c47910 220 DELAY        282134   c47870       0    36 
tLogTask   logTask        efc720 250 PEND         29f490   efc658       0     0 
value = 0 = 0x0     
 
 
Removing XTRP for the time being...                                                              
 
                                                   </pre>
<!-- Author: Ben -->


<!-- Date: Sat Apr 14 22:22:51 2001 -->
<pre>Continuing L2 running with alpha in non-tag mode. 
 
After 53 K events, there is a DO Timeout from COT 04. 
 
HRR ... 
 
At 57 K events, there is another DO timeout from COT 12. 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112107' target=_top>112107</a>) -->


<!-- Date: Sat Apr 14 22:25:45 2001 -->
<pre>I've looked offline at runs using the L2 rate test trigger 
table (112033, 034 and 105) and see something puzzling 
which might be an artifact of using a weakly prescaled 
zero bias trigger (BC) to drive up the L1A rate, but 
I would like to be sure.  What I see is that the L1A 
are NOT distributed evenly among the 36 BC locations 
in one turn around the ring (this can be seen on the 
`TS' page (right most tab) of the ScalerMonitor). 
 
Offline I can see that the livetime IS distributed 
evenly among the 36 BC locations (we can get this 
up as another page on the ScalerMonitor).  I expect 
both to be flat if things are working properly AND 
the L1A are pretty random.  But a trigger driven 
solely by BC is not.  I suspect a beat effect due 
to the fact that the number of BC locations (36) 
and the prescale factor (100) have common factors. 
 
If we could try a take two runs, back to back, (yes I 
know this may be asking a lot of the system!) with 
the zero bias prescale equal to 100 and then 125, it 
would be helpful (unless somebody has a better theory). 
(36 = 2^2 * 3^2, 100 = 2^2 * 5^2, 125 = 5^3; I think 
99 = 3^2 * 11 would be no better).  Thanks!   
 
PS If it can not be done on the current shift, 
please pass the request on to the 8am meeting. 
</pre>
<!-- Author: Michael Schmidt :: (run <a href='/cgi-bin/runSummaryRun.cgi?112105' target=_top>112105</a>) -->


<!-- Date: Sat Apr 14 22:26:04 2001 -->
<pre>Hoping to find someone who knows the password so that we can 
change the pre-scale on the zero bias trigger.  This is a  
suggestion by Michael Schmidt to see what happens if there is no 
beat frequency with the Bunch counters, 
 
as seen in the next plot.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112107' target=_top>112107</a>) -->


<!-- Date: Sat Apr 14 22:29:47 2001 -->
<table><tr><td><a href=/cgi/elog/elog.pl?nb=2001&action=view&page=-656&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/elog.pl?nb=2001&action=view&page=-656  width='300' align='top'></td><td>Look at the pattern of bunches that had triggers issued. This is an effect of the prescale being 100 on the zero bias.  If we were to change the prescale to 125, the bars should even out.    I know how to change the prescale, but don't know the password.  Who to call... </a></td></tr></table>
<!-- Author: Ben -->


<!-- Date: Sat Apr 14 22:31:08 2001 -->
<pre>DO Timeout  at 70 K events from COT 13.</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112107' target=_top>112107</a>) -->
<!-- Comment: Sat Apr 14 22;51;53 comment by...Ben -->
HRR works again.


<!-- Date: Sat Apr 14 23:02:20 2001 -->
<pre>After Arnd called with the password for dial-a-prescale, 
stopped run after 100 K events, stopped run to change prescale 
from 100 to 125. 
 
(Tried to do it during the run, but after 15 minutes, it still 
hadn't worked.  Right after the run ended,  the command worked 
easily.)</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112107' target=_top>112107</a>) -->


<!-- Date: Sat Apr 14 23:11:17 2001 -->
<pre>Changed prescale to 125 ... I think. 
TS bunch monitor looks the same. 
When I click on the dial-a-rate button, it says that 
the prescale preset is 100. 
 
So I can't tell if it was changed or not. 
Perhaps it was reset after the COLDSTART ? 
I can try again. 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112108' target=_top>112108</a>) -->


<!-- Date: Sat Apr 14 23:23:38 2001 -->
<pre>Put this in the fix-list for RC. 
 
Tried dial-a-prescale during a run.   
It hung for more than 15 minutes until a new run was started.  
 
Dial-a-prescale did work before I partitioned - very fast.  
However, it wasn't clear it did anything, because when I   
looked at the Trigger Control again (after run was going), in  
 both places it still said the old value, rather than the new.  
 
The next time I tried to do it after a COLDSTART, but before  
ACTIVATE, and it is also hanging. </pre>
<!-- Author: Ben -->
<!-- Comment: Sat Apr 14 23;28;32 comment by...Ben -->
<pre>fter I clicked ABT+RST,  the dial-a-rate finally
acknowledged that I had changed the prescale.  Still, 
when I reopen the window, it does not appear different.
</pre>


<!-- Date: Sat Apr 14 23:30:00 2001 -->
<pre>Still trying to change prescale. 
 
After I changed the prescale to 125, when I try to change 
it again to 125, it says: 
 
Prescale changed from 126 to 125. Apparently, it does not like  
odd numbers. 
 
Can prescales be odd ?</pre>
<!-- Author: Ben -->
<!-- Comment: Sat Apr 14 23;37;55 comment by...Ben -->
<pre>So if I click set twice in a row, I can see what it thinks
it is.

But if I change it to 120. The next time I try to change it,
it says it is 121.

The offset seems to be always up by one.</pre>


<!-- Date: Sat Apr 14 23:49:10 2001 -->
<pre>I give up. 
 
Did a run in which I set the prescale to 98,  it told me that 
the prescale was 99.  I then PARTITIONed, COLDSTARTed,  
ACTIVATEd, ran for a bunch of events, saw that the  
TS bunch display looked the SAME,  then ENDed the Run, ABT+RST, 
then checked the prescale value by asking it to change its 
value again,  
 
It said the prescale was -155. 
  
Got that: 100, 98, 99, -155. 
 
You make the call. 
 
Anyway, it would be be better if a trigger was made specifically 
with  
 
ZERO BIAS/ 125  so we could really know what was set. 
</pre>
<!-- Author: Ben :: (run <a href='/cgi-bin/runSummaryRun.cgi?112111' target=_top>112111</a>) -->
<!-- Comment: Sun Apr 15 06;38;38 comment by...Michael Schmidt -->
<pre>The offset of one is OK; this is a hardware thing.
The negative value is puzzling.  I will look at the
runs offline anyway; the effective prescale can be
determined from the fred counts or rates before and
after the prescale function.  Thanks for trying.</pre>
<!-- Date: Sat Apr 14 23:54:12 2001 -->
<font color=red>Shift Summary: </font><table border=0><td><tr><td bgcolor=#e0e030><pre>Si integration 
  The L3 reformatter didn't know the right barrel ID for L00. Fixed. 
  Still lots of trouble using HEVB: 
    Invalid byte counts in VRB headers (missing words?). 
    Occasional bus errors when reading VRBs. 
  Problems were not solved so Si should remain out. 
 
Calibrations 
  Type    Tried?    Ran OK?     In DB?    Comments. 
  ------- ------    -------     -------   --------------------- 
  Cal-QIE   Y          Y          Y  
  Cal-LED   Y          Y          Y       It took several tries 
  Cal-XEF   Y          N          N       XEF HV didn't come on 
  CLC-QIE   N          N          N       There was uncoalesced beam 
  CLC-LED   N          N          N       No expert present 
  COT       Y          Y          Y        
  MUON      Y          Y          n/a      
  SMX       Y          Y          N 
  TOF       Y          Y          Y 
We still can't figure out why a seemingly good calibration run 
sometimes doesn't get into the database. 
 
Rick run: OK 
 
XTRP00 had to be rebooted once. 
 
L2 tests 
  The L2_RATE_TEST trigger runs without trouble (unlike in the last 
  eve shift). At Mike Schmidt's suggestion we tried changing the 
  ZERO_BIAS prescsale to see if the distribution of L1A's among 
  bunches was changed. We never managed get dial-a-prescale to 
  work properly: it returned unchanged or nonsensical values when 
  we tried to read back the prescale after attempting to set it. 
 
  Mike would like the day shift to try to follow up on this study. 
 
Missing trigger tables? 
  We were supposed to run 1x8_END_1[7,101] and [7,102] but Run Control 
  listed no such triggers, despite having been restarted several times. 
</pre></td></tr></td></table> 
<br><b>End of Shift Numbers</b>
<table><tr><td width=60% align=left>
<b>CDF Run II <p></b>                       
<pre>
Runs                   112049-112111
Delivered Luminosity   0  pb-1
Acquired Luminosity    0  pb-1
Efficiency             0
   
</td></tr></table></pre>
<!-- Author: Steve Tether -->
<!-- Comment: Sun Apr 15 07;40;03 comment by...Michael Schmidt -->
<pre>I checked runs 112108 and 112111 offline and
it appears that the zero bias prescale was
100.  So I would claim that my theory has
not been disproven yet by data and would
still like to request TWO runs back to back
of the L2 rate test (tagging or non-tagging)
with the zero bias prescale set to 100 and
then 125.</pre>