kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 13, 2012, 01:42:11 AM |
|
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)
|
|
|
|
steveme
Newbie
Offline
Activity: 37
Merit: 0
|
|
September 13, 2012, 02:55:25 AM |
|
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.
Could you give this a proof read : http://btc.steveme.mailforce.net/CM1%20quickstart%20guide.html
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 13, 2012, 04:01:35 AM |
|
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
|
|
|
|
hm
Member
Offline
Activity: 107
Merit: 10
|
|
September 13, 2012, 08:21:45 AM Last edit: September 13, 2012, 08:35:53 AM by hm |
|
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.
|
|
|
|
steveme
Newbie
Offline
Activity: 37
Merit: 0
|
|
September 13, 2012, 10:42:59 AM |
|
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
|
|
|
|
Lethos
|
|
September 13, 2012, 10:46:41 AM |
|
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.
|
|
|
|
LazyOtto
|
|
September 13, 2012, 11:02:01 AM |
|
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.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 13, 2012, 11:57:02 AM |
|
... and I've already forgotten what the problem was Was it USB related or HDD?
|
|
|
|
Glasswalker
|
|
September 13, 2012, 12:06:05 PM |
|
I'm looking forward to try your next release. I hope you'll succeed in raising the clock while maintaining mining stability. Yes, I just finished the smartxplorer run, and unfortunately it encountered some problems I'm tweaking some more settings now and re-running it. The new release works beautifully... But at it's current clock speed it's only about "equal" to the 175 release, so I wanted to push the clock higher before "releasing" it. I know this thing can get up to 180Mhz+ while meeting timing for a Spartan6 LX150 -2 speed grade chip. And that would mean with overclock, well over 200Mhz But I've got to find the "magic" combination of settings that will coax the bloody Xilinx toolchain to produce a working bitstream... I'll post another update once I have it.
|
|
|
|
Lethos
|
|
September 13, 2012, 12:15:02 PM |
|
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. Probably best to wait a while to really confirm really what was causing it. Since I don't know for sure if my temporary fix or it's more permanent solution will work. So I don't know for sure the follow to be true. However the reason for the entire system slowly crashing, while still kind of working, was the usb stick was becoming undetectable, either by becoming unmounted or ejected, as soon as any of the CM1's was connected via usb. I use a wireless mouse (usb bluetooth) and usb thumb drive since the beginning, it has always been that way, but this most recent problem only effect the thumb drive. I even tested if it temporarily effected the mouse and it did not. Only programs which was entirely in memory continued to work, anything currently being access form the stick, disappeared. This lead to a slow but eventual system crash as more and more programs realised some quicker than others than it could not access it's files. Debian has more system level and diagnostic programs installed by default that work entirely in memory, that were easy to find out how and what occurred and to get it working again. Btw I don't recommend ever yanking out a usb in mid-use, it's more obvious now how many orphaned files it has, while it didn't cause any permanent damage, I'd bet it would eventually. While I've made only minor hardware changes since I got the system (Replacing a usb hub), nothing has changed recently, they did not coincide with the timing of this problem, it was a software change that allowed me to uncover this problem. Getting a new powered usb hub. Gone through 2 since I got it, it also worked fine without them too for a while, connecting directly to the usb ports on the board, actually was most stable with it, surprisingly. Hence while I'm uncertain if it will actually fix it, but I figured if the thumb drive could drop like that, only thing that could make it do that is a lack of power to maintain it, according to what little log info I have, it's not a software call or command that issued it.
|
|
|
|
Lethos
|
|
September 13, 2012, 12:15:32 PM |
|
I'm looking forward to try your next release. I hope you'll succeed in raising the clock while maintaining mining stability. Yes, I just finished the smartxplorer run, and unfortunately it encountered some problems I'm tweaking some more settings now and re-running it. The new release works beautifully... But at it's current clock speed it's only about "equal" to the 175 release, so I wanted to push the clock higher before "releasing" it. I know this thing can get up to 180Mhz+ while meeting timing for a Spartan6 LX150 -2 speed grade chip. And that would mean with overclock, well over 200Mhz But I've got to find the "magic" combination of settings that will coax the bloody Xilinx toolchain to produce a working bitstream... I'll post another update once I have it. I'll be happy to test your next one Glasswalker.
|
|
|
|
|
Lethos
|
|
September 13, 2012, 12:36:22 PM |
|
I believe that to be a different but similar problem. Not ruling it out of course.
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
|
September 13, 2012, 12:44:18 PM |
|
I believe that to be a different but similar problem. Not ruling it out of course. The side affect is that the USB persistent filesystem regularly gets corrupted. Without fixing the dismount on shutdown, and allowing fsck on boot, you can expect all sorts of large and small weird problems due to random file corruption...
|
|
|
|
Lethos
|
|
September 13, 2012, 12:56:21 PM |
|
I believe that to be a different but similar problem. Not ruling it out of course. The side affect is that the USB persistent filesystem regularly gets corrupted. Without fixing the dismount on shutdown, and allowing fsck on boot, you can expect all sorts of large and small weird problems due to random file corruption... True, it probably would, but the system doesn't (yet) suffer any bad issues from these resets, it operates fine now and has done so until the usb triggered it to drop the thumb drive. For now I have managed to avoid that occurring again.
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
September 13, 2012, 12:57:33 PM |
|
However the reason for the entire system slowly crashing, while still kind of working, was the usb stick was becoming undetectable, either by becoming unmounted or ejected, as soon as any of the CM1's was connected via usb. I use a wireless mouse (usb bluetooth) and usb thumb drive since the beginning, it has always been that way, but this most recent problem only effect the thumb drive. I even tested if it temporarily effected the mouse and it did not.
Hi Lethos, this is a problem which surfaced in the past, see old thread messages, where attaching a usb device sometimes makes a different one to disappear. If I'm not wrong this problem was on windows back then. Anyway, good to know it happens on linux as well. spiccioli
|
|
|
|
Lethos
|
|
September 13, 2012, 01:07:52 PM |
|
However the reason for the entire system slowly crashing, while still kind of working, was the usb stick was becoming undetectable, either by becoming unmounted or ejected, as soon as any of the CM1's was connected via usb. I use a wireless mouse (usb bluetooth) and usb thumb drive since the beginning, it has always been that way, but this most recent problem only effect the thumb drive. I even tested if it temporarily effected the mouse and it did not.
Hi Lethos, this is a problem which surfaced in the past, see old thread messages, where attaching a usb device sometimes makes a different one to disappear. If I'm not wrong this problem was on windows back then. Anyway, good to know it happens on linux as well. spiccioli Must of missed that (or don't remember), I've just find it odd, what could of caused it to just start happening. At least I know why now, I don't even know for sure if a new powered hub will help.
|
|
|
|
norulezapply
|
|
September 13, 2012, 01:43:29 PM |
|
Just incase anyone was interested, BFGMiner isn't working with my Cairnsmore1's but CGMiner is working fine
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
|
September 13, 2012, 04:05:06 PM |
|
Must of missed that (or don't remember), I've just find it odd, what could of caused it to just start happening. At least I know why now, I don't even know for sure if a new powered hub will help.
Lethos, I don't think a powered hub can help you here since it is an OS/driver problem as far as I know. spiccioli
|
|
|
|
LazyOtto
|
|
September 13, 2012, 04:16:08 PM |
|
... I've just find it odd, what could of caused it to just start happening. ...
'Maybe' a small increase in ambient temperature? Are you using the makomk bitstream and are any of your CM1 FPGAs generating over 0.5% Invalids? For me, USB related problems went away when I stopped connecting a USB cable to a board which is generating 2.25% invalids. (By daisy chaining the boards and making the one with about 0.2% invalids the Master.) With this approach I've been operating four days continuously whereas before the reconfiguration I had two failures within 24 hrs.
|
|
|
|
|