I've found that my Prismas don't like to run for much longer than 48-hours in the DC.  I've had to restart them from the rPi three consecutive times now, through Minera.  That said, if you catch them before they cool down, you don't have to restart cgminer as many times before it "catches."

I'm playing with the auto-restart function in Minera--we'll have to wait for it to die again before I can test the settings.

Cheers.

I attempted that setup yesterday, but found that (in my hour of messing with it) it made clearing the bad responses difficult.  That said, it did recognize them both (0 and 1) and appeared to be trying to send work to both.  I was dealing with other issues as well, so YMMV.

Cheers.

This appeared to be the solution.  Once I let the boards warm up, they appear to be hashing just fine.  Thanks for the tip, it was dead on.

Cheers.

I'm going to attempt to fire those two boards up again this morning. . They are in a DC,  so the temperature is on the low side. I'll let you know what I find.

I've lost two out of my eight boards last night around midnight.  There is no visible problem I can find, but when plugged directly into the Pi or the BE controller I get nothing.  On the BE controller I get multiple PwrDn counts, but no hardware errors.  The device doesn't warm up, and the boards heat sinks are cool to the touch!

I've connected the two good units back into the chain, distributed the power appropriately and have my fingers crossed.  I hope AM does something to sort out this issue--they've been good about it in the past; I imagine they are scrambling to figure it out as we speak.

Here it is: https://bitcointalk.org/index.php?topic=671189.msg8157775#msg8157775

PM me when you get your rpi and I'll make sure you have everything you need!

It sounds like everything you're doing should work.  Maybe it's time to try using BFGminer 4.10 as a proxy with your BE controller and see how that works.

That explains the log, then!  Which version of cgminer are you using?

I notice that you have "BET1" listed as the device.  Are you using more than one USB UART controller on your system?

My machines are housed in a DC, so I feel your pain.  I've taken to using the "Mobileminer" APIs to monitor and restart them remotely.  That said, since these devices are likely running cgminer on a rPi, you could use a number of tools that plug into that API set to keep things running.

I imagine we could even scratch together a log monitoring system that would restart cgminer automatically until the errors cleared.  If I get some time this weekend (I won't) I'll work on that....

It's been suggested that restarting the mining software (repeatedly) will eventually clear those up.  I've found that I have to restart cgminer between 5-10 times before it finally "takes."  I know that's not an amazing solution, but the devices seem to run pretty trouble-free once they're hashing...

Cheers.

Yeah, my bad--I should have been more clear.  They are designed to be ran horizontally, but you should use shelving to support every two or so.  The ears aren't designed to support the weight of the unit, just to keep them in place in the rack.

Cheers.

They have rack mount ears--they are designed to be mounted in a DC horizontally.

I found this article today and thought of you--I know you were thinking about doing something like this come winter.  Now that the cold's here, I'm bringing something to mine bitcoins and keep my feet warm to work tomorrow!

Cheers.

This works well on a home router, but if you are on a more complicated network you may need to take the following steps:

1.) Determine what IP range your DHCP server is handing out to the network drop you plan to use.  Do this by plugging in the cable to a laptop/computer and jotting down the IP it assigns you.  This IP will give us the range we need for the next steps (note that the rPi won't use the same IP address when it's plugged into the same cable).

2.) Install an IP scanner tool (I use Angry IP Scanner) and point it to the entire subnet for the IP address you wrote down earlier.  For example, my DHCP server gave me a 10.2.0.34 address, so I'm going to configure Angry IP to scan IP addresses between 10.2.0.1 and 10.2.0.255.

3.) Scan the IP range with Angry IP Scanner before you plug in your Raspberry Pi.  Write down (or screenshot) the output of Angry IP (if there are just a few, write down the last number of each IP).

4.) Plug in your Raspberry Pi.

5.) Scan the IP range again, and compare your first list with your second.  The difference should be* the IP address assigned to your Raspberry Pi.

Hope that helps!

*sometimes machines don't respond quickly enough in your first scan, so you may get back a few different IPs the second time.  Check each one by trying to ssh into them i.e. "ssh pi@xx.xx.xx.xx" until you get connected.  The default password for the pi user is "raspberry"

I'm going to get my spouse and my girlfriend to help, just to be safe!

I'm running CG's image on a RPi B, I don't think it's B+.  Aside from the problem mentioned above, it's ran great for the last 24 hours.

Cheers.

It popped back up pretty quick, it's running 1451 now--apparently I just needed to be patient and restart cgminer until it cleared.

Me either--I believe that restarting cgminer until it clears up is the answer, as I'm up and running now after just resetting cgminer a few times.  Maybe six, maybe a few more, I wasn't counting.  I would love to figure this out.  Power cycling the Prisma doesn't seem to clear it, either.

Back up and running for now, we'll see what the clock reaches--it's sitting at 1322 now, but it's been steadily climbing.