Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 3. (Read 286370 times)
I have noticed that while using BFGminer 3.0.2, one of my CM1's would get detected and my Ztex would be registered. The other CM1 would not be registered even after executing modprobe. I found out that by removing Ztex first during boot up and allowing the CM1 script to run with modprobe as root, I can see that the are all registered. Plugging in the Ztex would be picked up afterwards.
I'm trying to run 9 Cairnsmore's off a rPi, using cgminer and the bitstream they came shipped with. They all work fine, but I can only seem to get 8 of the 9 running SIMULTANEOUSLY; /dev/ttyUSB10 /dev/ttyUSB11 just won't work, giving the ol' Icarus detect problem. I'm Scratching my head a bit. Any pointers on how I might resolve it?
Actually, just checked dmesg properly, which shows:
[ 1900.005211] ftdi_sio ttyUSB8: FTDI USB Serial Device converter now disconnected from ttyUSB8
[ 1900.005329] ftdi_sio 1-1.2.6:1.0: device disconnected
[ 1900.005997] ftdi_sio ttyUSB9: FTDI USB Serial Device converter now disconnected from ttyUSB9
[ 1900.006100] ftdi_sio 1-1.2.6:1.1: device disconnected
[ 1900.014160] ftdi_sio ttyUSB10: FTDI USB Serial Device converter now disconnected from ttyUSB10
[ 1900.014268] ftdi_sio 1-1.2.6:1.2: device disconnected
[ 1900.014981] ftdi_sio ttyUSB11: FTDI USB Serial Device converter now disconnected from ttyUSB11
[ 1900.015077] ftdi_sio 1-1.2.6:1.3: device disconnected
...the offending card
But as I said, I get any card to do this, it's not tied to one specifically, but seems to be just tied to ttyUSB8-11. Any ideas?
I had the same issue but Yohan sent me a PM and the most important instruction he gave me was as follows:
1. Power up the units.
2. Power up your PC, miner, etc.
3. Plug in the units to the USB hub/turn the USB hub on. Wait until all the units have the double orange LED.
4. Run the modprobe. And this part is important. PHYSICALLY LOOK at the units and make sure after you run the modprobe that they all activate. It can take a couple minutes.
This was my problem, they were in another room so I would run the modprobe, wait 2 seconds and start mining and it was super flaky.
I even had the modprobe in my mining script followed by a sleep 2;
I never saw anywhere that said the USB might take a while to pick them up.
So make sure you do this, this is the most important step.
Then, do #5, mine with your program. Only after you verify step #4 and that all devices have the proper lights and have had time to settle will the miner pick them all up.
Hope this helps.
I'm trying to run 9 Cairnsmore's off a rPi, using cgminer and the bitstream they came shipped with. They all work fine, but I can only seem to get 8 of the 9 running SIMULTANEOUSLY; /dev/ttyUSB10 /dev/ttyUSB11 just won't work, giving the ol' Icarus detect problem. I'm Scratching my head a bit. Any pointers on how I might resolve it?
Actually, just checked dmesg properly, which shows:
[ 1900.005211] ftdi_sio ttyUSB8: FTDI USB Serial Device converter now disconnected from ttyUSB8
[ 1900.005329] ftdi_sio 1-1.2.6:1.0: device disconnected
[ 1900.005997] ftdi_sio ttyUSB9: FTDI USB Serial Device converter now disconnected from ttyUSB9
[ 1900.006100] ftdi_sio 1-1.2.6:1.1: device disconnected
[ 1900.014160] ftdi_sio ttyUSB10: FTDI USB Serial Device converter now disconnected from ttyUSB10
[ 1900.014268] ftdi_sio 1-1.2.6:1.2: device disconnected
[ 1900.014981] ftdi_sio ttyUSB11: FTDI USB Serial Device converter now disconnected from ttyUSB11
[ 1900.015077] ftdi_sio 1-1.2.6:1.3: device disconnected
...the offending card
But as I said, I get any card to do this, it's not tied to one specifically, but seems to be just tied to ttyUSB8-11. Any ideas?
Note for people with USB stability problems: try a piece of clear tape covering the 5V connector (on the right when you look at the connectors from above) in the plug you connect to your USB hub or server, I was fed up trying to work out which combination of power supply and USB hub/port would work and it seems it helps (no disconnect for 2 days now) and is easily reversible.
Make it longer than the full length of the connector and make it wrap around the exterior so that inserting the plug won't push it inside (sorry no picture, you'll have to try it for yourself).
Make it longer than the full length of the connector and make it wrap around the exterior so that inserting the plug won't push it inside (sorry no picture, you'll have to try it for yourself).
I'm totally not understanding your post?
I'm trying to run 9 Cairnsmore's off a rPi, using cgminer and the bitstream they came shipped with. They all work fine, but I can only seem to get 8 of the 9 running SIMULTANEOUSLY; /dev/ttyUSB10 /dev/ttyUSB11 just won't work, giving the ol' Icarus detect problem. I'm Scratching my head a bit. Any pointers on how I might resolve it?
Note for people with USB stability problems: try a piece of clear tape covering the 5V connector (on the right when you look at the connectors from above) in the plug you connect to your USB hub or server, I was fed up trying to work out which combination of power supply and USB hub/port would work and it seems it helps (no disconnect for 2 days now) and is easily reversible.
Make it longer than the full length of the connector and make it wrap around the exterior so that inserting the plug won't push it inside (sorry no picture, you'll have to try it for yourself).
Make it longer than the full length of the connector and make it wrap around the exterior so that inserting the plug won't push it inside (sorry no picture, you'll have to try it for yourself).
We are often asked how high can we stack. Does this answer the question?
If you are running the default bitstreams (makomk) then your you shoulf be using Icarus worker in MPBM. The Cairnsmore setting is for hashvoodoo bitstreams.
But one last note.
As you know, the rPi is a minimally powerful machine. It cuts it with MPBM, but just barely.
For example:
running the BFL Single with MPBM on the rPi lightly overclocked to 800mhz the BFL settles down to an "Average MH/s" of 787.xx.
running the same BFL Single with MPBM on a quad-core 2.66ghz Mac Pro it settles down to 794.xx.
Almost a whole 1% faster.
I can't give the same comparative values for the CM1s since I could never get them to work on OS X.
-- edit
I mention this because either cgminer or bfgminer will put less of a compute strain on the rPi. And since you're running the stock CM flash you shouldn't really *need* to be running MPBM. (Unless you just prefer it. Which I happen to. In addition to MPBM running the dynamic clock CM better.)
-- edit 2 (And one more thing.)
I've also found that MPBM on the rPi runs just a small bit better / faster if I set it up with GetWork "Work Sources" running through slush's stratum proxy than by using the built in stratum Work Sources.
YMMV.
As you know, the rPi is a minimally powerful machine. It cuts it with MPBM, but just barely.
For example:
running the BFL Single with MPBM on the rPi lightly overclocked to 800mhz the BFL settles down to an "Average MH/s" of 787.xx.
running the same BFL Single with MPBM on a quad-core 2.66ghz Mac Pro it settles down to 794.xx.
Almost a whole 1% faster.
I can't give the same comparative values for the CM1s since I could never get them to work on OS X.
-- edit
I mention this because either cgminer or bfgminer will put less of a compute strain on the rPi. And since you're running the stock CM flash you shouldn't really *need* to be running MPBM. (Unless you just prefer it. Which I happen to. In addition to MPBM running the dynamic clock CM better.)
-- edit 2 (And one more thing.)
I've also found that MPBM on the rPi runs just a small bit better / faster if I set it up with GetWork "Work Sources" running through slush's stratum proxy than by using the built in stratum Work Sources.
YMMV.
did this and as icarus worker and it started 
Congratulations! 
Now we can both go to bed.
And here's another thought.
I have encountered problems with my CM1s if I don't bring them up in the sequence they like.
1) Computer and USB hub on but MPBM not running
2) disconnect CM1s from USB
3) power down CM1
4) power up CM1 and wait for it to be fully stable
5) connect CM1 to USB
6) verify /dev/ttyUSBxx are present for the CM1
7) start MPBM
Now, this just might be an issue due to my running a more experimental flash than the stock flavor. But it is what I've had to do.
Key step: Never connect the CM1 to USB until it is fully powered up / stable.
I have encountered problems with my CM1s if I don't bring them up in the sequence they like.
1) Computer and USB hub on but MPBM not running
2) disconnect CM1s from USB
3) power down CM1
4) power up CM1 and wait for it to be fully stable
5) connect CM1 to USB
6) verify /dev/ttyUSBxx are present for the CM1
7) start MPBM
Now, this just might be an issue due to my running a more experimental flash than the stock flavor. But it is what I've had to do.
Key step: Never connect the CM1 to USB until it is fully powered up / stable.
did this and as icarus worker and it started
And here's another thought.
I have encountered problems with my CM1s if I don't bring them up in the sequence they like.
1) Computer and USB hub on but MPBM not running
2) disconnect CM1s from USB
3) power down CM1
4) power up CM1 and wait for it to be fully stable
5) connect CM1 to USB
6) verify /dev/ttyUSBxx are present for the CM1
7) start MPBM
Now, this just might be an issue due to my running a more experimental flash than the stock flavor. But it is what I've had to do.
Key step: Never connect the CM1 to USB until it is fully powered up / stable.
I have encountered problems with my CM1s if I don't bring them up in the sequence they like.
1) Computer and USB hub on but MPBM not running
2) disconnect CM1s from USB
3) power down CM1
4) power up CM1 and wait for it to be fully stable
5) connect CM1 to USB
6) verify /dev/ttyUSBxx are present for the CM1
7) start MPBM
Now, this just might be an issue due to my running a more experimental flash than the stock flavor. But it is what I've had to do.
Key step: Never connect the CM1 to USB until it is fully powered up / stable.
And you might give a try stepping through the USB ports one at a time as an icarus worker.
Though I doubt that is the problem of the moment since you are getting a failure to open port.
Not some sort of 'unexpected reply'.
Though I doubt that is the problem of the moment since you are getting a failure to open port.
Not some sort of 'unexpected reply'.
And the python --version:
Python 2.7.3
Python 2.7.3
creating them as cairnsmore.
tried 1 at a time.
tried 1 at a time.
Well that looks effectively the same as mine.
My BFL Single is on another machine ATM doing some testing, so 0 - 7 is both my CM1's.
AH, here's a thought, with my flash each FPGA chip gets its own comm line / USB port. But, IIRC, with the standard flash things are substantially different.
Have you tried stepping through one at a time?
I.e., try only one worker at /dev/ttyUSB0 .
If no joy, delete that worker and try /dev/ttyUSB1 .
etc.
Also, are you creating icarus workers or cairnsmore in mpbm?
-- edit
Got the image. Looks as I would expect.
Here is my "uname -a" output:
Linux xxxxx 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux
My BFL Single is on another machine ATM doing some testing, so 0 - 7 is both my CM1's.
AH, here's a thought, with my flash each FPGA chip gets its own comm line / USB port. But, IIRC, with the standard flash things are substantially different.
Have you tried stepping through one at a time?
I.e., try only one worker at /dev/ttyUSB0 .
If no joy, delete that worker and try /dev/ttyUSB1 .
etc.
Also, are you creating icarus workers or cairnsmore in mpbm?
-- edit
Got the image. Looks as I would expect.
Here is my "uname -a" output:
Linux xxxxx 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux
ls -la /dev/ttyUSB*
crw-rw-rwT 1 root dialout 188, 0 Jun 5 00:54 /dev/ttyUSB0
crw-rw---T 1 root dialout 188, 1 Jun 5 00:47 /dev/ttyUSB1
crw-rw---T 1 root dialout 188, 2 Jun 5 00:54 /dev/ttyUSB2
crw-rw---T 1 root dialout 188, 3 Jun 5 00:53 /dev/ttyUSB3
crw-rw---T 1 root dialout 188, 4 Jun 5 00:53 /dev/ttyUSB4
ttyUSB0 is the single
picture is =
http://imageshack.us/photo/my-images/211/testzt.png/
crw-rw-rwT 1 root dialout 188, 0 Jun 5 00:54 /dev/ttyUSB0
crw-rw---T 1 root dialout 188, 1 Jun 5 00:47 /dev/ttyUSB1
crw-rw---T 1 root dialout 188, 2 Jun 5 00:54 /dev/ttyUSB2
crw-rw---T 1 root dialout 188, 3 Jun 5 00:53 /dev/ttyUSB3
crw-rw---T 1 root dialout 188, 4 Jun 5 00:53 /dev/ttyUSB4
ttyUSB0 is the single
picture is =
http://imageshack.us/photo/my-images/211/testzt.png/
In my last post I have an alias for ll='ls -la', if that wasn't obvious.
If you put a screen cap in your last post, I'm not seeing it.
If you put a screen cap in your last post, I'm not seeing it.
In the "Worker editor" you are supplying the "Port:" as "/dev/ttyUSB1", etc.?
-- edit
Also, I'm sure you remembered to stop any executing instances of cgminer or bfgminer which were previously running.
-- edit
And let's double check those permissions down in /dev
xx@xxxx ~ $ ll /dev/ttyUSB*
crw-rw---T 1 root dialout 188, 0 Jun 4 23:49 /dev/ttyUSB0
crw-rw---T 1 root dialout 188, 1 Jun 4 23:49 /dev/ttyUSB1
crw-rw---T 1 root dialout 188, 2 Jun 4 23:49 /dev/ttyUSB2
crw-rw---T 1 root dialout 188, 3 Jun 4 23:49 /dev/ttyUSB3
crw-rw---T 1 root dialout 188, 4 Jun 4 23:49 /dev/ttyUSB4
crw-rw---T 1 root dialout 188, 5 Jun 4 23:49 /dev/ttyUSB5
crw-rw---T 1 root dialout 188, 6 Jun 4 23:49 /dev/ttyUSB6
crw-rw---T 1 root dialout 188, 7 Jun 4 23:50 /dev/ttyUSB7
-- edit
Also, I'm sure you remembered to stop any executing instances of cgminer or bfgminer which were previously running.
-- edit
And let's double check those permissions down in /dev
xx@xxxx ~ $ ll /dev/ttyUSB*
crw-rw---T 1 root dialout 188, 0 Jun 4 23:49 /dev/ttyUSB0
crw-rw---T 1 root dialout 188, 1 Jun 4 23:49 /dev/ttyUSB1
crw-rw---T 1 root dialout 188, 2 Jun 4 23:49 /dev/ttyUSB2
crw-rw---T 1 root dialout 188, 3 Jun 4 23:49 /dev/ttyUSB3
crw-rw---T 1 root dialout 188, 4 Jun 4 23:49 /dev/ttyUSB4
crw-rw---T 1 root dialout 188, 5 Jun 4 23:49 /dev/ttyUSB5
crw-rw---T 1 root dialout 188, 6 Jun 4 23:49 /dev/ttyUSB6
crw-rw---T 1 root dialout 188, 7 Jun 4 23:50 /dev/ttyUSB7
Jump to: