Hmmm...  Thanks for the info.  I did to this and perhaps that's the culprit? 
What is the "memory debugging feature" that you turned on?

I'm seeing a problem with 3.8.1 on an RPi running Rasbian.  Twice in the last 24 hours cgminer has stopped running.  It appears as if the "q" key was pressed even though I'm sure it was not.  This hardware has run solid for weeks before I upgraded to 3.8.1. 

0-25%

Throttling should be reduced in the next firmware release.  Part of the problem was that if Chili was idle because the host mining software was not sending any jobs (perhaps it's not started yet or there is a problem with the pool connection), then Chili would cool off and notice that it could crank up the frequency and voltage.  This is bad when work unit start coming again because it is now running too fast & hot.

New firmware will not change frequency or voltage when there are no work units in the queue.  I'm testing that and other fixes now.

Edit: The temperature that is reported is the temperature of the hottest ASIC chip.

Not at this time.  I have no current plans to release it but might change my mind later. 

Except that WinUSB *IS* the correct driver for ASICs if using cgminer.

End of topic.

1. Update to the newest firmware.  This is a known issue with the new Rev B ASIC chips that we did not see in the older Rev A samples.

2. Rebooting the board will fix the problem if it is what I think it is.  If rebooting never helps, then send MrTeal a PM for directions on what to do next.  I will have a firmware fix for this but have been busy with real life stuff and getting batch 2 built.

3. No other than keep the board cooler with a better heatsink or TIM.  We plan to have a firmware update to assist you in having more control over this.  (See excuses in #2)

Please remember, we're a very small team - not a swarm of locusts. 

Keep this political shit out of our thread.

cgminer requires the WinUSB driver.
bfgminer requires the FTDI serial driver.

Gathering all of the parts together and delivering to the assembly house as a single package or "kit" for them to build.

The answer is "Yes". 

That sounds to me like your cooling solution is not working well enough.  There are two types of temperatures that will cause the hash rate to drop. 
1) The temperatures of the ASIC chips.  Your heatsink and fan or your TIM (Thermal Interface Material) may not be good enough.
2) The temperature of the voltage regulator.  Keeping the voltage regulator cool will help ensure your Chili will hash as fast as possible.  Someone recently posted photos of an old PS3 heatsink attached to the bottom of the voltage regulator area.  Or at the very least, add a fan blowing on the voltage regulator.

Based on your comment above, I think #1 is your primary problem.  Which heatsink and fan are you using?  What TIM are you using?

No.

No, nothing other that what was documented.  There is a new bit in a control register that needs to be set.  See the BFL source code for 1.2.8 or 1.2.9 and compare it to the older code.

Probably but there are some issues in doing that.  I'll need to work out the details. 
It is planned to be working with the normal release of bfgminer.

No.

When a board first starts up, the firmware makes sure the board and chips are cooled down before it starts the self test.  This helps ensure the maximum number of engines (cores) will pass self test.

LED decoder ring

The LEDs are numbered 1 to 8 with #1 closest to the USB connector and #8 closest to the power and fan connectors.  During first power up, LEDs 5, 6, 7, and 8 will light up and LEDs 1, 2, 3,  and 4 will indicate a failure code if anything is wrong with the hardware.  This happens VERY quickly - in less than a second.

If the initial hardware checks are good, #7 will blink indicating it is waiting for the board to cool down.  This will always blink for a few seconds even if the board is cold. 

Then #7 and #8 will blink indicating ASIC self test. 

After that, 1, 2, 3, 4 will indicate how many jobs from cgminer are waiting to run in the input queue.  LED 5 is just a debug output for me but it roughly indicates a job has completed - but sometimes blinks too fast for the human eye to see.  Just ignore LED 5.

I am working on some firmware updates that will fix most (or all?) of the problems the boards are having.  For example, one failure I think I have figured out is occasionally a board will jump to more than 100 GH/s but have 100% hardware errors.  I have one board that does this once per day or so and needs to be rebooted.  After chasing this for a while, I believe I have finally figured out what is going on and will have a fix in the next release.

No.  It will say
"All your coin are belong to us."

Yes, in an effort to extract as much hash rate as possible, we have enabled some cores/engines that are (as it turns out) somewhat marginal.  It is planned to have a future firmware release that will improve this.  I have only run 3 Chilis for any length of time and 2 of them have much lower error rates than the other one.  It is somewhat luck of the draw.

Yes.  The Chili works anywhere a BFL SC ASIC works.  Note that we're done all of our testing so far with cgminer.  It also works with a special version of bfgminer.  We will soon release a fix in our firmware that will work with standard bfgminer.

It appears to me that it's possible that third unit has a problem.  If the problem is what I think it is, I can send you directions on how to fix it.

Please PM me with the serial number of that unit.