<!-- Title: 19:49:00  Tue Sep 26 2000 -->
<!-- Crewchief: Jane Nachtman -->
<!-- Op1: &nbsp; -->
<!-- Op2: &nbsp; -->
<!-- Op3: &nbsp; -->
<!-- Op4: &nbsp; -->
<!-- Op5: &nbsp; -->
<!-- Op6: &nbsp; -->
<!-- Notes: -->
<pre>New.</pre>


<!-- Date: Tue Sep 26 19:58:51 2000 -->
The bottom Level 2 Decision crate now has a permanent processor (b0l2de01).  This crate is currently being used for SVTD readout from the SVT/L2 board.  Please contact me (310-403-2236) and/or Bill Ashmanskas if you need to use this crate. 
<!-- Author: Jane Nachtman -->


<!-- Date: Wed Sep 27 09:53:51 2000 -->
<pre>The top crate looks idle.  No log book entry. 
I'm turning off and pushing in my board. 
 
</pre>
<!-- Author: Greg -->


<!-- Date: Thu Sep 28 17:17:07 2000 -->
<pre>To connect to Alpha board use minicom ttyC64.  The connection will change on occasion, I'll try to post the number here. Eventually the connection will be logically connected to b0l2pr00 but the minicom ports need to be fixed. 
 
The Alpha should load and run L2autoconfig whenever there is a powercycle or reset. I've noticed that it doesn't always work on a powercycle due to ethernet problems. Simply resetting the board usually gets it to work. 
 
        </pre>
<!-- Author: Stephen Miller -->


<!-- Date: Fri Sep 29 12:13:52 2000 -->
<pre>I am preparing to use all the L2 Cal and top L2 decision 
crate. I am plugging in all the isolation hardware 
and testing it.</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Fri Sep 29 14:23:54 2000 -->
<pre>I installed all the isolation system.  Right now 
IsoList is in slot 7 with jumper removed.   
I was able to deliver seeds to IsoList, and  
generate the start_load bus mastership,  but  
data is garbage. 
 
In addition,  b0l2cl00 where Clique resides, seems 
to have a vme problem.  I couldn't map the crate 
correctly.  I put IsoClique in b0l2cl01 temporarily 
instead.</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Fri Sep 29 20:30:12 2000 -->
<pre>Date: Wed, 27 Sep 2000 16:05:51 -0500 (CDT) 
From: Bill Ashmanskas <ashmansk@cdf.uchicago.edu> 
To: svt@fnal.gov 
Cc: Frank Chlebana <chlebana@cdfsga.fnal.gov> 
Subject: Re: SVT participation in integration test 
 
(Oops, I got the logic reversed the first time about svtmode.) 
 
I have asked the shift crew to include b0svt01 (daq_svt_tracking_01), b0svt06 (daq_svt_fitter_06), and b0l2de01 (daq_level2_decision_01) by default in integration runs, until further notice.  That implies that the shift crew "owns" those crates, and if we want to use them, we need to ask the permission of the shift crew, not just negotiate among ourselves.  It will be very good for us as a system to have a piece of SVT regularly included in the run, configured, monitored, etc. 
 
When the silicon is not being read out, the "svtMode" run_control parameter should be set to "hfospy" so that the SVT generates its own data internally.  When the silicon is being read out, it is better if the "svtMode" run parameter is left blank, so that the Hit Finders actually process data from the fibers. 
 
This has been OKed by Luciano. 
 
-Bill 
</pre>
<!-- Author: Bill Ashmanskas -->


<!-- Date: Fri Sep 29 20:34:33 2000 -->
<pre>I just tried to start a run with the SVT alone (b0svt01, b0svt06, 
and b0l2de01).  First, b0svt01's coldstart failed because the 
G-init signal was stuck in the asserted state on the master spy 
control in b0svt06.  I cleared this by clearing the "G init 
follows CDF backplane signals" register on the spy control.  Then 
b0svt01 and b0svt06 were OK, but the coldstart in b0l2de01 fails 
with this message: 
 
Sent ack to Run Control: 2 IDLE SUCCESS                                          
Messenger: processStatechange Config                                             
Messenger: processReadoutlist                                                    
Failed To Get Message type <doesn't exist>                                       
Error Processing Readout List !                                                  
Messenger: processStatechange Abort                                              
Sent ack tok tn Control: 2 IDLE SUCCESS                                          
Messenger: processStatechange Reset                                              
Sent ack to Run Control: 2 IDLE SUCCESS                                          
Timed out waiting for r/o list                                                   
 
I don't know how to debug this, so we currently have no way to 
include ourselves in the readout. 
</pre>
<!-- Author: Bill Ashmanskas -->


<!-- Date: Mon Oct 2 08:50:51 2000 -->
<pre>I ama plugging in the FRED interface board for a test. 
I will leave in Steve's board for the moment to see if 
it interferes.  Plus, I don't have any jumpers!</pre>
<!-- Author: Greg -->


<!-- Date: Mon Oct 2 12:21:32 2000 -->
<pre>The reason for failed coldstart on the L2 decision crates was 
that I had implemented a template for their configuration message 
in run control, but not in the run control front end code. The 
type of the message sent on coldstart would not be recognized 
by the code. I have fixed this, although it is not thoroughly 
tested. Sorry for any inconvenience ...</pre>
<!-- Author: Arnd -->


<!-- Date: Mon Oct 2 13:39:57 2000 -->
OK, with that fix, SVT readout is once again working.  
<!-- Author: Bill Ashmanskas -->


<!-- Date: Tue Oct 3 00:51:05 2000 -->
<p> 
Looking at L1A counters and HF ispy counters in b0svt01, b0svt06, 
b0l2de01.  Spy control L1A counters stay in sync in different crates, 
but b0l2de01's spy board doesn't get initialized by R_C, since it's 
not supposed to be in that crate.  Hit Finders in slots 4,5,6,13 
(crate b0svt01) agree with spy control on number of L1A, which is very 
significant: data valid transitions are correctly delimiting events. 
HF14 has lost lock, so thinks it sees an infinite number of 
transitions.  HF15 seems to be counting only 50% of L1A.  B4 data are 
supposed to be phi=2,3 z=2,3, so I should see data in HF14, the one 
with lost lock.  Hmmmm. 
 
<p> 
ispy data in slot 4 is hdi=(e020; x; e022; x; e024; x; e021; x; e023; 
x); chips=(8d-8a; x; 8d-87; x; 8d-87; x; 8d-87; x; 8d-88; x; 8d-87; 
x).  ispy data in slot 5 is hdi=(e220; e321; e222; e323; e224; e320; 
e221; e322; x; e324).  slot 6 seems to be just a bunch of EOR words 
and fill words.  slot 13 is hdi=(e030; x; e032; x; e034; x; e031; x; 
e033; x).  slot 15 does not at all resemble data. 
 
<p> 
I think this implies that B4 data are in slot 5.  Hmmmm.  
<!-- Author: Bill Ashmanskas -->


<!-- Date: Tue Oct 3 09:53:40 2000 -->
<pre>I will be using b0l2cl01 and b0l2de00 for awhile for 
Isolation trigger tests.</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Tue Oct 3 11:16:12 2000 -->
I switched the set of SVT initialization constants to the set named <FONT COLOR="#FF0000">nom_wide_fakeXFT</FONT>.<BR> 
See the <A HREF="http://www.pi.infn.it/~punzi/SVT_config.html">svt config Web page</A> for details.
<!-- Author: Giovanni Punzi -->


<!-- Date: Tue Oct 3 11:42:48 2000 -->
<pre>I am finished with l2cal and l2decision crates. 
I only used b0l2de00 and b0l2cl01 but both worked 
with no problems.</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Tue Oct 3 13:09:36 2000 -->
I changed the Merger DIP switch settings in b0svt01.16 to reflect the fact that (I thought) B4 data were coming only from the HF in slot 13.  As it turns out, the correct slot is 5.  (Physical wedges 2 and 3 will appear on the fibers for wedges 2 and 4.  Unfortunately, we had been looking at the fibers for wedges 3 and 4.)  I will make another entry when this is fixed.
<!-- Author: Bill Ashmanskas -->


<!-- Date: Tue Oct 3 14:49:16 2000 -->
b0svt01.left, b0svt01.right, b0svt02.left, b0svt02.right are now mapped to wedges 2, 4, 3, 5.  I edited the metaKey values in the 
hardware database.  Note that the spy board names are thus 
changed to w02w04 and w03w05.  I also changed the merger DIP 
switch settings in wedges 2 and 3 to expect only inputs A and C, not B or D (corresponding to the middle Hit Finder, barrels 2,3). 
Probably we should also enable the hold on the Hit Buffer output, 
but I have not done this.  
<!-- Author: Bill Ashmanskas -->


<!-- Date: Tue Oct 3 15:19:14 2000 -->
JDL is helping us debug b0svt02 TRACER problem.  Also, crate CPU from b0svt04 will be returned (was a loaner 2308), b0svt01's 2301 will move to b0svt04, b0svt03 will get a 2301, and b0svt01 will get a 2304.
<!-- Author: Bill Ashmanskas -->


<!-- Date: Tue Oct 3 17:57:46 2000 -->
b0svt02 tracer problem was traced to swapped fibers on east side of 1st floor patch panel (crates 2 and 7 were swapped).  fixed. 
b0svt02 and b0svt04 are now 2304s, but it appears that some 
tweaking is needed to get software working fully on them. 
b0svt07 is a new 2301.  b0svt03 is the 2301 that used to be 
b0svt02.  we decided to leave b0svt01 intact for now, since it 
works and is part of integration; it will be replaced with a  
2304 as soon as b0svt02 is demonstrated to work with run control.
<!-- Author: Bill -->


<!-- Date: Tue Oct 3 17:58:14 2000 -->
<pre>I am starting the random test for b0svt03 (ph=7).</pre>
<!-- Author: Alexei Semenov -->


<!-- Date: Tue Oct 3 22:40:01 2000 -->
Spare cables and front panels have been moved to SVT locker on first floor.  Loopback cables from HB output to Merger A input in unused crates is now a short gold cable, for neatness.  Cabling 
between crate 6 and crates 1,2 is much cleaner.  Crate 6 has been rearranged a bit: xtrp emulator in slot 20, HF (for ospy loop of 
fake xtrp data) is in slot 21 (and hardware DB updated, so that 
board can be initialized by run control), merger to fan out these 
two boards' data to wedges 2,3 is in slot 18, merger to fan in 
wedge 2,3 data and forward to jane is in slot 17.  Slot 19 must remain empty for clearance to slot 20.  Track fitters 
are currently bypassed, but it is simple to insert them later in 
the week.  We can now book, initialize, and run b0svt02, which 
is a 2304.
<!-- Author: Bill Ashmanskas -->


<!-- Date: Tue Oct 3 23:27:15 2000 -->
b0svt01, b0svt02, b0svt06, and b0l2de01 are now back in the integration test (b0svt02 for the first time).  new map files are compressed (using my ad-hoc compression for now), because coldstart is otherwise unacceptably slow (we were last by a large margin to complete the coldstart before the compression).  i do not understand pattern of which HFs in wedge 3 do/don't see data, and i suspect a cabling problem.  will investigate tomorrow.
<!-- Author: Bill -->


<!-- Date: Wed Oct 4 14:47:10 2000 -->
<pre>Testing  the Cluster List L2 Calorimeter Interface board( 
slot 14):  Successfully transfered 0-5 MB long words in a burst 
mode in successive simulated 'events'.  The Mod_Done bit was 
correctly sent as well.  Of interest: both the ISO-LIST and 
Global L1 interface cards were in the crate in lower numbered 
slots.  Neither board interfered with the MB bus mastership 
protocol.  </pre>
<!-- Author: John Carlson -->


<!-- Date: Wed Oct 4 21:46:08 2000 -->
<pre>Corrected 2 MB data bus shorts.  MD_DATA bits 121 and 122, pins 
B27 and C27 on the MB, were shorted together on the slot 3 MB 
termination board.  Secondly, pin A23(MD_DATA(101)) in slot 13 
on the transition board side was bent out of position touching 
a ground pin.  Bent back into place. 
</pre>
<!-- Author: John Carlson -->


<!-- Date: Thu Oct 5 00:14:47 2000 -->
I had asked the shift crew not to include SVT for a few hours this evening, while I tinkered.  New shift now knows that it is available again for integration.  Crate 2 slot 5 Hit Finder fibers are cabled correctly, through splitter rack, to  
blue and orange fibers of 
FIB fiber bundles S245 and S345.  I still don't understand why I see lost lock on all four fibers.  If I move fibers to adjacent slot, the lost lock condition moves with the fibers.  So I disabled the merger input (crate 6, slot 17, B) corresponding to crate 2 for now, so that we don't merge a bunch of error words with presumably good data from crate 1.  Also, much more initialization is now done in Hit Finder coldstart routine.  cvs (svtvme library) and development updated, crates 1,2,6 rebooted, coldstart runs without crashing, interactive inspection of memory contents shows that new code seems to do what it is supposed to do. 
<p> 
Incidentally, it would be nice if each individual fiber at the splitter rack were labeled, so that one didn't have to trace them through lots of spaghetti to find the cable bundle, whose label is often obscured anyway.
<!-- Author: Bill Ashmanskas -->


<!-- Date: Thu Oct 5 13:26:41 2000 -->
<pre>Work proceeded on Isolation trigger this morning with  
Stephen Miller.  Up to 24 seeds per event were  
read out successfully.  No failures were seen when  
the buffer number was a fixed value,  but once again  
a few relatively rare failures were seen when the buffer 
number was changed continuously.  These failures were 
studied and documented in more detail. 
 
At one point Stephen speculated that the L1 card was writing 
data to the same address List was expecting. The L1 card 
was pulled out (again) as a test.  Errors were seen after 
this as well but perhaps not of the same type as before. 
This isn't clear.  The L1 card is not plugged in at the  
moment.</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Thu Oct 5 17:26:23 2000 -->
<pre>The L2 processor can now have its executable automatically 
loaded by Run Control. The executable loaded is  
L2_physics table name. Currently we don't have an executable for  
each physics table. Have a set a soft link from L2cosmicrun to 
L2_COMMISSIONING_TABLE_2_v-5.  L2cosmicrun gives autoaccepts 
on every event, and does fill most of TL2D bank. 
 
</pre>
<!-- Author: Stephen Miller -->


<!-- Date: Thu Oct 5 17:41:25 2000 -->
Implemented loading of memories from gzip-compressed data files. 
Gzipped data files used for wedges 0,2,3,4,5.  Tested on crates. 
Am now implementing checksumming of memories to further speed 
up initialization.  Will unbook crates now and test checksum code 
later tonight.
<!-- Author: Bill -->


<!-- Date: Fri Oct 6 04:01:54 2000 -->
<table><tr><td><a href=/elog/notebooks/l2/Fri_Oct__6_2000_040129.ps align=top><img src=/elog/gifs/ghost64.gif  width='56' align='top'></td><td>PEMDETower Energy and occupancy</a></td></tr></table>
<!-- Author: Subir Sarkar -->


<!-- Date: Fri Oct 6 04:04:58 2000 -->
Sorry, my mistake
<!-- Author: {Quick_Entry} -->


<!-- Date: Fri Oct 6 14:28:15 2000 -->
JDL is about to upgrade b0svt01 to a 2304  
<!-- Author: Bill -->


<!-- Date: Fri Oct 6 20:14:49 2000 -->
Thanks to JDL, b0svt01 is now an MVME 2304.  svtvme library now contains svtvme_smartWriteFromFile, which reads e.g. hb_w02.HB-ROADS.cksum (if it exists) and does not bother reading the contents of hb_w02.HB-ROADS over the network if the checksum matches the VME memory.  Also, if a gzipped file hb_w02.HB-ROADS.gz exists, it is used instead of hb_w02.HB-ROADS.  With this change, typical SVT coldstart time is about 10 seconds, and amazingly enough is signficantly slowed down by terminal I/O.
<!-- Author: Bill Ashmanskas -->


<!-- Date: Fri Oct 6 23:36:39 2000 -->
Aaron (ace) and Steve N took some data with SVX and SVT booked.  
Subir's spy buffer dump program delivered the goods. 
 We now see B4 data in both SVT crate 1 and crate 2.  HDI header word by stream is (where the digits are halfbarrel, wedge, layer)  
 
<br> 
<br>hf b0svt01.05 ispy 0 e220, chip ids 83 82 
<br>hf b0svt01.05 ispy 1 e321, chip ids 85 84 83 
<br>hf b0svt01.05 ispy 2 e222, chip ids 89 88 87 86 85 
<br>hf b0svt01.05 ispy 3 e323, chip ids 89 88 87 86 85 84 
<br>hf b0svt01.05 ispy 4 e224, chip ids 8d 8c 8b 8a 89 88 87 
<br>hf b0svt01.05 ispy 5 e320 
<br>hf b0svt01.05 ispy 6 e221 
<br>hf b0svt01.05 ispy 7 e322 
<br>hf b0svt01.05 ispy 8 (missing) 
<br>hf b0svt01.05 ispy 9 e324 
<br> 
<br>hf b0svt02.14 ispy 0 e230 
<br>hf b0svt02.14 ispy 1 e331 
<br>hf b0svt02.14 ispy 2 e232 
<br>hf b0svt02.14 ispy 3 e333 
<br>hf b0svt02.14 ispy 4 e234 
<br>hf b0svt02.14 ispy 5 e330 
<br>hf b0svt02.14 ispy 6 e231 
<br>hf b0svt02.14 ispy 7 (missing) 
<br>hf b0svt02.14 ispy 8 e233 
<br>hf b0svt02.14 ispy 9 e334 
<p> 
Tomorrow I will make the HF coldstart routine intelligent enough 
to deal gracefully with programmable chip ids, sensible barrel 
number setting (from metaKey value), and disabled channels.  A 
separate question is whether we should attempt to fetch such  
information from the hardware database. 
 
<!-- Author: Bill -->


<!-- Date: Fri Oct 6 23:54:16 2000 -->
Other things to do tomorrow: 
<ul> 
<li>compare merger A and C spy buffer data to see whether bunch IDs match 
<li>put unused hit finders into some sort of idle test mode, so that they don't blink eerily (and misleadingly) out of synch with L1 trigger 
<li>are there uninitialized registers in spy control coldstart?  it seems that not all possible freeze conditions are cleared at startup. 
<li>try to validate hit finder data processing with simulation (at the spy buffer level) 
</ul>
<!-- Author: Bill -->


<!-- Date: Sat Oct 7 02:31:43 2000 -->
<pre>This is the third time CDF DAQ hangs with  
 
b0svt01/02 timeout message. 
Also gives RXTP timeout(!) error 
 
During each of these failures I was running a workstation  
process to set global freeze, read spy buffers and release 
freeze etc. 
 
in any case look at /cdf/people2/sarkar/svtvme/Native/example 
directory for a few dump files I have managed to collect.  
I have hopefully attach correct run numbers.  
 
It happens again with 01. So I think it is wise not to run 
my program before I understand what I am doing wrong.  
 
</pre>
<!-- Author: Subir Sarkar -->


<!-- Date: Sat Oct 7 05:38:31 2000 -->
<P> 
I cannot not run any of my spy buffer reading programs  
from the unix machine. As a test I tried to run the  
same program, which has already been working both from Unix as 
well as within vxworks many many times earlier today.  
 
<P> 
The program ran merrily as a crate process and read the  
buffers continuosly, but createed a SVT_TRACKING_0n time out  
error immediately when run from Unix. The ACE has been kind enough to let me do this test quite a few times. I still do  
not understand the source behind this destructive interference, 
though.
<!-- Author: Subir Sarkar -->


<!-- Date: Sat Oct 7 06:27:51 2000 -->
I have found that both b0svt05 and b0svt06 are  
master enabled. I do not know whether this has  
any implication on what's going on  
<!-- Author: Subir -->


<!-- Date: Sat Oct 7 08:03:23 2000 -->
<pre>I'll be using L2CAL and L2DECISION for a couple of hours, 
or until I'm knocked off.</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Sat Oct 7 10:49:30 2000 -->
<pre>I moved the IsoClique to b0l2cl00 (where it is  
supposed to be since that is where Clique is). 
I sent seeds and read them out with the  
alpha ok.  But the alpha seems to want to 
produce FISION errors and hang up every 10-15 minutes,   
and needs to have the reset button hit.   
Right now "Track #1" and IsoList and L1 Global 
are all in the crate. I am finished for the day.</pre>
<!-- Author: Steve Kuhlmann -->


<!-- Date: Sat Oct 7 14:23:32 2000 -->
I am taking b0l2de00 for some tests with the alpha and SVT/L2 board (aka Track #1).
<!-- Author: Jane  -->
<!-- Comment: Sat Oct  7 15;28;19 comment by...Jane -->
I'm also taking b0l2de01 for a few minutes. 

<!-- Comment: Sat Oct  7 16;05;16 comment by...Jane -->
I'm finished with b0l2de01 now. 

<!-- Comment: Sat Oct  7 16;14;29 comment by...Jane -->
I am finished with b0l2de00.  I found the same sort of problems that Steve mentioned, with the alpha hanging every once in a while.


<!-- Date: Mon Oct 9 12:09:01 2000 -->
I am using b0l2de00 for some tests.  If someone else wants to use it, please let me know.
<!-- Author: Jane (310-403-2236) -->
<!-- Comment: Mon Oct  9 12;39;00 comment by...Jane -->
I am also using b0l2de01, svt_fitter_06, and svt_tracking_01 and 02.

<!-- Comment: Mon Oct  9 14;34;33 comment by...Jane -->
I am no longer using the SVT crates and b0l2de01.


<!-- Comment: Mon Oct  9 17;53;15 comment by...Jane -->
I am finished with b0l2de00.
<!-- Date: Mon Oct 9 15:16:56 2000 -->
I implemented a trivial SVT polling program, which runs on 
b0svt02 automatically upon startup and updates once per minute. 
I am embarrassed to say where the output currently is spooled (it will change ASAP), 
but you can look at a recent snapshot at 
<p> 
<a href="http://hep.uchicago.edu/~ashmansk/temp/svtstat.dat">http://hep.uchicago.edu/~ashmansk/temp/svtstat.dat</a>
<!-- Author: Bill -->



<!-- Date: Mon Oct 9 19:27:43 2000 -->
Following Luciano's instructions, we now inject a set of fake hits into each event (alternating between a set that will fire a pattern in wedge 2 and a set that will fire a pattern in wedge 3), so that each wedge should see a track in every other event, and each event should see one track, even if there are no (meaningful) real silicon hits.  The boards fire the road that is predicted by Guram and Vladimir.  
<!-- Author: Bill and Stefano -->


<!-- Date: Tue Oct 10 08:55:37 2000 -->
We are taking Level 2 Decision 00 and 01, and SVT crates : Fitter 06 and Tracking 01 and 02.
<!-- Author: Greg and Jane -->
<!-- Comment: Tue Oct 10 11;11;55 comment by...Jane -->
We're finished for now. 


<!-- Date: Wed Oct 11 10:23:02 2000 -->
<pre>We are using L2 crate to test handshake protocol with the TS. 
The TS with new prom hangs on the final part of the handshake, 
and goes into state 23 which is an undefined state. 
We'll put old prom into TS. 
</pre>
<!-- Author: Stephen Miller -->
<!-- Comment: Wed Oct 11 17;59;29 comment by...Stephen Miller -->
We changed the prom in TS 6. That had no effect on the behaviour.
We changed the prom back to version 40.


<!-- Date: Wed Oct 11 21:21:04 2000 -->
It is currently not possible to include SVT crates in the integration tests, because their presence causes an immediate run failure due to busy condition in b0svt0[126].  Cause is not understood.  I currently have no way to know whether or not it is due to any recent change.  As far as I can tell, we have not been included in integration tests since 8:30 AM on 10/10, so there is a fairly large time window in which trouble could have started.
<!-- Author: Bill Ashmanskas -->


<!-- Date: Thu Oct 12 13:37:38 2000 -->
Thanks to Jim Patrick, a temporary fix is now in for conflict between HEVB and SVT, but can't be tested until next time SVT is included in integration. 
See today's day shift main logbook.
<!-- Author: Bill -->


<!-- Date: Thu Oct 12 17:22:45 2000 -->
<pre>I am finished with L2-TS tests. The problem is not solved and 
will require Andrew to figure it out. For now it still is  
possible for interface boards to do tests with standalone VME  
code. One can also use run control, and the crate will be readout 
for the first event, but then a HRR will be necessary to  
continue each time. 
 
Also, now connect to the alpha using minicom port ttyC65. 
 
</pre>
<!-- Author: Stephen Miller -->


<!-- Date: Thu Oct 12 18:49:53 2000 -->
taskDelete svtvme_mon on b0svt01 and b0svt02 while 
starting Subir and myself histogram and monitor program.
<!-- Author: marco rescigno -->


<!-- Date: Thu Oct 12 18:50:24 2000 -->
SVT plan for the next day (as of today's 4pm SVT meeting) 
<p> 
<ul> 
<li>Marco and Stefano will look at output of a run taken by 
shift crew today and check that the expected Hit Buffer output 
actually appear in the SVTD bank 
<li>UnKi and Bill will get initial version of Track Fitter coldstart code into svtvme library 
<li>Marco and Subir will continue to develop and test spy buffer monitoring 
<li>Stefano will continue to try to understand Hit Buffer behavior from spy buffer dump files 
<li>Bill will continue to try to understand Hit Finder behavior using offline svtsim with SIXD data from run 100892 
<li>We plan to take data next shot (tomorrow, we think) with Hit Buffer output written to SVTD.  Once we feel that we understand that, we will insert the Track Fitters. 
</ul>
<!-- Author: Bill Ashmanskas -->


<!-- Date: Thu Oct 12 19:50:06 2000 -->
<pre>b0svt01 , b0svt02 rebooted.  
Should be back to the *normal* state.  
crate b0svt01,b0svt02,b0svt06 are now excluded 
to let Bill test TF cold start. 
</pre>
<!-- Author: marco rescigno -->
<!-- Comment: Thu Oct 12 20;23;49 comment by...Bill -->
I am able to work parasitically with b0svt06, so I do not
need to have any crates allocated to me in order to keep
working on TF coldstart. I turn them back to Ace.


<!-- Date: Thu Oct 12 21:51:25 2000 -->
<pre>TF coldstart routine is in, but currently has phony name 
svtvme_tf_coldstart1(), because there is a mismatch between 
memory image and flash RAM data for coefficient and phi0 
(they are interchanged).  Once this is fixed, I will change 
the name, and the coldstart routine will run automatically 
when each run starts. 
<p> 
(TF coldstart coded by Sarah, Un-Ki, and Bill) 
</pre>
<!-- Author: Bill Ashmanskas -->


<!-- Date: Thu Oct 12 21:55:45 2000 -->
Changed HF strip Q cut from 2 counts to 4; changed cluster 
Q cut from 5 counts to 10.  Changed limit on number of 
clusters per ladder from 10 to 100.  Changed number of 
spy buffer words per sample from 500 to 5000.  Should take 
effect with next reboot of b0svt0[12].  
<!-- Author: Bill -->


<!-- Date: Thu Oct 12 23:13:38 2000 -->
<pre>Looked at SVTD bank during non-SVX run. It is OK. I looked with Trigmon ( setup cdfsoft2 development then  runTrigMon 0 (make sure with Ace partition is 0) then it dumps SVTD at each event) and indeed the simulated track is there for each event. A good run to look at offline is e.g. 101262. I looked at Spy Buffers in last Mergers and they are also OK. Bill's spydump is not on the web, although process is running, maybe copy to uchi is busted.</pre>
<!-- Author: Stefano Belforte -->


<!-- Date: Fri Oct 13 00:45:32 2000 -->
As it turns out, the svtvme Makefile (inherited from some old 
cdfvme code) does not include dependence of object files on 
include files, so .c files are not necessarily recompiled when 
.h files on which they depend are modified.  I changed the  
include files today several times while merging Track Fitter 
code with the rest of the library, and evidently should have done a 
"gmake clean" on the development directory.  I now have in my 
"update" scripts a "gmake clean" before "gmake" to work around 
this problem.  We really should use some sort of make-depend 
mechanism to include these dependencies in the Makefile.  I 
recommend rebooting all SVT crates at the earliest opportunity. 
<p> 
This, by the way, is why my monitor task was failing this 
evening.
<!-- Author: Bill Ashmanskas -->


<!-- Date: Fri Oct 13 11:42:39 2000 -->
Temporarily stopped svtvme_mon in crates b0svt01 and 
b0svt02. Rebooted as they were not responding to RC.  
<!-- Author: Subir -->


<!-- Date: Fri Oct 13 12:22:36 2000 -->
When svt_spy_manager is included, the run cannot be started. 
But the message is not clear enough to indicate that 
the svt_spy_manager is really responsible. We  
must find a way to get data from the crate without  
being a part of the run somehow. Time is precious now and  
Bill does want to make sure with svtvme_mon that  
everything is fine. So we may not play with a process which  
is still in debug stage. 
 
Bill will let me know when he is satisfied with his test 
so that we can start trying our stuff out again.
<!-- Author: Subir -->


<!-- Date: Fri Oct 13 14:47:41 2000 -->
Some heap corruption showed up in the Messenger task, so 
b0svt01,2 didn't respond to a halt message.  While I do 
not see any evidence of a bug, I changed svtvme_mon to 
allocate memory just once and never free it.  This will 
take effect next time crates are reloaded.  (And I rebooted 
b0svt05 just to test it somewhere.)
<!-- Author: Bill -->
<!-- Comment: Fri Oct 13 18;48;15 comment by...Bill -->
This "fix" temporarily introduced a big leak, now filled.

<!-- Date: Fri Oct 13 17:52:42 2000 -->
R_C showed heap corruption again in Messenger task. 
I suspect a memory leak in ColdStart code, so I am 
taking b0svt05 to exercise coldstart for a while.
<!-- Author: Bill -->
<!-- Comment: Fri Oct 13 18;22;39 comment by...Bill -->
Coldstart does seem to leak a bit, but only on the order of
100 KB per iteration, so it doesn't seem very plausible that
this is why the crates run out of memory.




<!-- Date: Fri Oct 13 19:38:15 2000 -->
SVT is in the run, recording spy buffer snapshots, and not 
leaking memory (at least not very fast, if at all).  I see 
silicon data in HF input spy buffers except w2b2l3 and w3b3l2, 
which were also missing in run 100892. 
<p> 
In run 100892's data, about 7% of channels appear to have 5% 
occupancy or higher.  Excluding hot channels, occupancy is 
about 1%.  
<!-- Author: Bill -->