Restarted with cgminer this morning with 3.8.2 + patches from git master. It has been 6 hours, and 8 ASICs have gone zombie, and then been rediscovered without issue. So, this looks like a keeper on Fedora 19!
With this approach, the AMU number will keep rising. How high can it go before restarting is advisable? Does each disabled AMU use memory? Or is it just a matter of overflowing 2^31 ? Restarting weekly is probably a sane policy.
After approx. 2 days, half of the ASIC units are zombies again. BUT, now simply restarting the software did not awake them. I had to unplug, and replug the failed units. (Fortunately, when they aren't hashing, they don't burn your fingers!)
This reminds me of the ALWAC II [
http://en.wikipedia.org/wiki/Axel_Wenner-Gren ] at Naval Research Labs. It had 256 bytes all electronic (vacuum tube) RAM, which was paged in its entirety from a magnetic drum memory. Computations within the page of RAM were blindingly fast by the standards of the day, and the Fortran compiler was able to optimize for this. However, because 256 bytes (with parity) was a lot of vacuum tubes, the failure rate was fairly high. You needed to run your program 3 times, and if it got the same answer 2 out of 3 times, you were good.
Why does this remind me of USB ASIC mining? Well, a ground breaking invention on the ALWAC was a parity bit on each byte of memory. Each byte was on its own vacuum tube board, with a neon (high reliability) lamp which glowed when the parity check failed. An apprentice had a cart of vacuum tubes, and would race down the aisle to each board that was lit, replace all 9 tubes (they could be tested and the good ones recycled later), and run to the next. That's what I feel like, checking for the green LEDs on the USB ASIC array, and replugging the units.