Cairnsmore1 - Quad XC6SLX150 Board

[tenzor]

I wonder if anyone was able to set up CM1 board mining with Raspberry Pi already? If yes, how many boards is one RPi able to handle?

running 12 boards. Looks good. Floating bugs with not working boards simetimes, but i believe it's cables problem.

[1714206971]

1714206971

[makomk]

There's a really annoying bug in the MPBM Cairnsmore1 worker that causes the built-in watchdog to reset it to the default speed if the network falls over for a couple of minutes, and it doesn't ramp it up again so it's going to stay there for a while. Hopefully this patch should fix it:

Code:

diff --git a/modules/theseven/cairnsmore/cairnsmoreworker.py b/modules/theseven/cairnsmore/cairnsmoreworker.py
index 4dd4dd0..aaadc96 100644
--- a/modules/theseven/cairnsmore/cairnsmoreworker.py
+++ b/modules/theseven/cairnsmore/cairnsmoreworker.py
@@ -395,6 +395,7 @@ class CairnsmoreWorker(BaseWorker):
     if self.oldjob and self.oldjob.starttime:
       if self.oldjob.starttime:
         hashes = (now - self.oldjob.starttime) * self.stats.mhps * 1000000
+        hashes = min(hashes, 2**32)
         self.hasheswithoutshare += hashes
         self.oldjob.hashes_processed(hashes)
       self.oldjob.destroy()
@@ -410,6 +411,7 @@ class CairnsmoreWorker(BaseWorker):
     if self.job:
       if self.job.starttime:
         hashes = (now - self.job.starttime) * self.stats.mhps * 1000000
+        hashes = min(hashes, 2**32)
         self.hasheswithoutshare += hashes
         self.job.hashes_processed(hashes)
       # Destroy the job, which is neccessary to actually account the calculated amount

[Lethos]

Nice Fix.

[Isokivi]

There's a really annoying bug in the MPBM Cairnsmore1 worker that causes the built-in watchdog to reset it to the default speed if the network falls over for a couple of minutes, and it doesn't ramp it up again so it's going to stay there for a while. Hopefully this patch should fix it:

Code:

diff --git a/modules/theseven/cairnsmore/cairnsmoreworker.py b/modules/theseven/cairnsmore/cairnsmoreworker.py
index 4dd4dd0..aaadc96 100644
--- a/modules/theseven/cairnsmore/cairnsmoreworker.py
+++ b/modules/theseven/cairnsmore/cairnsmoreworker.py
@@ -395,6 +395,7 @@ class CairnsmoreWorker(BaseWorker):
     if self.oldjob and self.oldjob.starttime:
       if self.oldjob.starttime:
         hashes = (now - self.oldjob.starttime) * self.stats.mhps * 1000000
+        hashes = min(hashes, 2**32)
         self.hasheswithoutshare += hashes
         self.oldjob.hashes_processed(hashes)
       self.oldjob.destroy()
@@ -410,6 +411,7 @@ class CairnsmoreWorker(BaseWorker):
     if self.job:
       if self.job.starttime:
         hashes = (now - self.job.starttime) * self.stats.mhps * 1000000
+        hashes = min(hashes, 2**32)
         self.hasheswithoutshare += hashes
         self.job.hashes_processed(hashes)
       # Destroy the job, which is neccessary to actually account the calculated amount

Could I please get the "clueless moron" version of how to apply this patch ?

[makomk]

Could I please get the "clueless moron" version of how to apply this patch ?

Sorry, only just noticed this message. TheSeven's added a more complete version upstream, so you should just be able to "git pull" and get it.

[steamboat]

I'm running the dynamic hashvoodoo release capped at 200 on mpbm and a laptop and i've been noticing my rig doesn't like more than 17 boards connected at once. It always drops 2 random boards a few hours after I reset them. Each time one of them drops I swap out the usb cable for a new one. It's possible they aren't getting enough power, but I have them connected to a 1000 watt power supply on a 1500va/1000 watt UPS that hasn't given any warnings, and the rig only draws 950 from the wall, so i should have ~250 watts to spare. I'm going to split the rig up and see what happens over the weekend.

You have to be a little careful on what an individual ATX PSU will do. The additive of individual rails is often more than the overall rating but conversely that doesn't mean you can get the entire 1000 watts out of the 12V rails.

In some power supplies the 12V is also split and individual sections have a limit and it is possible to exceed the limit on one section whilst under capacity either overall or even in other sections.

There is another aspect which probably isn't a big factor in modern ATX supplies but I will mention to be complete and that is where the 5V or 3.3V is underloaded and causes an issue. In older supplies there was often a primary regulation based on usually 5V loading. Low or no load on the 5V typically lowered what I will call the excitation of the power supply and basically it drops too low to provide enough energy to 12V circuits. Some of you may have noticed that we put a small loading on our PDB for 5V and 3.3V to avoid this issue.

upon further inspection i indeed was drawing too much from the power supply. switched out to a more efficient 1200 watt and everything is humming along nicely and drawing less power too! Now to find something to do with this newfound free time.

[bitcowok]

There is another aspect which probably isn't a big factor in modern ATX supplies but I will mention to be complete and that is where the 5V or 3.3V is underloaded and causes an issue. In older supplies there was often a primary regulation based on usually 5V loading. Low or no load on the 5V typically lowered what I will call the excitation of the power supply and basically it drops too low to provide enough energy to 12V circuits. Some of you may have noticed that we put a small loading on our PDB for 5V and 3.3V to avoid this issue.

Yep. I hit this issue loading up a power supply's 12V rail with CM1s.  Almost let all the magic smoke out but caught it just in time.  The remedy: load up the 5V rail with a x6500 

[Bitbird]

My Cairnsmore1 displayed dead one chip after the other by BFGMINER from time to time (after start BFGMINER around 5 to 20 minutes) today. When this occur you'll need disconnect the power to restart Cairnsmore1. But that wouldn't help this situation. What could be caused this?

[Doff]

My Cairnsmore1 displayed dead one chip after the other by BFGMINER from time to time (after start BFGMINER around 5 to 20 minutes) today. When this occur you'll need disconnect the power to restart Cairnsmore1. But that wouldn't help this situation. What could be caused this?

Is this the dynclock version of Bfgminer, the one Luke-Jr has been working on with the clock settings for the new bitstream?  If it is, setting the clocks to start at 175 fixed that problem for me. if its an older version using makomk bitstream I don't know the answer.

[Luke-Jr]

My Cairnsmore1 displayed dead one chip after the other by BFGMINER from time to time (after start BFGMINER around 5 to 20 minutes) today. When this occur you'll need disconnect the power to restart Cairnsmore1. But that wouldn't help this situation. What could be caused this?

Could you make a debug.log file with this failure and upload it somewhere? Add to the end of your bfgminer command: --debuglog 2>debug.log

[Bitbird]

@Doff
It's standard version of Bfgminer 2.8.1

@Luke-Jr
OK. I'm testing the Cairnsmore1 on my another Linux PC. Will know this problem still occur or not soon.


#EDIT: Seems it's computer problem. Didn't get the same error on another PC at present.

[Luke-Jr]

@Doff
It's standard version of Bfgminer 2.8.1

2.8.1 only worked with fixed-frequency bitstreams, not the new dynamic-frequency ones, FYI.

[Cranky4u]

is there any chance of getting a monthly summary of updates? e,g,

Oct
Bitsreams
Mokamk  ver 5  (300MHs)

CGMiner
CKolivas ver 3000.1.00001  (yeah updates are my thing)

etc...etc...

P.S. it is all good and I appreciate your work...plus back it up with sheckles now and then

[tenzor]

After cold start of 12 boards, some of them wan't start mining. Cgminer responds with a 'invalid blah-blah' and doesn't mine on them. Kano's python usb tester responds with empty values after some timeout or invalid response. I'm using master/slave config with up/down cable. So, from this 12 boards I have, random number wan't start. It might be slave or master, does not matter. During request their leds flashs normally, as expected. Yellow off, then green on and fading down. Then yellow again.
After power cycle failed biard and its master/slave board, it might work in about 80%. If not, I just power do cycle again.
Tried to change usb hub, usb cables, miner..

Looks like controller issue? v1.5. Any suggestions?

[yohan]

After cold start of 12 boards, some of them wan't start mining. Cgminer responds with a 'invalid blah-blah' and doesn't mine on them. Kano's python usb tester responds with empty values after some timeout or invalid response. I'm using master/slave config with up/down cable. So, from this 12 boards I have, random number wan't start. It might be slave or master, does not matter. During request their leds flashs normally, as expected. Yellow off, then green on and fading down. Then yellow again.
After power cycle failed biard and its master/slave board, it might work in about 80%. If not, I just power do cycle again.
Tried to change usb hub, usb cables, miner..

Looks like controller issue? v1.5. Any suggestions?

It is more likely that the USB is screwed up but there is an ocassional thing that is power supply related. So try following this sequence in powering the rig up again up:

(1) Remove 12V power and ideally unplug all USB leads at Cairnsmore1s. If you happen to have a USB hub with a switch for on/off that can work as well as unplugging if it properly removes USB power. Do check that it does remove power some don't do this properly. Basically we want the boards to be fully de-powered before starting. This is also the only way also to reset the USB controller if it gets upset by sometime and we have seen that a few times.
(2) Power 12V and Controller LED is flashing on all boards and each FPGA section is powered and configured - LEDs bright.
(3) If you don't get Controller and section LEDs doing the right things modify the power up of the 12V by doing an initial momentary switch on then off and on again.
(4) Plug back in USB leads either one by one or use the hub switch if you have one.
(5) Make sure you leave enough time for USB to enumerate before firing up mining software and better still check USB ports/COMs are all correct and present in the host.

When using master/slave in Controller 1.5 it is important that both boards of the pair power up together otherwise one may fail to start up and that is only an issue for master/slave usage. We are going to try and improve the Controller to either remove, or reduce, this powering up dependence but that might be a few weeks before we have the time to do that.

[Glasswalker]

is there any chance of getting a monthly summary of updates? e,g,

Oct
Bitsreams
Mokamk  ver 5  (300MHs)

CGMiner
CKolivas ver 3000.1.00001  (yeah updates are my thing)

etc...etc...

P.S. it is all good and I appreciate your work...plus back it up with sheckles now and then

Unfortunately I'm in France on travel for my day job. And I had hoped to have much development time, but unfortunately that hasn't panned out. I've been extremely busy with no time but for work/eat/sleep. Hell this is the first time I've been online in days... I don't even know what's going on as far as recent developments are concerned.

I'm returning to Canada on Thursday, and I'll do my best to dedicate some time to getting some significant bitstream progress made then.

Sorry for the delays everyone. I'm well aware that each day is ticking closer to ROI problems. I'm doing my best to make time. (I have a cluster running myself now, and I need to get ROI on them too, so I feel you pain).

[tenzor]

It is more likely that the USB is screwed up but there is an ocassional thing that is power supply related. So try following this sequence in powering the rig up again up:

(1) Remove 12V power and ideally unplug all USB leads at Cairnsmore1s. If you happen to have a USB hub with a switch for on/off that can work as well as unplugging if it properly removes USB power. Do check that it does remove power some don't do this properly. Basically we want the boards to be fully de-powered before starting. This is also the only way also to reset the USB controller if it gets upset by sometime and we have seen that a few times.
(2) Power 12V and Controller LED is flashing on all boards and each FPGA section is powered and configured - LEDs bright.
(3) If you don't get Controller and section LEDs doing the right things modify the power up of the 12V by doing an initial momentary switch on then off and on again.
(4) Plug back in USB leads either one by one or use the hub switch if you have one.
(5) Make sure you leave enough time for USB to enumerate before firing up mining software and better still check USB ports/COMs are all correct and present in the host.

When using master/slave in Controller 1.5 it is important that both boards of the pair power up together otherwise one may fail to start up and that is only an issue for master/slave usage. We are going to try and improve the Controller to either remove, or reduce, this powering up dependence but that might be a few weeks before we have the time to do that.

Ok, didn't try exactly that yet, but I always wait some time before testing. USB on host enumerated, correct and presented. I can do a request using kano's python script. I can see during request flashing lights on pair of FPGA's (so they handling incoming request?), I can see even green light on one of them (got nonce?), but no response on host after timeout (70%) or wrong response (30%).
Boards failing after complete reset, when no power at all, even no usb powert to them. Tried starting boards then host, host then boards - no changes. With or without usb connected. Controller red light blinking pretty fast all time when PSU turned on and power cables connected.
So, for now, to resolve this issue, I power down slave, than master. Then power up slave/master or master/slave doesn'y matter.
Usually failing 1-3 boards out of 12, usually different.

Also, I received my boards with controller 1.5, but 6 of 12 didn't work in master/slave - FPGA-s LEDs was red after board boots. So, I flashed controller, it seems to be resolved for now.

Hmmm... How much power each board requires during start process? Have not measure voltage output on PSU during start.

[yohan]

Hmmm... How much power each board requires during start process? Have not measure voltage output on PSU during start.

During startup there are surges mainly due to the capacitors on the 12V and rails that come up more or less immediately. We have limited these surges by the way we turn on the main power supplies and that is the reasoning for the phased turn on that you will see on the board. That goes a long way to limiting surges. We don't know what the surge current peaks at as it changes dynamically as the boards power up and the highest current peak is extremely short duratiion and very hard to measure.

What do think is sometimes a problem is the rate at which the 12V rises from 0V to normal range. This rise rate depends on the number of CM1 boards in the rig and the power supply being used so it is different for more or less every rig. If is too slow then one of 2 things can happen. The first is that the Controller FPGA fails to configure. The second is that we think that the USB doesn't come out of reset correctly. To see if this is your issue try powering up with only some of your rig say half initially on the power supply. If these all come up ok repeat gradually adding boards to find where issues start to occur. If this does prove to be the root of your problems there are a couple of ways to proceed. The first argueably wasteful way is to either split your power supply into 2 power supplies or just use a bigger supply that might give a better ramp time. More crudely and needs care is to live plug in the power supply of the last few boards and after bringing up whatever of the stack will come up happily with the power supply.

[tenzor]

It is more likely that the USB is screwed up but there is an ocassional thing that is power supply related. So try following this sequence in powering the rig up again up:

(1) Remove 12V power and ideally unplug all USB leads at Cairnsmore1s. If you happen to have a USB hub with a switch for on/off that can work as well as unplugging if it properly removes USB power. Do check that it does remove power some don't do this properly. Basically we want the boards to be fully de-powered before starting. This is also the only way also to reset the USB controller if it gets upset by sometime and we have seen that a few times.
(2) Power 12V and Controller LED is flashing on all boards and each FPGA section is powered and configured - LEDs bright.
(3) If you don't get Controller and section LEDs doing the right things modify the power up of the 12V by doing an initial momentary switch on then off and on again.
(4) Plug back in USB leads either one by one or use the hub switch if you have one.
(5) Make sure you leave enough time for USB to enumerate before firing up mining software and better still check USB ports/COMs are all correct and present in the host.

When using master/slave in Controller 1.5 it is important that both boards of the pair power up together otherwise one may fail to start up and that is only an issue for master/slave usage. We are going to try and improve the Controller to either remove, or reduce, this powering up dependence but that might be a few weeks before we have the time to do that.

Did that, nothing changes. 1-2 boards still failing.

During startup there are surges mainly due to the capacitors on the 12V and rails that come up more or less immediately. We have limited these surges by the way we turn on the main power supplies and that is the reasoning for the phased turn on that you will see on the board. That goes a long way to limiting surges. We don't know what the surge current peaks at as it changes dynamically as the boards power up and the highest current peak is extremely short duratiion and very hard to measure.

What do think is sometimes a problem is the rate at which the 12V rises from 0V to normal range. This rise rate depends on the number of CM1 boards in the rig and the power supply being used so it is different for more or less every rig. If is too slow then one of 2 things can happen. The first is that the Controller FPGA fails to configure. The second is that we think that the USB doesn't come out of reset correctly. To see if this is your issue try powering up with only some of your rig say half initially on the power supply. If these all come up ok repeat gradually adding boards to find where issues start to occur. If this does prove to be the root of your problems there are a couple of ways to proceed. The first argueably wasteful way is to either split your power supply into 2 power supplies or just use a bigger supply that might give a better ramp time. More crudely and needs care is to live plug in the power supply of the last few boards and after bringing up whatever of the stack will come up happily with the power supply.

Looks like my PSU can only start 4 boards without any errors. That's strange... If I add 2 boards more, one will fail. I'm using PDB with OCZ ZT 750W PSU
If fails master board, it's slave still works.

[Cranky4u]

is there any chance of getting a monthly summary of updates? e,g,

Oct
Bitsreams
Mokamk  ver 5  (300MHs)

CGMiner
CKolivas ver 3000.1.00001  (yeah updates are my thing)

etc...etc...

P.S. it is all good and I appreciate your work...plus back it up with sheckles now and then

Unfortunately I'm in France on travel for my day job. And I had hoped to have much development time, but unfortunately that hasn't panned out. I've been extremely busy with no time but for work/eat/sleep. Hell this is the first time I've been online in days... I don't even know what's going on as far as recent developments are concerned.

I'm returning to Canada on Thursday, and I'll do my best to dedicate some time to getting some significant bitstream progress made then.

Sorry for the delays everyone. I'm well aware that each day is ticking closer to ROI problems. I'm doing my best to make time. (I have a cluster running myself now, and I need to get ROI on them too, so I feel you pain).

Cheers Glasswalker...appreciate the efforts