<!-- Title: 14:39:22  Mon Oct  8 2001 -->
<!-- Crewchief: Luciano Ristori -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>Time to start a new page!</pre>


<!-- Date: Tue Oct 9 10:31:18 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-389&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-389  width='300' align='top'></td><td>L2 SVT trigger</a></td></tr></table>
<!-- Author: Stephen -->


<!-- Date: Tue Oct 9 10:37:48 2001 -->
<pre>Run 128419 was run with TWO_TRACK_SVT_v-5 table using SVT 
triggers at L2. Above plot shows successful implementation 
of L2 cuts: d0 >= 100um, Pt >= 2Gev, Chisq <= 25, Ntracks 
satisfying cuts >=2. Black histogram is all SVT tracks, 
Blue histogram is the value for the 2 tracks with the maximum 
(minimum) values for events where the L1 trigger bit was set. 
Red histogram is the same where the L2 trigger bit was set. 
Thanks to Jane and Matt for taking this run. 
This run was taken in tagging mode.</pre>
<!-- Author: Stephen -->


<!-- Date: Tue Oct 9 13:48:17 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-390&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-390  width='300' align='top'></td><td>L2 cutting on jets</a></td></tr></table>
<!-- Author: Stephen -->


<!-- Date: Tue Oct 9 13:50:00 2001 -->
<pre>The above entry is the look area a-stream data from run 128338. 
The L2 jet cutting code appears to be working just fine.</pre>
<!-- Author: Stephen -->


<!-- Date: Tue Oct 9 14:18:22 2001 -->
<pre>Isolation tests: had to remove DCAS crate 4 slot 9 since it 
was hanging up L2 clustering.  Monica will be here tomorrow 
and will look at it.   With the new firmware it appeared 
on the scope that the zero energy cluster problem was  
greatly reduced,  but our software now gives errors in  
unpacking TC2D and the histograms are not reasonable. 
Nathan fixed and tested the Trigmon version with  
isolation in it but it only has the seed information,  
no energies yet.   So we took a lot of data but don't 
know the quality yet.   
Run 128661 had a DCAS cable unplugged as a test.   
Runs 128676 and 680 had all cables plugged in.   
 
Trigmon showed Iso and Clist in sync at all times in all  
runs.  We left Isolist plugged in and request that others 
do so as well unless a problem is seen.</pre>
<!-- Author: Steve Kuhlmann, Bob Blair -->


<!-- Date: Tue Oct 9 20:37:13 2001 -->
Dear God, I even get paged when the entire detector is down... 
 
they tried taking a Rick run tonight.  Our old friend b0l2cl04 wouldn't pass coldstart.  It turns out the real reason was that the ace didn't know the dcas in slot 9 was unplugged, so he didn't know to remove it from the run configuration, and the error messages from RC didn't give any indication of this fact.  I came in and replaced that board (SN40) with the only spare that doesn't have any notes on it about problems - SN39.  Note - when SN40 is plugged in the blue PROP LED is always on.  The crate now works fine.
<!-- Author: hray -->


<!-- Date: Wed Oct 10 11:12:54 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-391&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-391  width='300' align='top'></td><td>All of g stream for run 128338. Note the few events with clusters with lost energy bits.</a></td></tr></table>
<!-- Author: Stephen -->


<!-- Date: Thu Oct 11 20:16:41 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-392&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-392' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-393&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-393' width='300'></a></center>
<!-- Author: hray -->
<!-- Comment: Thu Oct 11 20;22;51 comment by...hray -->
The above plots are from the search for cluster merging.  Ignore the labels - I couldn't figure out how to remove them.  For these runs I had the top connector on DCAS in slot 10 (brd 4) and slot 19 (brd 10) unplugged for DCAS in crate b0l2cl01.  These signals are from the backplane LOCOS for that crate.  Yellow is BRD_HS_SEED4, Green is BRD_HS_SEED10, Purple is BRD_SEL4, Pink is BRD_SEL10.  In the left plot I was triggering on both BRD_HS_SEED4 and BRD_SEL10, a condition which would give the cluster merging that we've seen.  I've triggered on HS_SEED4 going high at 1 V, and BRD_SEL10 going high at 1V, 560 mV, 360 mV, and 280 mV.  The only one of these four which triggered was at 280 mV, which the above picture is taken from.  The right plot is a picture of all 4 traces, under normal running.  Nothing seems out of order.  For these runs I couldn't use L2DE crate - so I couldn't check TrigMon to make sure that the cluster merging was happening.  See today's evening shift elog -> L2DE wouldn't pass partition from the start, and there was some problem with resetting/rebooting any crates.  Luckilly Arnd just walked through the trigger room and offered to change the boot parameters so I can fix the L2DE crate.  Now I can fix that crate and connect the LA to look at more stuff.  more to follow..


<!-- Date: Thu Oct 11 21:04:54 2001 -->
<pre>well, I spoke too soon.  I am still unable to get the l2de crate to work.   
This is what happens: 
b0l2de00-> i 
 
  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY 
---------- ------------ -------- --- ---------- -------- -------- ------- ----- 
tExcTask   excTask        efe738   0 PEND         299530   efe660       0     0 
tNetTask   netTask        edd0b8   1 PEND         27f83c   edd008       0     0 
tPortmapd  portmapd       ed8330   1 PEND         27f83c   ed81c0      16     0 
tRlogOutTasrlogOutTask    e4abf8   2 PEND         27f83c   e4aa70       0     0 
tRlogInTaskrlogInTask     e49668   2 PEND         27f83c   e49440       0     0 
tShell     shell          eaa768   5 READY        283200   ea9730  1c0001     0 
tRlogind   rlogind        ed98c0  15 PEND         27f83c   ed9500       0     0 
tAioIoTask1aioIoTask      eee6a8  50 PEND         27fcb0   eee600       0     0 
tAioIoTask0aioIoTask      ee74a0  50 PEND         27fcb0   ee73f8       0     0 
tAioWait   aioWaitTask    ef58b0  51 PEND         27f83c   ef5758       0     0 
rshelld    eba5c0         ebf870 100 PEND         27f83c   ebf708 ffffffff     0t1         VISIONserver   eb97e0 100 PEND         27f83c   eb96b0       0     0 
t2         ROBINserver    eb47b8 100 PEND         27f83c   eb4678       0     0 
t3         httpDaemon     eaf790 100 PEND         27f83c   eaf578       0     0 
Messenger  FER_messenge   e85bd8 200 PEND+T       27f83c   e85508      44  1788 
tLogTask   logTask        efbdc0 250 PEND         299530   efbcf8       0     0 
value = 0 = 0x0 
b0l2de00->  
b0l2de00->  
b0l2de00->  
b0l2de00->  
b0l2de00-> Message from RTserver: Connection established. 
Start subscribing to subject </_b0l2de00_15227864>. 
FER_smartInitMS: Connected iTry = 0 
Making local Connection...Successful 
Subscribed to >>/setPartition/frontEnd/level2/decision/00<< 
Subscribed to >>/*/vxconfig/frontEnd/level2/decision/00<< 
Messenger: processPartition 2 
Sent ack to Run Control: 2 IDLE SUCCESS  
Messenger: processStatechange Config [0] 
 
so...everything looks okay, but then this is where it stops.   
The minicom window has no response after the partition transition. 
The ALPHA never seems to receive the ColdStart messages?  I've tried 
reset_crate and pressing reset on both ALPHA and the crate.  Now 
I'll try the more drastic power cycle</pre>
<!-- Author: hray -->
<!-- Comment: Thu Oct 11 21;09;23 comment by...hray -->
oh yeah - the alpha_check shows everything is fine -> with the one little exception that the alpha thinks it has a physics_01 table loaded.  Hmmm.  


<!-- Date: Thu Oct 11 22:06:44 2001 -->
Several things: first, I powercycled the crate to no avail. I rebooted the alpha computer, as it was in an odd state after the power outage earlier this week.  Second, I tried unplugging the blue ethernet cable from alpha in 00, hoping to load the exe by hand after cs.  The 00 crate will not pass CS, with errors as listed above, so I can never get to the point of loading exe by hand (I think it needs to be done after cs, please someone correct me if I'm wrong).  I tried 01 crate.  there alpha does load the exe correctly, but this crate also fails in cs, with a different error: 
<br>b0l2de01-> TRACER: VISIONopen Name=geo32:/slot=2 
FISION: S_errno_EIO (0x5): VME BERR received! 
FISION: S_errno_EIO (0x5): VME BERR received! 
FISION: S_errno_EIO (0x5): VME BERR received! 
Cannot configure readout - check readout list. 
Readout process not started. Error status: 1 
Setup failed with error code 5 
Setup failed with error code 1 
Statechange failed  
<br> 
but at least this is a real error and not an unsolvable hang as above.  
<!-- Author: hray -->


<!-- Date: Fri Oct 12 12:41:04 2001 -->
<center><a href='/elog/notebooks/l2/Fri_Oct_12_2001_123947.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-396' ></a><a href='/elog/notebooks/l2/Fri_Oct_12_2001_123959.ps'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-398' ></a></center>
<!-- Author: hray -->
<!-- Comment: Fri Oct 12 12;47;02 comment by...hray -->
Many problems getting started: When I try to run with L2Torture, L2Rate, or Physics_0_01 tables with a cable (one or two) unplugged on DCAS I get CLIST errors - first 0 MB words sent, then bc mismatches.  I ran with L2Torture and two DCAS cables unplugged on Sept 4, so I know this will (should) work.  Above picture: I triggered on the error bit being set to see what was wrong with the events now that I've unplugged cables.  If I put the error bit at the end of the scope memory, for 5 ms before the error bit there is NOTHING.  No traces.  If I center the error bit, or put it at the beginning of the memory I see this : the RH picture, of a L1A coming around 400 us later, but then nothing else for the remainder of the scope memory.  
<br>
Traces:0=L1A, 1=HLNK_LE0, 2=EOE, 3=RCLK, 4=FIFO_EMPTY*, 5=LOC_REQ, 6=DSTROBE*,7=DDONE*,
    8=LOC_BOSS, 9=MB_DONE_OUT, 10=CLIQUE_END, 11=CLIQUE_BUF0, 12=CLIQUE_BUF1, 13=WCLK,
    14=WEN0, 15=WEN1 BACKPLANE: 16=STARTLOAD, 17=DONE0, 18=BUF0, 19=BUF1 


<!-- Date: Fri Oct 12 12:51:04 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-401&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-401  width='300' align='top'></td><td>Trying to look at BOSS signals on backplane to see if CLIST really is really having problems with the BOSS.  Everything looked bad so I tried unplugging CLIST and jumpering and looking at only BOSS from L1Int.  I still see this:  yellow is BOSS,  green is BOSSREQ, purple is BOSSGROUT and pink is BOSSGRIN.  It appears BOSSGRIN is the only signal that looks healthy.  I tried running with FRED and in CalibContinuous, but both gave this  pic? note BOSS scale is ~1/4 that of the BOSSGRIN signal</a></td></tr></table>
<!-- Author: hray -->


<!-- Date: Fri Oct 12 19:41:53 2001 -->
modifed memory allocation in svt cold start code, so that a 
single big malloc is done once (and never freed), which i 
expect to reduce memory fragmentation problems that cause 
svt crates to have to be rebooted.  
<!-- Author: bill a -->


<!-- Date: Fri Oct 12 20:32:10 2001 -->
Steve K came in earlier today when I was fighting with the L2de crate.  With the help of Stephen Miller we tracked down the bad boss/boss always being held high to the termination board on the left hand side of the crate.  We don't understand it, but simply reseating the board made all signals in the crate wonderful again.  I'm going to push on with cluster merging now
<!-- Author: hray -->


<!-- Date: Sat Oct 13 14:17:52 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-402&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-402  width='300' align='top'></td><td>Clist, ISO and L1 are in L2 crate.  Cables are all plugged in on DCAS.  Scope on back shows two boards exerting boss cleanly. LA shows CLIST events appear okay.  Not sure what is happening here. will investigate</a></td></tr></table>
<!-- Author: hray -->


<!-- Date: Sat Oct 13 14:27:21 2001 -->
<table><tr><td><a href=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-403&button=yes target='xxx' onclick='jswindow()'; align=top><img src=/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-403  width='300' align='top'></td><td>picture of scope for previous bad run - traces are correct  as labeled</a></td></tr></table>
<!-- Author: hray -->


<!-- Date: Sun Oct 14 08:39:49 2001 -->
<pre>Starting Iso tests.  Running with cosmics_notracks  
successfully with no problems,  L1,Clist,Iso in and  
sending data reliably.  Studying Iso energies and  
Trigmon/ClusterVal software with Nate.</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Sun Oct 14 11:00:44 2001 -->
<center><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-405&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-405' width='300'></a><a href='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-406&button=yes' target='xxx' onclick='jswindow()'><img src='/cgi/elog/det-system-elog.pl?nb=l2&action=view&page=-406' width='300'></a></center>
<!-- Author: SK -->
<!-- Comment: Sun Oct 14 11;03;10 comment by...Steve Kuhlmann -->
<pre>Having troubles with L2 clustering (I think) with a cable
unplugged.   Left plot for Clist is run 128891 with
cosmics_notrack trigger and all cables plugged in.
Right plot is Clist run 128892 with top cable of DCAS slot 13, 
crate 0 unplugged.   Isolist looks similar in both runs
so it seems L2 clustering right now doesn't like a 
cable unplugged?</pre>


<!-- Date: Sun Oct 14 11:32:52 2001 -->
<pre>Finished with Iso tests.  In the runs with no cable unplugged 
the Iso energies were clearly seen for the first time to be outofsync with the seed information,  showing up  
in the next event.  This tells us where to look when ANL engineers come out this week.  
 </pre>
<!-- Author: SK -->


<!-- Date: Sun Oct 14 20:58:31 2001 -->
<pre>L2 Meeting summary for last week (10/8-10/12) 
Monday: 
  L2 ran succesfully with cutting at the end of the store. 
There were some problems Friday morning, but it wasn't clear 
what the real problem was. A flaky SVT board (which might 
have caused the problem) was replaced Friday evening. 
  Someone should check the error logger to find out how often 
there was a L2 timeout error. 
  Svt cutting was succesfully tested, with an L2 SVT trigger 
correctly cutting on svt track quantities. There are no known 
problems with the Tracklist board design. 
  Electron triggers didn't have much time for testing. The 
alpha code was crashing while evaluating the electron trigger. 
  Isolation board still has some energy bit errors. Steve 
will need the system about 2.5 days a week to work on this. 
  Clustering still has merged cluster, and eta and phi bit errors 
to work on. Heather and Monica will keep working on these. 
  Beam will return on November 17th with collisions a week 
after that. 
 
Wednesday: 
  We need to run on all of the L2 cutting runs and some tagging 
runs to fully characterize the error rate at L2. Nate will 
run his TrigMon code on the data. He will also add ntuple  
creation to his code. This will allow further analysis of  
events with errors. 
  We should be able to make use of the dedicated Trigger group 
disks on fcdfsgi2. Peter Wilson knows what the area is. 
 
Friday: 
   Tape drives don't seem to be working so no validation of 
data yet.  
   Isolation board has energies out of sync with the seed  
information.  
   The MBUS is being redesigned because of the difficulty 
in obtaining RC termination in a SIP package. We will use  
SMT pull down resistor packs and individual caps to provide 
that termination. All/most of the engineering recommendations 
will be incorporated in the new design. These changes mean 
the MBUS won't be available for testing for at least 3 weeks. 
 We need to make plans for setting up the MBUS tests. This will 
be done on Monday when/if more people are present at the meeting. 
 
 
</pre>
<!-- Author: Stephen -->


<!-- Date: Tue Oct 16 21:57:43 2001 -->
<pre>L2 Meeting 10/15/01 
Isolation- The current problem is that the energy data is out 
of sync with the seed location information. This is likely 
due to the fact that it takes longer to make the energy sums. 
  The TrigMon code for Isolation monitoring has been validated 
by comparing to standalone offline validation code. 
 
Data Validation of Cutting Runs- Only data from 2 long runs 
was successfully read from tape. These showed no L1 bit errors, 
and the usual Cluster merging and eta bit errors. The data will 
be reanalyzed to get a count of the number of each kind of error. 
The track plots showed disagreement between TL2D and XTRD, but 
that may all be problems on the XTRP side as no sync errors 
were observed in the online TrigMon plots.  
 
The New MBus - is being redesigned to put the RC termination 
as surface mount parts. The design should be ready towards the 
beginning of next week. The delay in the new bus design will put 
some time pressure on getting the bus tested. 
Peter Wittich and Ted will setup some tests to be done on the 
bus and will initially do them on the current backplane. 
 
Grounding for the Argonne boards will be reviewed.  
 
The final 2 CDF Alpha boards have been assembled and will be  
picked up (from D0) this week.  
 
Steve K. pointed out that the Electron triggers w/o tracks  
can be commissioned with cosmics.  
</pre>
<!-- Author: Stephen -->


<!-- Date: Wed Oct 17 04:40:56 2001 -->
<pre>Studies on cluster merging. Run 129043 to 129050 with all of available crates in + b0l2de00 with only CLIST and L1 Interface cabled (SVT and XTRP Interface have input cable removed, ISOLIST is out). Trigger table is COSMIC_NOTRACKS[3,205] and SMXRs are removed form a lot of CCAL crates. 
 
Create conditions for 2 clusters in the same crate by removing 3 cables from DCAS front panel. I can trigger easily on the error by requiring LOC_BOSS &lt; 1.15 usec which happens only when 5 or less clusters are received in CLIST. 
Connect LA to some of DCAS internal signals (by removing DCAS in slot 20 and IsoPick in slot 21 of b0l2cl00). Found that PROPAGATING hoes on after the first BRD_HSD, even though no BRD_SEL* or TOW_HAS_SD0* is seen. Observed correct FLAG_OUTs 
(0 qnd 1) as well as FLAG_OUT2 being set when cluster skipping conditions are met. Need more investigation.</pre>
<!-- Author: monica -->


<!-- Date: Wed Oct 17 18:02:01 2001 -->
<pre>Tried to get more insight into cluster merging problem. 
Had to spend most of my time trying to understand why CLIST is seemingly losing sync in the old fashion, i.e. not all of the clusters in the event are passed to MB so that FIFO_EF* is always high and CLIST becomes BOSS right after SLOAD* goes low, even if EOE for that event has not been received yet. 
In trying to solve this problem, I swapped CLIST (was SNO 1, now SNO 2) and CLIQUE (was SNO 1. noe SNO 3) without any effect on sync loss. I also tried unplugging L1 Int so that CLIST was the only board in the crate. BOSS, BOSSGIN and BOSSGOUT on the backplane all seemed fine. 
I could "solve" the problem only by reproducing exactly last evening running conditions, i.e. with SVT and XTRP interface boards plugged in the alpha crate and the front panel connector unplugged. Which is like saying that CLIST does behave only if the alpha has to timeout before sending new SLOAD*!  
 
Anyway, by the time I "solved" this loss of sync, I had to give CCAL crates to Rick. When I tried runnig at high rates with L2_TORTURE trigger table but no front-end crates, I could NEVER trigger on the cluster merging condition of last night (LOC_BOSS being shorter than 1.15 usec when two DCAS cable are unplugged). 
So, it is important that "real" cluster come in, even if only cosmics, to be able to study cluster merging and wrong cluster eta (also observed last night).</pre>
<!-- Author: monica -->


<!-- Date: Wed Oct 17 20:33:35 2001 -->
<pre>Isolation trigger tests today:  We started off with   
just the trigger booked and no detector,  making  
clusters "the Michigan way" by pulling out DCAS cables.  
Several runs this way worked perfectly.  In-sync,  perfect  
energy match with expected,  etc.   Then after booking  
the detector and taking a cosmics run we decided to   
pursue what appeared to be stuck bits in eta and phi.   
These were not in the Isolation system,  but in the   
part of the L2 clustering system that sends signals  
to Isolation.  Monica Tecchio fixed these, and then  
the sequence that she detailed above happened.   
Tomorrow we plan to continue with the tests in the morning  
until Stephen arrives. </pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Thu Oct 18 16:42:49 2001 -->
<pre>Isolation thursday:  eventful morning.   I'll try to reconstruct step by step. 
1) 5 boards in: L1, Clist, 2 tracks, Iso. 
2) No detector booked, unplug cable.  Data looks perfect in all 5 boards, the 2 track boards are causing the 600 us timeout as expected. 
3) Book endwalls.  Cal Clustering seems messed up since both 
Clist and Isolist have Ncluster mismatches. 
4) Remove track boards as a test,  coldstart fails due to Clist. This is the spare Clist that Monica put in last night. 
5) Put in other Clist,  changing proms as per Monica's instructions over the phone.  Coldstart and running now works,  
no clustering problems.  Isolist sees eta mismatches, probably due to bad solder joints on Clique like yesterday. 
6) With Monica's instructions put in other Clique.  As we 
saw yesterday eta and phi are fixed for Iso with this Clique,  but a seed is not generated all the time.  This is reproducible.  This is worse than an 
eta-phi mismatch so I put the other Clique back in. 
7) With Matt created a configuration file under the ace 
area, L2_COSMICS_TEST,  that sets up the track boards with fake data and books the trigger, CCAL, WCAL, xtrp, svt.  Run all 5 boards with it and signals on backplane look good and data looks good,  except for eta-phi mismatches in Iso mentioned above.  It's still an open question whether the energy mismatches seen are completely due to the eta phi mismatches or not.  I'm looking into this.  </pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Fri Oct 19 16:09:13 2001 -->
<pre>Reces Tests 
  I was able to create the DTO errors that occur when reading 
Reces. The run used just the lower crate with only the alpha 
and 4 reces boards in. No other crates book in the run. 
Running TEST_RECES_v-2 exe.  
 Start_load timed out at 600us each time. This is because 
MOD_DONE(2) is shorted to START_LOAD on that backplane. 
I would get a DTO error within a minute or less of running. 
I changed the alpha code to ignore that mod_done bit. In that 
mode I never had the DTO error even with reading out all 4  
reces boards. 
  I triggered the LA with the BERR* line on the VME backplane. 
Looking on the Alpha PCI bus, I see the problem is that  
the CIA chip doesn't respond to a vme read (via the universe) 
when the CIA has just read a reces board.  
  Perhaps the crate controller code could be changed so that it 
it retries after getting a vme berr, and only gives a dto if 
it gets several in a row. 
</pre>
<!-- Author: Stephen -->


<!-- Date: Fri Oct 19 17:28:01 2001 -->
<pre>Clique Work 
  
On Clique SN01, I reflowed Q15. Taking cosmic runs 
129231, 129232 
Both Clist and Isolist had good agreement on the number  
of clusters. (although for both there was at least one 
event with an error.) 
For Clist the ntower entry had a lot of errors, but no 
eta or phi errors. 
For Isolist, there were still eta errors, but no phi errors. 
 
I then reflowed B21-B25 and E8-E16 on CLique SN03. For this 
board in run 129233, Clist has lots of ncluster and ntower 
mismatches with just a few eta and phi errors. 
Isolist has just 1 ncluster mismatch, the same eta bit errors 
observed last night and at least 1 phi error. 
 
I will reinstall SN01, since that works better for Clist.</pre>
<!-- Author: Stephen -->


<!-- Date: Fri Oct 19 17:33:31 2001 -->
<pre>The Run Control SoundServer is now running.  You may hear  
warning and error messages from the speakers near  
the b0dap58 and b0dap59 machines. 
 
Only machines in the control room will produce  
audio messages, for obvious reasons.</pre>
<!-- Author: W.Badgett -->
<!-- Comment: Mon Oct 22 09;56;04 comment by...W.Badgett -->
<pre>Sorry, this should have gone in the main shift e-log.</pre>