Was it USB related or HDD?
Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 20. (Read 286370 times)
... and I've already forgotten what the problem was
Was it USB related or HDD?
Was it USB related or HDD?
I think I may have found a temporary fix to my problem ...
Congratulations.Just in case someone else someday runs into the same or equivalent problem, and while it is still fresh in your mind, could you give a very short description of what you uncovered, please?
--
If you want to wait a few days for validation, that makes sense. However, I do suggest jotting notes down now. It is amazing how fast little details can fade from memory.
I think I may have found a temporary fix to my problem and yes Debian did help alot in finding out what caused it.
Still be a few days before I'm sure if it is what was the problem.
Still be a few days before I'm sure if it is what was the problem.
Thanks for that. I'll get another draft up tonight with some tidying up and some clearer examples.
Remove the accidental quote in the cgminer line
Also note that I didn't create a 2.7.5a coz in the 2.7.5 release there is:
cgminer-2.7.5-win32/cgminer-fpgaonly.exe
... so ckolivas has already put the equivalent of my 2.7.5a in the cgminer windows binary file (from now on)
The reason this file exists (as you probably know but should also mention in the script) is that the default cgminer.exe file requires the ATI or nVidia OpenCL driver/SDK installed on windows or it won't run.
Also note that at the moment, ckolilvas is away and his download web site isn't working.
I have copied his windows and linux 2.7.5 binary archive files to my git download:
https://github.com/kanoi/cgminer/downloads
This windows one on my download page:
cgminer-2.7.5-win32.7z — cgminer2.7.5 ckolivas release file: windows 32bit (mingw)
It's been fixed
Code:
-G " -S
Also note that I didn't create a 2.7.5a coz in the 2.7.5 release there is:
cgminer-2.7.5-win32/cgminer-fpgaonly.exe
... so ckolivas has already put the equivalent of my 2.7.5a in the cgminer windows binary file (from now on)
The reason this file exists (as you probably know but should also mention in the script) is that the default cgminer.exe file requires the ATI or nVidia OpenCL driver/SDK installed on windows or it won't run.
I have copied his windows and linux 2.7.5 binary archive files to my git download:
https://github.com/kanoi/cgminer/downloads
This windows one on my download page:
cgminer-2.7.5-win32.7z — cgminer2.7.5 ckolivas release file: windows 32bit (mingw)
It's been fixed
Board #0017 is now flashed with hashvoodoo-175, but it had a problem with the clock, the red heartbeat leds don't flash but are always on. I'll re-flash it shortly.
Really? If it persists like this after a reflash, let me know, we can troubleshoot. It might be you actually have a "bad" board.
For some really basic troubleshooting:
- Which release was it? (the older one or newer one, both have a 175 release, you want the OLDER of the 2, the newer one has major stability issues due to a bug I introduced)
- You are using the correct matching HashVoodoo controller right? (not a stock enterpoint controller?)
Let me know if any of that helps (or just your reflash).
It was my bad .. I flashed the wrong bitstream, one of makomk's. I'm sorry to have caused confusion.
Meanwhile, I flashed the newer 175 release. I don't have access to the stats right now, but in the first hours after flashing, only FPGA-0 worked OK, the others had timeout waiting for confirmation.
After work, I'll flash the older 175 release ( http://cloud.github.com/downloads/pmumby/hashvoodoo-fpga-bitcoin-miner/hashvoodoo_release_08_16_2012.zip ), see how it works and report back.
I'm looking forward to try your next release. I hope you'll succeed in raising the clock while maintaining mining stability.
Code:
-G " -S
Also note that I didn't create a 2.7.5a coz in the 2.7.5 release there is:
cgminer-2.7.5-win32/cgminer-fpgaonly.exe
... so ckolivas has already put the equivalent of my 2.7.5a in the cgminer windows binary file (from now on)
The reason this file exists (as you probably know but should also mention in the script) is that the default cgminer.exe file requires the ATI or nVidia OpenCL driver/SDK installed on windows or it won't run.
I have copied his windows and linux 2.7.5 binary archive files to my git download:
https://github.com/kanoi/cgminer/downloads
This windows one on my download page:
cgminer-2.7.5-win32.7z — cgminer2.7.5 ckolivas release file: windows 32bit (mingw)
It's been fixed
Guys,
I've played a bit with CM1 back in July, but I'm not up to date with the latest best practices and not familiar with MPBM. Now I need to catch up, but trying to extract meaningful info from 110+ pages of this thread is driving me crazy.
I'm willing to announce a bounty of 20 BTC for a Quick-start Guide To Mining with CM1. Let's limit it to Windows for now. This guide should cover all the steps necessary to go from an unpacked box of CM1 board(s) to a fully configured rig that is happily hashing using current best practices. Yes, this should include setting up MPBM and Python environment for it.
The bounty will go to the first one who writes such Guide before September, 20th. It will be paid as soon as I'm able to successfully configure my boards following the proposed steps. Going forward, such Quick-start Guide will be very helpful for people new to CM1, so I invite others to increase the bounty if they are so inclined.
I've played a bit with CM1 back in July, but I'm not up to date with the latest best practices and not familiar with MPBM. Now I need to catch up, but trying to extract meaningful info from 110+ pages of this thread is driving me crazy.
I'm willing to announce a bounty of 20 BTC for a Quick-start Guide To Mining with CM1. Let's limit it to Windows for now. This guide should cover all the steps necessary to go from an unpacked box of CM1 board(s) to a fully configured rig that is happily hashing using current best practices. Yes, this should include setting up MPBM and Python environment for it.
The bounty will go to the first one who writes such Guide before September, 20th. It will be paid as soon as I'm able to successfully configure my boards following the proposed steps. Going forward, such Quick-start Guide will be very helpful for people new to CM1, so I invite others to increase the bounty if they are so inclined.
Could you give this a proof read :
http://btc.steveme.mailforce.net/CM1%20quickstart%20guide.html
Use cgminer 
That's all question about my code
Edit: and the version in my git 2.7.5i waiting to go into cgminer, has proper hardware error detection in it (among many other changes/fixes)
That's all question about my code
Edit: and the version in my git 2.7.5i waiting to go into cgminer, has proper hardware error detection in it (among many other changes/fixes)
Can anyone help me get BFGMiner working properly with the CM1 please?
I have MPBM working fine, submitting shares as it should, with controller rev 1.5 and the 210Mhz bitstream on all FPGAs.
I have compiled BFGMiner (i'm running RPi Raspbian linux distro) and I am launching it with the following command:
I have my pools in a bfgminer.conf file, and they are all loaded correctly on launch.
The problem is that BFGMiner is reporting no shares at all, even though the green lights are flashing on my Cairnsmore1's, yet it works fine in MPBM.
BFGMiner just outputs the readjustments and nothing else. Only 1 accepted share, yet the green lights have been flashing for a while now..
Also I noticed this in the BFGMiner ending session log after a 15 minute run -
Is that significant?
Any idea how I can get BFGMiner working?
I have MPBM working fine, submitting shares as it should, with controller rev 1.5 and the 210Mhz bitstream on all FPGAs.
I have compiled BFGMiner (i'm running RPi Raspbian linux distro) and I am launching it with the following command:
Code:
bfgminer -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB6 -S /dev/ttyUSB7 --icarus-timing short
I have my pools in a bfgminer.conf file, and they are all loaded correctly on launch.
The problem is that BFGMiner is reporting no shares at all, even though the green lights are flashing on my Cairnsmore1's, yet it works fine in MPBM.
BFGMiner just outputs the readjustments and nothing else. Only 1 accepted share, yet the green lights have been flashing for a while now..
Code:
[2012-09-13 00:46:02] Icarus 1 Re-estimate: Hs=2.380537e-09 W=2.384182e-03 read_count=101 fullnonce=10.227s
[2012-09-13 00:46:09] Icarus 3 Re-estimate: Hs=2.380921e-09 W=2.012963e-03 read_count=101 fullnonce=10.228s
[2012-09-13 00:46:16] Icarus 2 Re-estimate: Hs=2.380716e-09 W=2.740838e-03 read_count=101 fullnonce=10.228s
[2012-09-13 00:46:22] Icarus 0 Re-estimate: Hs=2.380969e-09 W=1.712761e-03 read_count=101 fullnonce=10.228s
Also I noticed this in the BFGMiner ending session log after a 15 minute run -
Code:
[2012-09-13 01:00:43] Work items generated locally: 1162
Any idea how I can get BFGMiner working?
Board #0017 is now flashed with hashvoodoo-175, but it had a problem with the clock, the red heartbeat leds don't flash but are always on. I'll re-flash it shortly.
Really? If it persists like this after a reflash, let me know, we can troubleshoot. It might be you actually have a "bad" board.
For some really basic troubleshooting:
- Which release was it? (the older one or newer one, both have a 175 release, you want the OLDER of the 2, the newer one has major stability issues due to a bug I introduced)
- You are using the correct matching HashVoodoo controller right? (not a stock enterpoint controller?)
Let me know if any of that helps (or just your reflash).
I just found the non-temporary page for Cairnsmore1:
http://enterpoint.co.uk/products/spartan-6-development-boards/cairnsmore-1/
ps. stats for my boards:
Board #0017 is now flashed with hashvoodoo-175, but it had a problem with the clock, the red heartbeat leds don't flash but are always on. I'll re-flash it shortly.
The other three boards with sn>600 are working fine with makomk's dcmwd4e-220:
http://enterpoint.co.uk/products/spartan-6-development-boards/cairnsmore-1/
ps. stats for my boards:
Board #0017 is now flashed with hashvoodoo-175, but it had a problem with the clock, the red heartbeat leds don't flash but are always on. I'll re-flash it shortly.
The other three boards with sn>600 are working fine with makomk's dcmwd4e-220:
Since no one gave any suggestions, just thought I'd let you know I'm going to try moving everything over to a Debian configuration.
To the best of my knowledge, it should work without any issues to run Cgminer and XBMC it's two main purposes on there.
Ubuntu, may have been the popular choice, but going back to a more stable and reliable OS, rather than user friendly one, will hopefully help.
To the best of my knowledge, it should work without any issues to run Cgminer and XBMC it's two main purposes on there.
Ubuntu, may have been the popular choice, but going back to a more stable and reliable OS, rather than user friendly one, will hopefully help.
Lethos,
I'm using ubuntu _server_ 12.04, and I'm not sure I do understand you correctly, but if you're running it from an USB stick I'd try to run it from an old HD or a SSD (small ones are cheap these days).
I'd also try not to use it as an HTPC at the same time.
If you try, install just the base server, and the ia32 libs.
No X server, no fancy desktop and so on.
Problems = parts^2.
spiccioli
Already tried that, that was the first things I tried when I did a fresh install of Ubuntu.
Why it's not working I don't know. But I've given up trying to fix it with in Ubuntu.
My only other options left after this is to assume it's not a software problem, but a hardware one.
Since no one gave any suggestions, just thought I'd let you know I'm going to try moving everything over to a Debian configuration.
To the best of my knowledge, it should work without any issues to run Cgminer and XBMC it's two main purposes on there.
Ubuntu, may have been the popular choice, but going back to a more stable and reliable OS, rather than user friendly one, will hopefully help.
To the best of my knowledge, it should work without any issues to run Cgminer and XBMC it's two main purposes on there.
Ubuntu, may have been the popular choice, but going back to a more stable and reliable OS, rather than user friendly one, will hopefully help.
Lethos,
I'm using ubuntu _server_ 12.04, and I'm not sure I do understand you correctly, but if you're running it from an USB stick I'd try to run it from an old HD or a SSD (small ones are cheap these days).
I'd also try not to use it as an HTPC at the same time.
If you try, install just the base server, and the ia32 libs.
No X server, no fancy desktop and so on.
Problems = parts^2.
spiccioli
I've been running Xubuntu 11.04 for over a year - stability in the extreme
(it's currently 2x6950, 2xIcarus, 1xBFL Single)
Meanwhile, if anyone was using my 2.7.5+ git master, I've updated it a bit and found the (minor) cause of why it was submitting the bad HW error shares rather than throwing them away.
That, and a bunch of other changes, are here in my master git (it also compiles as "2.7.5g" at the moment):
https://github.com/kanoi/cgminer
The pull request of it all to ckolivas is here:
https://github.com/ckolivas/cgminer/pull/310
It STILL has the minor HW loop bug (but that bug is in all versions of cgminer - so it's not a new one - and it doesn't cause any real trouble)
I'll get it fixed ... one day
My post in the cgminer thread about it:
https://bitcointalksearch.org/topic/m.1184415
(it's currently 2x6950, 2xIcarus, 1xBFL Single)
Meanwhile, if anyone was using my 2.7.5+ git master, I've updated it a bit and found the (minor) cause of why it was submitting the bad HW error shares rather than throwing them away.
That, and a bunch of other changes, are here in my master git (it also compiles as "2.7.5g" at the moment):
https://github.com/kanoi/cgminer
The pull request of it all to ckolivas is here:
https://github.com/ckolivas/cgminer/pull/310
It STILL has the minor HW loop bug (but that bug is in all versions of cgminer - so it's not a new one - and it doesn't cause any real trouble)
I'll get it fixed ... one day
My post in the cgminer thread about it:
https://bitcointalksearch.org/topic/m.1184415
Still find it strange though that it creates 4 extra ttyUSB entries, but only 2 are used...
This is normal. The FTDI chip used on the cairnsmore1 board (http://www.ftdichip.com/Products/ICs/FT4232H.htm) creates 4 UART ports. That's just how it works. Different bitstreams can make use of these ports for different purposes as they see fit. But from the computers perspective the FTDI will always make 4 serial ports. We don't have any direct control over that. They can be used in different configs, for example with an icarus chained bitstream like makomk's shortfin, it uses 2 as serial, and leaves the other two open for SPI/JTAG if I remember correctly.
On HashVoodoo, it uses all 4 ports, one per chip. (right now, but in the future it will have an option, which will be configurable by software to chain them in any config you like, for example use 1 port to drive several boards worth of chips)
Thanks!
Still find it strange though that it creates 4 extra ttyUSB entries, but only 2 are used...
This is normal. The FTDI chip used on the cairnsmore1 board (http://www.ftdichip.com/Products/ICs/FT4232H.htm) creates 4 UART ports. That's just how it works. Different bitstreams can make use of these ports for different purposes as they see fit. But from the computers perspective the FTDI will always make 4 serial ports. We don't have any direct control over that. They can be used in different configs, for example with an icarus chained bitstream like makomk's shortfin, it uses 2 as serial, and leaves the other two open for SPI/JTAG if I remember correctly.
On HashVoodoo, it uses all 4 ports, one per chip. (right now, but in the future it will have an option, which will be configurable by software to chain them in any config you like, for example use 1 port to drive several boards worth of chips)
And, btw, does your rig / mining now look good to you?
Yep
Still find it strange though that it creates 4 extra ttyUSB entries, but only 2 are used... But hashing speed is approx. 800 Mhz, so I guess all is good Thanks!!I will be writing a guide as well on how I had to fit it all together!
I compiled 2.7.5 also. (On Debian 'wheezy' 32bit.)
Don't remember the exact error message, but it was essentially a 'failed to open port'.
I have not yet tried executing cgminer from a cold boot. 'Perhaps' mpbm is not properly releasing/closing the ports when I shut it down.
Since I haven't done that cold boot test / done all the testing I can, I've not yet posted on the cgminer thread reporting a problem or asking for help.
Glad it's working for you.
And, btw, does your rig / mining now look good to you?
Don't remember the exact error message, but it was essentially a 'failed to open port'.
I have not yet tried executing cgminer from a cold boot. 'Perhaps' mpbm is not properly releasing/closing the ports when I shut it down.
Since I haven't done that cold boot test / done all the testing I can, I've not yet posted on the cgminer thread reporting a problem or asking for help.
Glad it's working for you.
And, btw, does your rig / mining now look good to you?
BTW, you're running cgminer? I've not been able to get that running on a Debian 7 release yet. Do you have any advice / observations about how you got it going?
Yes, I'm running cgminer 2.7.5, but on Ubuntu 12.04 64-bit. I didn't had to do anything special... What seems to be the problem?
Jump to: