<!-- Title: 09:44:46  Wed Jan  2 2002 -->
<!-- Crewchief: Wayne Newton -->
<!-- Op1: Liberace -->
<!-- Op2: Victor Borge -->
<!-- Op3: Steve and Edie -->
<!-- Op4: Pavoratti -->
<!-- Op5: Raffi -->
<!-- Op6: Barney the Purple Dino -->
<!-- Notes: -->
<h1>Welcome to 2002</h1> 
My Plan (no sign of anyone else who is concerned)<ul> 
<li> Access at 11:00 to fix FIB_00 
<li> Attempt to roust EVB people to fix ATM switch during access 
<li> Install new software as default 
<li> Go find Ken and get fib firmware ironed out 
</ul> 
Will attempt to hunt down others who may care to get in on this 
access, but priority goes to fixing VRB crate (my decision-come 
to the trigger room and argue with me...)


<!-- Date: Wed Jan 2 09:51:48 2002 -->
<h1>Foiled Again!</h1> 
OPS managers decided during tomorrows studies (24h, starting 
at 8 AM) would be a better time to fix the EVB so we can 
use L00 in CDF.  Other Access plans (3 Hour Access, starting at 11)
<!-- Author: SCN -->


<!-- Date: Wed Jan 2 11:59:23 2002 -->
<pre>Plan - as devised by Lester, Mary, Steve N., Jean 
------------------------------------------------- 
1. Access - change VME PS 
2. During Access - steve installs new software, brings 
   all VRB firmware up to latest firmware 
3. during maching studies tomorrow, fix ATM switch for L00 
4. Steve works with Ken on new VRB firmware - V15 - install 
    as soon as ready and tested 
5. Steve - X-mode 
6. debug duplicate channel, 00f3, etc problems 
    that have been identified</pre>
<!-- Author: Jean -->


<!-- Date: Wed Jan 2 12:51:30 2002 -->
<ul> 
<li> New software installed.  At some point, SB3W8L0 had an external trip.  After power cycling SB3W7L0 accidently, 
I turned it on and it initialized fine.  However, seems  
the "auto-booting" mode puts all currents to pink in 
IMON.  Clear them and they go away, but maybe not until after 
a real init.  Will try to understand this and perhaps toss 
a handshake init into the auto-boot procedure to ameliorate 
this. 
<li> Going into the access to "back out" FTMs in b0fib00, so they 
don't get destroyed when the PS swap happens.  We haven't seen 
them get killed before, but we don't have enough spares 
to replace them, so this is a sane idea.  Everybody else out 
to lunch, so I make this decision alone... 
</ul>  
<!-- Author: SCN -->


<!-- Date: Wed Jan 2 14:28:30 2002 -->
<pre>b0fib00 back up, will leave the onlining of it to someone else... 
</pre>
<!-- Author: SCN -->
<!-- Comment: Wed Jan  2 14;41;13 comment by...SCN -->
OK, I turned all the FIBs back online, but I have no clue
which HDIs should be on and which shouldn't.<BR>
In the future, it should suffice just to turn the
crate offline, and not mess with fib/hdi flags at all.
This already works for the DAQ, i.e. just flipping the
crate online flag is enough to take everything out.  It probably
could work for the PS info as well.
<BR>
Still updating VRBs...


<!-- Date: Wed Jan 2 15:55:26 2002 -->
Updated all Vrbs to firmware of 11/06/01 (aka vrb_1B06.hex). 
Also noted that minicom sessions for b0svx03 and b0svx08 are 
read only, in that you can see what is printed but you cannot 
type.  Typically this is a problem with the termination of  
the minicom lines somewhere.
<!-- Author: SCN -->


<!-- Date: Wed Jan 2 18:17:43 2002 -->
<pre>Switched b0fib00 wedges back on. Used configuration of layers 
that was used in run 135614 
 
Tried a calibration run and got 100% reformatter errors on SCPU  
decoded as FIB_09 Channel 8. If this is true its SB0W5 L3 
 
Noticed SB0W5L4 has nominal IDVDD  = 295 mA THIS IS TOO HIGH! 
</pre>
<!-- Author: Unhappy UnMerry me -->
<!-- Comment: Wed Jan  2 18;40;00 comment by...Boo hoo  -->
<pre>So took SI and ran it in s seperate partition with SEVB 
and got almost 100% reformatter errors where reformatter 
sees

e031 c4c4

It should be getting e032. Took e032 out of the DB and switched
it off and restarted SEVB run. So far &gt;100 events with no
errors.

THERE GOES ANOTHER LADDER. Oh well this wedge
had L3 and L4 already off so barely tracking capable anyway. 
Now its USELESS.
</pre>


<!-- Date: Wed Jan 2 18:56:09 2002 -->
<pre>The silly GUI is turning on the CPC power on wedges that 
ARE NOT in powerset.dat. I checked, redownloaded, restarted  
GUI to no avail.</pre>
<!-- Author: Moi myself -->


<!-- Date: Wed Jan 2 22:37:55 2002 -->
<pre>After consulting with Mary, silicons were turned ON  
although PLOSS is around 25kHz, but stable.</pre>
<!-- Author: Soushi -->


<!-- Date: Wed Jan 2 22:41:20 2002 -->
<pre>persistent pink color of IMon from SB0W2L0, SB0W2L1. 
Both of them are coming from  AVDD: 
 
SB0W2L0 : latest/nominal = 100/305 
SB0W2L1 : latest/nominal = 255/500 
 
Paged Mary. suggested to "end run" and then, "cold start". 
After "coldstart", they are recovered.</pre>
<!-- Author: Soushi -->


<!-- Date: Thu Jan 3 01:16:01 2002 -->
<h3> Morning...</h3> zzzzzzzzzzz<P> 
Oh, excuse me.  Tania paged me about 100% RF errors, all 
coming from e122 (aka SB1W2L2).  At about the same time, 
Steve Miller was getting impatient and wanted to drop Silicon 
from the partition, so we made him run his own damn partition 
and with the software event builder confirmed that these happened, 
even after <ul> 
<li> A Cold Start 
<li> power cycling the ladder 
</ul> 
It is possible that we needed to power cycle the wedge, but 
I am so nervous about unnecessary power cycles that I just 
turned the ladder offline in the hdwdb.(I did it by hand, using sqlplus, so I did not provide a reason I am afraid)<P> 
Tania started a new run and now there are no RF errors.
<!-- Author: SCN -->
<!-- Comment: Thu Jan  3 09;50;39 comment by...SCN -->
In fact, this is weirder than we thought, for several reasons<ol>
<li> I failed to actually turn "it" off, and was later paged and
we sucessfully turned "it" off.  So apparently the problem
vanished and the resurfaced, or the SEVB was not sensitive to
this (is it the rate, or maybe the calib continuous trigger?)
<li> The one we thought was giving the problems was not
the one we turned off, but they never got running again to 
discover this fact.
</ol>
You can read all about the misidentification <a href=
'/cgi/elog/elog.pl?nb=2002&action=view&page=7&frame=2&anchor=02:42:29'>
here</a> including the anatomy of a Fib ID, which people might
find useful.  I have reenabled the mistaked HDI, but have not
disabled the bad HDI until we see the problem again.

<!-- Comment: Thu Jan  3 10;37;07 comment by...SCN -->
Ace saw 100% RF errors from e122, so I disabled it (FIB_04!).
It is still powered, but not read out.  Should we decide to abscond with Si ourselves, someone ought to try to figure out what is wrong-I would try turning off the ladder/PC and turning it back on, just to rule out that this does not help.  I repeat,
the hope is that with new fib firmware we won't get these 
RF errors, so that these problems which make things
"unrunnable" become "runnable" and we won't have to disable
them-we'll still get some wacky readout, but the event will
make it to tape.


<!-- Date: Thu Jan 3 14:43:14 2002 -->
<h3>Return of L00</h3> 
As can be seen <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=8&frame=2&anchor=14:37:25'>here</a>, they fixed the 
connection between the L00 VRB SCPU and the ATM switch, and 
we ran L00 LB1W0 L0,1,2 at standby for ~ 20 kEvents calib continuous through the HEVB, run number 136151.  It will just 
stay in as default, though it must be hand-biased (Complaints  
about that to D. Stuart)
<!-- Author: SCN -->


<!-- Date: Thu Jan 3 18:27:01 2002 -->
<pre> 
We took the silicon and had a charge injection run (136175) with 
SB4W3L4.  We injected every 16th strip and readout in 
DPS/read-all mode. 
 
Afterward, we put b0fib04 back to its original state. 
</pre>
<!-- Author: Aaron, Gino, Jason -->


<!-- Date: Thu Jan 3 18:59:41 2002 -->
<pre>SB3W1 L4 Vbias reads back 1.1 V even though it's off.  Figuring 
this is an offset in the PS, I am now subtracting it off before 
reporting voltages to the iFix HV summary page (similar to what 
I do for several ISL channels). 
</pre>
<!-- Author: Andy H. -->


<!-- Date: Fri Jan 4 09:30:44 2002 -->
<h3>Suggestions on tossed ladders</h3> 
Both <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=87&frame=2&anchor=18:17:43'>Mary</a> and 
<a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=87&frame=2&anchor=01:16:01'>I</a> had to drop some ladder due to 100% RF errors.  As far as I know, noone 
has gone back to look at them.  Here is what I suggest might be 
done<ul> 
<li> Exclude power cycling as a cure<BR> I would systematically  
reproduce the error and then <ol> 
<li> Cycle the power on just that ladder, see if it persists 
<li> Cycle the power on the PC (which means the whole wedge) and 
see if it persists. 
</ol> 
<li> Troubleshoot the nature of the problem<BR> 
With the help of a DAQ expert, one should be able to put the 
VRB channel in question in WYSIWYG mode (from the Vrb expert 
menu in SVXDAQ) and then manually capture some events.  In 
this mode the VRB will not throw away any data after the 
first EOR characters (i.e. c4c4) so it may (or may not) be 
illuminating to see what happens.  Note both the Reformatter and 
SVXDAQ will have trouble parsing whysiwhg data, but you just want 
an event dump. 
</ul> 
Recent changes to fib firmware may fix this problem, or they 
may just hide the problem by not causing RF errors (still, why is 
there no data?) in which case both of these steps would be necessary anyway.   
<!-- Author: SCN -->


<!-- Date: Fri Jan 4 10:51:18 2002 -->
What are we going to do in the <a href= 
'/cgi/elog/elog.pl?nb=2002&action=view&page=11&frame=2&anchor=09:59:54'>long access</a> next Tuesday? 
<ul> 
<li> Light levels/DOIM RX swaps? 
<li> Bore actions (SB3W5 needs rescuing)? 
<li> PS installation (if we got any...)? 
<li> Divorce 60 Hz from 400 Hz power 
<li> Install CAEN interlock switches to disable power on a crate by crate basis? 
<li> Other things I am forgetting? 
</ul> 
 
 
<!-- Author: SCN -->
<!-- Comment: Fri Jan  4 15;07;17 comment by...Gino -->
<pre>SB2W4 should be resqued as well. (With SB3W5 because 
it has exactly the same simptoms)</pre>

<!-- Comment: Fri Jan  4 16;21;05 comment by...SCN -->
Latest Rumor is Access is Wednesday and Thursday, ~40 h long.


<!-- Date: Fri Jan 4 18:15:00 2002 -->
<h1>7f Problem Solved for SB4W3L4</h1><p> 
Chip id 89 (5th chip on phi side of L4) channel 27 shows the so-called 7f-problem, as can be seen <A HREF="http://ncdf17.fnal.gov/~stuart/errors/ar0212cf.00ba_e434.html.gz">here in David's e-log</A><p> 
 
We took a series of runs with (only this half ladder with the software evb) charge injection to isolate the problem: 
<ul> 
  <li> (Run 136175) Read-all, DPS-on, Charge Injection into every 16th channel: <b> NO ERRORS</b> 
  <li> (Run 136221) Nearest Neighbor sparsification, DPS-on, Charge Injection into every 16th channel: <b>STRIP OUT OF ORDER 1177/4000 events</b> 
  <li> (Run 136237) NN sparse, DPS-on, Charge inj into channels 0-30: <b> NO ERRORS</b> 
  <li> (Run 136249) NN sparse, DPS-on, Charge inj into channels 0-24, 28-29.  Ie, I forced all channels from 0-25, and 27-30 to be readout, leaving exactly ONE HOLE IN THE FIFO FOR CHAN 27 TO COLLAPSE INTO: <b>STRIP OUT OF ORDER 100%.</b>  In this case, chan 27 is 00. 
</ul> 
<p> 
Looking back at the traveller from Berkeley, it turns out that this channel was marked bad by Igor 
 
<h3><b> 
This device is: 
F423z, Q454z, 7p153, chip 4 (counting from 0), die 238-016, channel 27.</b></h3><p> 
 
<h2><font color = ff0000>Conclusion 
<ul> 
  <li>FIFO collapse fails for this channel.   
  <li>At least some of the other 7f-problems are probably the same since some of them always happen to one channel in the same chip. 
  <li>This was a known bad channel from chip testing. 
  <li>As long as we readout out neighbors, we can actually correct for this error offline. 
  <li>Could also work around this by running chip in readall. 
</ul> 
</font></h2> 
Aaron, Jason, Gino, Lester, Tony, and of course Steve N.
<!-- Author: Aaron -->


<!-- Date: Fri Jan 4 18:28:14 2002 -->
<h2>New Fib Firmware</h2> 
Installed on Fibs for SB0W0/W1 and SB1W2/W3, and seems to work fine.  I even reintegrated SB1W2L2, which had 100% RF errors, 
and took runs 136258/136259, and didn't see any RF errors. 
Someone should look at the data to see what this HDI gave, 
but it is now "runnable" (albeit at a low rate due to the SEVB). 
I ran them both with all channels enabled and only with 
the channels with ladders read out enabled, and with standard 
rc, and they worked fine.  Page me if there is trouble. 
Tomorrow perhaps we can apply it elsewhere.  
<!-- Author: SCN -->


<!-- Date: Sat Jan 5 00:14:00 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030>CDF ERRORS CAUSE DVDD TRIPS!!! 
<p> 
On this Friday evening's shift, the SVT experts added the 
capability for SVT to pull CDF errors. Each time an error was pulled, LADDERS TRIPPED WITH DVDD overcurrent! On one occasion 
everything except L00 and about 5 SVX wedges tripped off. 
<p> 
This is not good. 
<p> 
I have persuaded Bill Ashmanskas to switch of this capability 
for now. He will make Steve's life misery until this problem is fixed.<p> 
</td></tr></td></table>
<!-- Author: Joel -->
<!-- Comment: Sat Jan  5 07;47;34 comment by...SCN -->
Theory: When you pull CDF error, the TS issues HALT.  When
the SRC is in HALT, you don't get keepalives.  It is known that
some ladders don't like this, perhaps this is dependent
on the state of the ladder.  The subsequent "RECOVER" 
restores the keepalives etc-thus it is known one should not spend too much time in HALT.  If the shifter does not notice that
CDF Error has been pulled, his reaction time to go from the HALT
state to the RECOVER state may take awhile.  Unfortunately, 
I don't think banning the pulling of CDF Error is really the solution...maybe we can keep the SRC from revoking the 
sending of keepalives, but I suspect this is a major breach of
CDF protocol since HALT means HALT.  If we have to do this, someone else can try to figure out the SRC errors wihtout HALTING
the SRC (it's hard to hit a moving target...)<P>
Is the SVX4 chip going to need as much TLC as the SVX3?
<!-- Comment: Sat Jan  5 10;20;58 comment by...Bill -->
No, I don't want to make Steve's or Lester's life misery, but I do hope
that this problem has an easy fix.  The problem being reported
by CDF_ERROR was real, i.e. we were overwhelmed with track
candidates in W3, and as a temporary fix we simply stopped looking at W3.  Our workaround, until we are able to use 
CDF_ERROR, will have to be to send an error code down to L2,
and hope that it forces a L2 decision timeout on our behalf.

<!-- Date: Sat Jan 5 04:40:37 2002 -->
<pre>SB5W8 L2 tripped on bias overcurrent.  Raised Imax, 
and turned it back on without trouble.</pre>
<!-- Author: ADF -->


<!-- Date: Sat Jan 5 07:15:21 2002 -->
<pre>SB4W6L3 was causing repeated init failures. I got Bill to take 
it out. I changed CAENvolts.dat, but in hindsight forgot to  
load it.</pre>
<!-- Author: Lester -->
<!-- Comment: Sat Jan  5 07;41;35 comment by...Lester -->
<pre>CAENvolts loaded to reflect change</pre>



<!-- Date: Sat Jan 5 09:14:32 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Everything OFF for interlock work!</pre></td></tr></td></table>
<!-- Author: Andy H., Eva H. -->


<!-- Date: Sat Jan 5 10:18:49 2002 -->
<pre>Ladders with persistent, high (&gt;1%) error rates in 
b0fib00: 
 
SB1W10 L2 
SB1W2 L4 
SB2W1 L3 
SB2W1 L4 
 
 
</pre>
<!-- Author: ADF -->
<!-- Comment: Sat Jan  5 11;23;57 comment by...SCN -->
In what sense is SB1W2 L4 bad?


<!-- Date: Sat Jan 5 13:56:48 2002 -->
<h3>Fib Firmware better, but may need work</h3> 
So, I looked for Reformatter errors from any of SB0W0/W1, SB1W2/W3.  I found some, for SB0W1 (31 total) and SB1W2 (9 total) in the runs 
range of 136250-136290.  In each case, the RF error is due 
to a leading 00 byte in the header, as will be demonstrated at the bottom.  However<ul> 
<li> I find in the last running many many problems with byte counts in VRBs and 00f3 rampant all over the 
place last night-in the same Run Range there were <ol> 
<li> 21016 FIB ID errors 
<li> 909 "Imposter Fib" errors 
<li> 289 "Bad Vrb Byte Count" errors, usually in at least 2, sometimes many more, Vrbs in the same event simultaneously 
caught in the SCPUs 
<li> 320 "Bad Channel Counts" where the sum(channels) != total, again often in multiVrbs in the same event, caught in the SCPUs  
<li> 93 "Event ID mismatches", caught in the SCPUs 
<li> 88 Sum != Total errors caught in the Reformatter 
</ol> 
To me, this looks like it was an awfully bad night for 
Silicon, and we need to investigate why. 
<li> The new firmware clearly does fix the c4c4 problem, as none 
of the reformatter errors were of that type.  In fact, e122, which was known to give the c4c4 problem, in the 9 events 
were there were RF errors, now gives its correct fib header and 
c2c2 (still no data...).  For this wedge the RF errors are in  
e123 
</ul> 
so I think the new firmware is as good as the old, i.e. it didn't really introduce a huge amount of new problems.  The leading 
00 byte looks like this: 
<pre> 
Detector ID not known (yet?). 
 FIB ids found: 
  0xe1203bfc  0xe1213bfc  0xe1223bfc  0x00e3203b  0xe1243bfc  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
 
 Error location code: 0x0000c130 
 
 
 Crate Id?: 0x00000000 
 
 Error during scanning MINI structure! 
 Last Unit prob. worked on (all counts from 0): 
  SCPU: 12 
  VRB : 1 
  LINK: 3 
  MINI: 0 
 
 Buffer (51763 until posi+2=51785) 
 0x0636f335  0xf34cf337  0xf34e054d  0x0672f371  0x2b740b73  0x06760f75 
 0x2ca1f377  0x06130112  0xf31d0214  0xf31f061e  0x063cf33b  0x014b013d 
 0xf34d054c  0x05660165  0x0371f367  0x02730672  0xf37f2ca0  0x0000c1c1 
 0xfc3b22e1  0x0000c2c2  0x3b20e300  0xf32ceffc  0x15001402 
 </pre> 
So, the problem ID is 0x00e3203b, and if I unbyteswap the 
relevant dump (last line) of the buffer, I get: 
<pre>e1223bfc c2c20000 00e3203b fcef2cf3 02140015</pre> 
(Note, here you see e122, which formerly only gave c4c4, with its 
header and then a truncate.)<P> 
So, this header input should be  
0x e1 20 3b fc  89 XX and on output should be to be 0x e1 23 3b fc  89 YY....<BR> 
The way the FIB works for channel x is<ul> 
<li> first byte input (e1) is output 
wysiwyg,  
<li> second byte input (20) is modifed for the Channel x of the fib. Lowest 4 bits = x%5 = HDI number, and the portcard bit 
(bit 4) = 1 iff x > 4. For x = 3, 20 -> 23.  If x = 7, 20 -> 32. 
<li> third and fourth byte (BXING and BESTATE) again are wysiwyg 
<li> fifth byte Chip ID is wysiwyg 
<li> sixth byte CAP id might be ungraycoded, 
not sure 
<li> From then  Channels are wysiwyg, data is 
ungreycoded. 
</ul>  So, what do I get if stick a leading 00 byte in 
front of the input:<BR> 
00e1203b fc89XXXX -> 00e3203b fcZZYY <B> 
so the first 40 bits match exactly.</B><BR>  If I take 
89 and ungrey code it, I get 0xf1, not 0xef. Grey 0x81 (=129 dec) gives ungreyed 0xef-(bad bit 3?) then <BR> 
Next byte 2b is input Cap ID, treated as Channel <BR> 
Chan 00 -> f3 treated as data, Data 02 treated as Channel, <BR> 
Chan 1e -> 14 treated as data, Data 00 treated as Channel, <BR> 
Chan 1f -> 15 treated as data<BR> 
You always get first chip first channel (0), then two consecutive ones, so it all holds together except for the Chip ID 89 != 81. 
Anyway, I'm convinced this is what is happening, the only 
question is is it a feature of the new firmware or just a 
consequence of last nights general silicon problem.<P> 
If I grep for this error, I see it is always the same modulo the BXING number in the last byte, which matches the real BXING number in the other channels:<pre> 
b0dap12.fnal.gov% grep -A1 -e "FIB ids" $errorfiles | grep -e "e120" 
errorfile136260.log-  0xe12035fc  0xe12135fc  0xe12235fc  0x00e32035  0xe12435fc  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
errorfile136260.log-  0xe1206dfc  0xe1216dfc  0xe1226dfc  0x00e3206d  0xe1246dfc  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
errorfile136262.log-  0xe12082fc  0xe12182fc  0xe12282fc  0x00e32082  0xe12482fc  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
errorfile136270.log-  0xe12047fc  0xe12147fc  0xe12247fc  0x00e32047  0xe12447fc  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
errorfile136270.log-  0xe1200cfc  0xe1210cfc  0xe1220cfc  0x00e3200c  0xe1240cfc  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
errorfile136270.log-  0xe12000fe  0xe12100fe  0xe12200fe  0x00e32000  0xe12400fe  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
errorfile136270.log-  0xe12012fc  0xe12112fc  0xe12212fc  0x00e32012  0xe12412fc  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
errorfile136270.log-  0xe12012fc  0xe12112fc  0xe12212fc  0x00e32012  0xe12412fc  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
errorfile136281.log-  0xe1203bfc  0xe1213bfc  0xe1223bfc  0x00e3203b  0xe1243bfc  0x00000000  0x00000000  0x00000000  0x00000000  0x00000000 
</pre> 
Unfortunately, for SB0W0/W1, all the problems happen in SB0W1 
(for unknown reasons...) so I cannot do the above grep, as the 
reformatter bug prevents it from displaying the Fib Ids found 
for the lower (second, whatever) PC.  However, I can 
look at the buffer dumps and for the one I looked at the  
problem is exactly the same, but for e010 (i.e. SB0W1 L0).<P> 
OK, now I am dizzy.  But talking to Andy, I think we can go ahead  
and put this firmware in more fibs-this "insert a 00 byte" may 
not even be in the Fib,may be due to other problems last night, or it may be fixable in an upgrade.  It would be nice to see occurances of it a calm period.
<!-- Author: SCN -->


<!-- Date: Sat Jan 5 15:05:11 2002 -->
Running GLINK tests: Get <pre> 
Testing GS2AB SVNWT  Crate 9, Slot 19   to 1RR21GT  Crate 0, Slot 20    Failed 
Testing GS223 SVNWT  Crate 9, Slot 18   to 1RR21GT  Crate 0, Slot 12    OK 
Testing GS201 SVNWT  Crate 9, Slot 17   to 1RR21GT  Crate 0, Slot 11    OK 
Testing GS1AB SVNWT  Crate 9, Slot 15   to 1RR21FB  Crate 2, Slot 20    OK 
Testing GS123 SVNWT  Crate 9, Slot 13   to 1RR21FB  Crate 2, Slot 10    OK 
Testing GS101 SVNWT  Crate 9, Slot 12   to 1RR21FB  Crate 2, Slot 8     OK 
Testing GS0AB SVNWT  Crate 9, Slot 10   to 1RR21FT  Crate 1, Slot 20    OK 
Testing GS023 SVNWT  Crate 9, Slot 11   to 1RR21FT  Crate 1, Slot 10    OK 
Testing GS001 SVNWT  Crate 9, Slot 8   to 1RR21FT  Crate 1, Slot 8      OK 
Testing GIWE2 SVSWT  Crate 10, Slot 10   to 1RR18IB  Crate 8, Slot 12   OK 
Testing GIWW2 SVSWT  Crate 10, Slot 9   to 1RR18IB  Crate 8, Slot 10    OK 
Testing GLW23 SVSWT  Crate 10, Slot 16   to 1RR21IT  Crate 6, Slot 18   Failed 
Testing GICW0 SVSWT  Crate 10, Slot 12   to 1RR18IB  Crate 8, Slot 18   OK 
Testing GIWE4 SVSWT  Crate 10, Slot 11   to 1RR18IB  Crate 8, Slot 11   OK 
Testing GS289 SVSWB  Crate 11, Slot 19   to 1RR21GT  Crate 0, Slot 18   OK 
Testing GS267 SVSWB  Crate 11, Slot 18   to 1RR21GT  Crate 0, Slot 16   OK 
Testing GS245 SVSWB  Crate 11, Slot 17   to 1RR21GT  Crate 0, Slot 13   OK 
Testing GS189 SVSWB  Crate 11, Slot 15   to 1RR21FB  Crate 2, Slot 18   OK 
Testing GS167 SVSWB  Crate 11, Slot 13   to 1RR21FB  Crate 2, Slot 16   OK 
Testing GS145 SVSWB  Crate 11, Slot 12   to 1RR21FB  Crate 2, Slot 12   OK 
Testing GS089 SVSWB  Crate 11, Slot 10   to 1RR21FT  Crate 1, Slot 18   OK 
Testing GS067 SVSWB  Crate 11, Slot 9   to 1RR21FT  Crate 1, Slot 16    OK 
Testing GS045 SVSWB  Crate 11, Slot 8   to 1RR21FT  Crate 1, Slot 12    OK 
Testing GIWW4 SVNWB  Crate 12, Slot 10   to 1RR18IB  Crate 8, Slot 17   OK 
Testing GIWW0 SVNWB  Crate 12, Slot 9   to 1RR18IB  Crate 8, Slot 8     OK 
Testing GLW45 SVNWB  Crate 12, Slot 17   to 1RR21IT  Crate 6, Slot 20   OK 
Testing GLW01 SVNWB  Crate 12, Slot 16   to 1RR21IT  Crate 6, Slot 16   OK 
Testing GICW2 SVNWB  Crate 12, Slot 12   to 1RR18IB  Crate 8, Slot 20   OK 
Testing GIWE0 SVNWB  Crate 12, Slot 11   to 1RR18IB  Crate 8, Slot 16   OK 
Testing GS5AB SVNET  Crate 13, Slot 19   to 1RR21HB  Crate 5, Slot 20   OK 
Testing GS523 SVNET  Crate 13, Slot 18   to 1RR21HB  Crate 5, Slot 10   OK 
Testing GS501 SVNET  Crate 13, Slot 17   to 1RR21HB  Crate 5, Slot 8    OK 
Testing GS4AB SVNET  Crate 13, Slot 15   to 1RR21HT  Crate 4, Slot 20   OK 
Testing GS423 SVNET  Crate 13, Slot 13   to 1RR21HT  Crate 4, Slot 10   Failed 
Testing GS401 SVNET  Crate 13, Slot 12   to 1RR21HT  Crate 4, Slot 8    OK 
Testing GS3AB SVNET  Crate 13, Slot 10   to 1RR21GB  Crate 3, Slot 20   OK 
Testing GS323 SVNET  Crate 13, Slot 9   to 1RR21GB  Crate 3, Slot 10    OK 
Testing GS301 SVNET  Crate 13, Slot 8   to 1RR21GB  Crate 3, Slot 8     OK 
Testing GIEW4 SVSET  Crate 14, Slot 10   to 1RR21IB  Crate 7, Slot 12   OK 
Testing GIEW2 SVSET  Crate 14, Slot 9   to 1RR21IB  Crate 7, Slot 10    OK 
Testing GLE23 SVSET  Crate 14, Slot 16   to 1RR21IT  Crate 6, Slot 10   OK 
Testing GICE0 SVSET  Crate 14, Slot 12   to 1RR21IB  Crate 7, Slot 18   OK 
Testing GIEE2 SVSET  Crate 14, Slot 11   to 1RR21IB  Crate 7, Slot 13   OK 
Testing GS589 SVSEB  Crate 15, Slot 19   to 1RR21HB  Crate 5, Slot 18   OK 
Testing GS567 SVSEB  Crate 15, Slot 18   to 1RR21HB  Crate 5, Slot 16   OK 
Testing GS545 SVSEB  Crate 15, Slot 17   to 1RR21HB  Crate 5, Slot 12   OK 
Testing GS489 SVSEB  Crate 15, Slot 15   to 1RR21HT  Crate 4, Slot 18   OK 
Testing GS467 SVSEB  Crate 15, Slot 12   to 1RR21HT  Crate 4, Slot 16   OK 
Testing GS445 SVSEB  Crate 15, Slot 11   to 1RR21HT  Crate 4, Slot 12   OK 
Testing GS389 SVSEB  Crate 15, Slot 10   to 1RR21GB  Crate 3, Slot 18   OK 
Testing GS367 SVSEB  Crate 15, Slot 9   to 1RR21GB  Crate 3, Slot 16    OK 
Testing GS345 SVSEB  Crate 15, Slot 8   to 1RR21GB  Crate 3, Slot 12    OK 
Testing GIEE0 SVNEB  Crate 16, Slot 10   to 1RR21IB  Crate 7, Slot 15   OK 
Testing GIEW0 SVNEB  Crate 16, Slot 9   to 1RR21IB  Crate 7, Slot 8     OK 
Testing GLE45 SVNEB  Crate 16, Slot 17   to 1RR21IT  Crate 6, Slot 12   OK 
Testing GLE01 SVNEB  Crate 16, Slot 16   to 1RR21IT  Crate 6, Slot 8    OK 
Testing GICE2 SVNEB  Crate 16, Slot 12   to 1RR21IB  Crate 7, Slot 20   OK 
Testing GIEE4 SVNEB  Crate 16, Slot 11   to 1RR21IB  Crate 7, Slot 16   OK 
</pre> 
<h3>The Three Failures</h3> 
 
<ul> 
<li> LB0W2 HDI 4 <I>(unused)</I><pre> 
Fib  Crate 10, Slot 16  S/N 138 Vrb  Crate 6, Slot 18  S/N 174 Ch: 0 1 2 3 4 5 6 7 8 9  
 
Error Loop # 1 buff 0 VCh 4 index 1297  Expect: 0x007e017d Receive: 0x007e8444 
Error Loop # 1 buff 0 VCh 4 index 1299  Expect: 0x047a0579 Receive: 0x047a037b 
Error Loop # 1 buff 0 VCh 4 index 1301  Expect: 0x08760975 Receive: 0x08760777 
... 
</pre> 
This it is like there is a reflection for the lower 16 bits every 
32 bits, like:<pre> 
Expect: 8444 007e 017d 027c 037b 047a 0579 0678 0777 0876 0975 
Get   : 8444 007e 8444 027c 037b 047a 037b 0678 0777 0876 0777 
--- 
Expect: 0a74 0b73 0c72 0d71 
Get   : 0a74 0b73 0c72 0b73 
</pre> 
Pretty weird, huh?  Luckily we don't need this Vrb, and this 
problem was <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=68&frame=2&anchor=14:33:55'>noted before</a>  
<li>Intermittent  Problem on SB2WB L2: <pre> 
Error Loop # 545 buff 0 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 547 buff 2 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 610 buff 1 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 612 buff 3 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 673 buff 0 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 675 buff 2 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 738 buff 1 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 740 buff 3 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 801 buff 0 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 803 buff 2 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 866 buff 1 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 868 buff 3 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 929 buff 0 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 931 buff 2 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 994 buff 1 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 995 buff 2 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 996 buff 3 VCh 7 index 2550        Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1057 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1059 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1121 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1122 buff 1 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1124 buff 3 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1185 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1187 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1188 buff 3 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1250 buff 1 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1251 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1252 buff 3 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1313 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1315 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1377 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1378 buff 1 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1380 buff 3 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1441 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1443 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1506 buff 1 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1507 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1508 buff 3 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1569 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1633 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1634 buff 1 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1636 buff 3 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1697 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1699 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1762 buff 1 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1763 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1764 buff 3 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1825 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1827 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1890 buff 1 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1892 buff 3 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1953 buff 0 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 1955 buff 2 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 2018 buff 1 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
Error Loop # 2020 buff 3 VCh 7 index 2550       Expect: 0x3e403f3f Receive: 0x3e403f1f 
... 
</pre> 
Looks like bad bit 5, always in the same place in data, but 
only on buffers 0-3.  Should try to identify if Fib or Vrb. 
Also very weird that it is almost always 2 bad events seperated  
by 1, then 61 good events, then 2 bad events seperated by 1, then 63 good events...this smells like something periodic going on 
in the crate maybe... 
<li>SB4W2 L0 looking odd too <pre> 
Fib  Crate 13, Slot 13  S/N 127 Vrb  Crate 4, Slot 10  S/N 152 Ch: 0 1 2 3 4 5 6 7 8 9  
 
Error Loop # 1 buff 0 Head index 0      Expect: 0x32700008 Receive: 0x2d680008 
Error Loop # 1 buff 0 Head index 3      Expect: 0x05060506 Receive: 0x00000506 
Error Loop # 2 buff 1 Head index 0      Expect: 0x32700009 Receive: 0x2f700009 
Error Loop # 2 buff 1 Head index 3      Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 2 buff 1 VCh 0 index 138   Expect: 0x027c037b Receive: 0xffe18444 
... 
Error Loop # 3 buff 2 Head index 0      Expect: 0x3270000a Receive: 0x2f70000a 
Error Loop # 3 buff 2 Head index 3      Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 3 buff 2 VCh 0 index 138   Expect: 0x027c037b Receive: 0xffe18444 
Error Loop # 3 buff 2 VCh 0 index 139   Expect: 0x047a0579 Receive: 0x007e017d 
... 
Error Loop # 4 buff 3 Head index 0      Expect: 0x3270000b Receive: 0x2f70000b 
Error Loop # 4 buff 3 Head index 3      Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 4 buff 3 VCh 0 index 8     Expect: 0xffe08444 Receive: 0x0260037b 
Error Loop # 4 buff 3 VCh 0 index 9     Expect: 0x007e017d Receive: 0x047a0579 
... 
Error Loop # 5 buff 4 Head index 0      Expect: 0x3270000c Receive: 0x2f70000c 
Error Loop # 5 buff 4 Head index 3      Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 5 buff 4 VCh 0 index 8     Expect: 0xffe08444 Receive: 0x0260037b 
Error Loop # 5 buff 4 VCh 0 index 9     Expect: 0x007e017d Receive: 0x047a0579 
Error Loop # 5 buff 4 VCh 0 index 10    Expect: 0x027c037b Receive: 0x06780777 
... 
Error Loop # 6 buff 5 Head index 0      Expect: 0x3270000d Receive: 0x2f70000d 
Error Loop # 6 buff 5 Head index 3      Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 6 buff 5 VCh 0 index 8     Expect: 0xffe08444 Receive: 0x0260037b 
Error Loop # 6 buff 5 VCh 0 index 9     Expect: 0x007e017d Receive: 0x047a0579 
Error Loop # 6 buff 5 VCh 0 index 10    Expect: 0x027c037b Receive: 0x06780777 
... 
Error Loop # 7 buff 6 Head index 0      Expect: 0x3270000e Receive: 0x2f70000e 
Error Loop # 7 buff 6 Head index 3      Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 7 buff 6 VCh 0 index 8     Expect: 0xffe08444 Receive: 0x0260037b 
Error Loop # 7 buff 6 VCh 0 index 9     Expect: 0x007e017d Receive: 0x047a0579 
... 
Error Loop # 8 buff 7 Head index 0      Expect: 0x3270000f Receive: 0x2f70000f 
Error Loop # 8 buff 7 Head index 3      Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 8 buff 7 VCh 0 index 8     Expect: 0xffe08444 Receive: 0x0260037b 
Error Loop # 8 buff 7 VCh 0 index 9     Expect: 0x007e017d Receive: 0x047a0579 
... 
Error Loop # 9 buff 0 Head index 0      Expect: 0x32700000 Receive: 0x2f700000 
Error Loop # 9 buff 0 Head index 3      Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 9 buff 0 VCh 0 index 8     Expect: 0xffe08444 Receive: 0x0260037b 
Error Loop # 9 buff 0 VCh 0 index 9     Expect: 0x007e017d Receive: 0x047a0579 
Error Loop # 9 buff 0 VCh 0 index 10    Expect: 0x027c037b Receive: 0x06780777 
... 
Error Loop # 10 buff 1 Head index 0     Expect: 0x32700001 Receive: 0x2f700001 
Error Loop # 10 buff 1 Head index 3     Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 10 buff 1 VCh 0 index 138  Expect: 0x027c037b Receive: 0xffe18444 
Error Loop # 10 buff 1 VCh 0 index 139  Expect: 0x047a0579 Receive: 0x007e017d 
Error Loop # 10 buff 1 VCh 0 index 140  Expect: 0x06780777 Receive: 0x027c037b 
... 
Error Loop # 11 buff 2 Head index 0     Expect: 0x32700002 Receive: 0x2f700002 
Error Loop # 11 buff 2 Head index 3     Expect: 0x05060506 Receive: 0x02080506 
Error Loop # 11 buff 2 VCh 0 index 8    Expect: 0xffe08444 Receive: 0x0260037b 
Error Loop # 11 buff 2 VCh 0 index 9    Expect: 0x007e017d Receive: 0x047a0579 
Error Loop # 11 buff 2 VCh 0 index 10   Expect: 0x027c037b Receive: 0x06780777 
</pre> 
 
So, total Byte count (index 0) is always wrong and Chan 0 byte count (index 3) is also always wrong. Event 1 there is no data 
in Chan 0.  Events 2,3,10 at byte 0x208 (index 138) where 
you expect 0x027c037b you get the next Channel.  Events 4-9,11, 
where you expect the beginning of Chan 0 data (index 8) 
you get 0x02(60)037b where the (60) would be 7C but for masking. 
Seems like a VRB problem, will try to track it down. 
</ul>
<!-- Author: SCN -->
<!-- Comment: Sat Jan  5 15;20;30 comment by...SCN -->
<h3>SB2WB L2</h3>
Problem is reproducable, and when swapping around Glink Cables
stayed with FIB.  Also can be seen in Fib2Fib (a subset of the
data path for Fib2Vrb):<pre>
Fib 40:4:106  Crate 9, Slot 19   Chans: 0 1 2 3 4 5 6 7 8 9
File: fib1k.fifo # Bytes 12860


Error loop 50 pipe 7 index 10157 Expect: 0x3f Receive: 0x1f
Error loop 50 pipe 7 index 10157 Expect: 0x3f Receive: 0x1f

Error loop 100 pipe 7 index 10157 Expect: 0x3f Receive: 0x1f
Error loop 100 pipe 7 index 10157 Expect: 0x3f Receive: 0x1f
...
</pre>

Suggest we replace this Fib next access.

<!-- Comment: Sat Jan  5 15;38;50 comment by...SCN -->
<ul>
<li><h3>LB0W2 4</h3>
Swapped Cables and problem stays with VRB, also seen
in Vrb Emulated Data test:<pre>
VRB Fake Data test   Crate 6, Slot 18   174:11/06/01
SVX Mode D64 Buffer # Varies Chans: 0 1 2 3 4 5 6 7 8 9 

Error in Loop 5000 Buff 0 near byte 0x424 -> Chan 4     Expect: 0x03030404 Actual: 0x03030202
Error in Loop 5000 Buff 0 near byte 0x42c -> Chan 4     Expect: 0x07070808 Actual: 0x07070606
Error in Loop 5000 Buff 0 near byte 0x434 -> Chan 4     Expect: 0x0b0b0c0c Actual: 0x0b0b0a0a
Error in Loop 5000 Buff 0 near byte 0x43c -> Chan 4     Expect: 0x0f0f1010 Actual: 0x0f0f0e0e
Error in Loop 5000 Buff 0 near byte 0x444 -> Chan 4     Expect: 0x13131414 Actual: 0x13131212
Error in Loop 5000 Buff 0 near byte 0x44c -> Chan 4     Expect: 0x17171818 Actual: 0x17171616
</pre>
Leave VRB there b/c Chan 4 not needed
<li> <h3>SB4W2-0</h3>
Swapped Cables and problem stayed with Vrb.  Problem not
seen in Vrb Emulated Data test, so probably input fifo or 
pointer problem.  Will swap out Vrb and retest.
</ul>

<!-- Comment: Sat Jan  5 16;16;28 comment by...SCN -->
Swapped VRB in b0svx04 Sl 10-
Out: VRB 152 PREP 551026  In: VRB 151 PREP 551025<BR>
Ch 0 problem went away.  This Vrb was claimed to have
a problem before, but problem was not reproducible nor
well enough documented to know what to fix.


<!-- Date: Sat Jan 5 16:43:51 2002 -->
<table border=0><td><tr><td bgcolor=#e0e030><pre>Interlock changes made and tested: 
 
(1) ISL_TE_CCW2L6_1OUT (previously insane RTD that now appears to 
be OK) returned to the interlocks. 
 
(2) You can now set the trip limit for SVX_TE_PCW1A_2 separately 
from the other DOIM RTDs.  Set it higher, 'cause it touches the port card itself. 
 
(3) You can now set the trip limit for blocked ISL CCs separately 
from the rest of the CCs.  Set it higher, because they basically 
read the ambient temp. 
 
I have set the trip limits as follows: 
 
SVX BHs: 15 deg C 
SVX DOIMs ("A" ring): 20 deg C 
SVX PCW1A_2: 25 deg C 
SVX DDRs ("B" ring): 20 deg C 
 
ISL CCs: 15 deg C 
ISL CPCs: 15 deg C 
ISL blocked CCs: 25 deg C 
 
L00 sil: 15 deg C 
L00 hyb: 15 deg C 
 
I determined these limits by looking at the temperatures from 
the evening of 02-JAN-2002, when everyone was on.  I believe I 
left enough breathing room with the ISL limits to add in the new 
inner layer 7's, but careful eye should be kept on these temps 
when they are first turned on.</pre></td></tr></td></table>
<!-- Author: Andy H., Eva H. -->
<!-- Comment: Mon Jan  7 16;15;08 comment by...Doug -->
<pre>I upped the trip limits for the ISL.  They are now:

	ISL CCs:  17 deg-C
	ISL CPCs: 15 deg-C
        ISL blocked-CCs: 35 deg-C

We just added all the B1 and B4 wedges plus the newly cooled B2
wedge.  I'd like to leave them at these higher limits for a day,
after which i'll reset them to something tighter.</pre>
<!-- Date: Sat Jan 5 18:06:14 2002 -->
With Andy and Jean's permission, I updated all Fibs in  
b0fib00 with the new Fib firmware.  I put in a  
2.5 microS timeout for Enabled pipelines (they all are) 
which do not receive data.  Current Run Number: 136313.
<!-- Author: SCN -->


<!-- Date: Sat Jan 5 20:51:19 2002 -->
<pre>REPRODUCING ERRORS IN TESTSTAND MODE 
===================================== 
 
1)I was able to successfully induce the 00f3 problem in teststand 
mode. It occurs when I write to the FIB while taking data. You 
can see the result in ~svxii/daq/anywhere/data/laser1435.svx  
 
2)in ~svxii/daq/anywhere/data/laser1436.svx I read several times 
without any parse errors appearing but wrote only once and then  
the 00f3 error appeared Event 206. 
 
3) Performed HRR several times in ~svxii/daq/anywhere/data/laser1437.svx lots of capid errors  
appeared.</pre>
<!-- Author: UnMerry Mary -->


<!-- Date: Sat Jan 5 21:57:37 2002 -->
<pre>Turning SI to stdby: GUI dies when I get to ISL  
 
svxinter: 
*** FATAL ERROR *** 
T_REALLOC &lt;((msg-&gt;variable_data_buf).data)&gt;: 65536 bytes: out of heap: file ipcmsg1.c, line 981 
Wall Clock Time: MON JAN 05 19:57:10 1970 
RTworks Time: 0.000000 
Last RTworks Error Code: 25 
Last C Error Code: 1114113 
Last OS Error Code: 1114113 
Last Socket Error Code: 1114113 
To create a core dump, please generate a QUIT signal 
(usually by typing CTRL-\) now. 
You have four seconds to do this. 
0xb117f0 (t5): memPartAlloc: block too big - 65536 in partition 0x2ded8c. 
 
</pre>
<!-- Author: Oh my my -->


<!-- Date: Sat Jan 5 22:04:51 2002 -->
Tested these <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=87&frame=2&anchor=10:18:49'> 
ladders </a> 
 
ALL OK WITH HST. Both SB1W10 L2 and SBW2 L4 were tested with 
NN DPS on using SvxDAQ no problems in 100-200 events
<!-- Author: UnMerry Mary -->
<!-- Comment: Mon Jan  7 09;58;15 comment by...SCB -->
<pre>That's SB1W2 L4</pre>
<!-- Comment: Mon Jan  7 10;00;10 comment by...Jean -->
<pre>This ia with new Fib Firmware v15 - trial version</pre>
<!-- Date: Sat Jan 5 22:21:36 2002 -->
<pre>SB1W2 L2 has had persistent AVDD pink and manual handshakes 
didn't fix it. SB1W1L4 had the same problem over the last 
hour. Coldstart fixed SB1W1L4 pink condition but failed 
to init SB1W2 L2. 
 
I am afraid that when I was messing around turning things on 
and running HST I recycled power on several wedges in B1 and B2 
a couple of times because of DVDD trips. Did I kill another 
chip?</pre>
<!-- Author: Very Unhappy Mary -->


<!-- Date: Sat Jan 5 22:32:25 2002 -->
<pre>Tried reading out SB1W2 L2 in svxdaq. Init returns all ffs 
and no data from ladder. Dumped fib output fifo in  
 
~svxii/daq/anywhere/e120_fib_fifodump.dat  
 
 
Fills up with d0d0s then times out.</pre>
<!-- Author: Mary :( :( -->
<!-- Comment: Sat Jan  5 22;35;43 comment by...Mary :( :( -->
<pre>Since DVDD and AVDD do go to values that are close to init
I will mask out init on this ladder in HDWDB but leave
it enabled and see how it behaves. Shouldn't cause reformatter
errors now</pre>


<!-- Comment: Sat Jan  5 22;59;48 comment by...Mary the Extremely UnMerry -->
<pre>I am innocent of any damage SB1W2 L2 has been bad for a while
for e.g. &lt;a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=87&frame=2&anchor=13:56:48'&gt;
see this entry by SCN &lt;/a&gt; 

Grumble this wedge is now borderline tracking wise!</pre>
<!-- Comment: Sat Jan  5 23;01;08 comment by...!@#$% -->
UGH forgot html:


<a href=
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=87&frame=2&anchor=13:56:48'>
SCNs entry </a> 
<!-- Date: Sat Jan 5 22:46:04 2002 -->
<pre>SOC AVDD is persistent pink and has been so for &gt; 1 hour while 
I was testing handshaking and coldstarting haven't helped. 
DVDD was also. pink until Dave called and told me the fib address 
and it turned green as soon as I manually handshook</pre>
<!-- Author: :-( -->
<!-- Comment: Sat Jan  5 22;47;57 comment by...:-( -->
<pre>SOC is OK after coldstart - I must have forgotten to unmark AVDD.
Silly me</pre>


<!-- Date: Sat Jan 5 22:53:18 2002 -->
<pre>Ran SEVB on full SI system 227 events no errors. Run 136318  
partition 5.  
 
READY TO INTEGRATE</pre>
<!-- Author: Mary The UnMerry -->




<!-- Date: Sat Jan 5 23:11:03 2002 -->
<pre>Boss Andy says to bias! Ay Ay Skipper - its done. 
Turned POWER to on. After that DVDD on L2 SB230 and  L0 and 
L2 SB2b0 went pink (hi!) manualy handshook and everything 
is fine now.</pre>
<!-- Author: Mary The Happy She Is Going Home -->


<!-- Date: Sat Jan 5 23:27:54 2002 -->
<pre>SI INTEGRATED STARTING RUN 136319. L00 BIAS = 80V</pre>
<!-- Author: I am still here -->


<!-- Date: Sun Jan 6 09:06:20 2002 -->
<h3>Fib Firmware Update</h3> 
I was looking at reformatter error for Run 136300 and up. 
Out of a total of 18464 across Si, 13814 or them come from one wedge, SB0W2, where we're getting the leading 00 byte problem. 
If memory serves, this wedge had "leading c4" troubles <a href= 
'/cgi/elog/det-system-elog.pl?nb=silicon&action=view&page=56&frame=2&anchor=10:53:32'> 
before</a>.  Now we know that the leading 0 byte comes through the pipeline processor, which is a significant clue-maybe we can 
fix the firmware better-I'll talk to Ken on Monday.<P> 
On an unrelated note, I thought it might be wise to mention that 
we do <B>NOT</B> write to the Fibs except during initialization. 
We do READ from them, at a rate of 0.1 Hz.  It is possible that 
in READing we need to enable (i.e. write) some bit that causes the 00f3 problem in any HDIs which are not done being read out 
(that's the only way I can think of how an action on the whole 
fib affects only 1 HDI-it is also testable by looking at the  
length of the readout of the other HDIs in the same Fib relative 
to where the 00f3 problem occurs).  It would also be nice 
to know if the 00f3 problem has occurred in any Fibs with new firmware (any in b0fib00). We'll look at it in more detail this week.   
<!-- Author: SCN -->


<!-- Date: Sun Jan 6 21:01:38 2002 -->
<pre>We have a persistent IMON pink cell, it's SB1W2L2 AVDD. 
Latest current is 915 for nominal 810.</pre>
<!-- Author: Yamashita -->


<!-- Date: Sun Jan 6 22:08:25 2002 -->
<pre>IB0W1 L4 will not init.  Rebooting FIB, power cycling (once) 
do not fix.  Currents are normal, and the last analyzable 
run, 136126, show the ladder as perfect.  Removed from  
HWDB but left on (currents are OK).</pre>
<!-- Author: ADF / JG -->


<!-- Date: Mon Jan 7 07:32:55 2002 -->
<pre>I was called in before the birds to find out why we are having 
a lot of "Silicon Timeout: Busy" errors. 
 
They have been occuring since Jan 1 at least, but I think this 
was when SCN instituted this error type.  
 
I ran with SEVB for 1000 events with no problems, we  
reingtegrated. SB0W2 lost init after a few minutes, has been  
doing this for a while according to the aces. So I took that  
wedge out. I noticed a large increase in reformatter errors 
after this happened. Strange error, 'Bank with ambiguous  
instance' SCPU 11  VRB 0 Link 6. According to the converter  
this is B2w1L1 I think. This is sometimes the most common error 
but it comes and goes. 
 
I need to know whether to put SB0W2 back in, for now it is  
powered and out. 
 
The Timeout errors went away once I got here, of course. 
</pre>
<!-- Author: Lester -->
<!-- Comment: Mon Jan  7 07;34;56 comment by...Lester -->
<pre>The error:

RAWREF Error - BNK-INSTAN - with code 31 -- START
 Line -  241 in: src/library/rr_refevt.c
 Buffer position: -1
 Error count: 1 of 1
 Reject rate: 50.000 percent
 
 Bank with ambiguous instance: fragment not
 added to bank.
 Bank Name   Bank Instan Mini Instan
  0x44584953  0x00000079  0x00000079
 
 Error location code: 0x0500b060
 
 
 Crate Id?: 0x00000050
 
 Error during scanning MINI structure!
 Last Unit prob. worked on (all counts from 0):
  SCPU: 11
  VRB : 0
  LINK: 6
  MINI: 0
 
 
 NOTE: Event rejected!                                                                                                                   </pre>

<!-- Comment: Mon Jan  7 07;41;41 comment by...Lester -->
<pre>SB4W4 also seems to lose init regularly. I have left this in.
</pre>

<!-- Comment: Mon Jan  7 08;51;07 comment by...Lester -->
<pre>SB0W2 back in after discussion with Jean.</pre>

<!-- Comment: Mon Jan  7 08;52;25 comment by...Lester -->
<pre>B2W5 'lost init' this time</pre>