Bitcoin Forum
December 08, 2016, 10:30:34 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 [436] 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4823680 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
January 22, 2013, 12:25:00 AM
 #8701

I was mining on a local stratum install testing out some stuff when the stratum server ran into this message from cgminer:

Code:
2013-01-21 16:30:15-0500 [Protocol,4,192.168.2.100] Unhandled Error
...................
stratum.custom_exceptions.ProtocolException: Cannot decode message '{"params": ["gigavps.000", "8� 0002", "H��0000", "Hh� b334", "4c39cdf0"], "id": 2320, "method": "mining.submit"}'

Not sure what that is, but cgminer submitted it. All of the mining equipment running at the time was BFL singles or mini rigs.
Firstly, I presume in cgminer you also see a share reject for it?
What was the share reject message? Was it also corrupted?

Normal rejects (the very low % ones) in Stratum mining seem to only be like so
i.e. at the same time as the new block message:
[2013-01-04 07:28:17] Stratum from pool 0 detected new block
[2013-01-04 07:28:17] Rejected 13d41e5e Diff 12/8 BFL 0 pool 0 (Not current block.)

The message in (...) is up to the pool/proxy

Any other Stratum rejects will most likely represent a pool/proxy bug or cgminer problem

Disconnects, of course, should be like so (I get them at midnight coz I forcefully disconnect/reconnect my network)
[2013-01-22 00:00:21] Lost 1 shares due to stratum disconnect on pool 0

It would also be ideal to actually see the dump of the protocol on the wire.

On linux that can be got by:
tcpdump -n -l -i any -s 2000 -XX port 3333 | tee dump.log
 or
tcpdump -n -l -i any -s 2000 -XX port 3333 > dump.log
 if you don't want to watch it

Obviously the port number (3333) would match the Stratum port number you are using.
The log file should not be overwhelmingly large even for a MiniRig since Stratum doesn't need to transfer ridiculous amounts of data
The start of each packet dump includes a timestamp

Basically this will show if indeed cgminer/Curl is corrupting it or if the proxy is.

I have a memory overlay for cgminer that works on linux and windows - but not with GBT coz my overlay uses about 30x the RAM and thus with GBT uses way too much RAM
It's a single *.h that you only need to include in miner.h with no other changes anywhere else,
that does a lot of memory protection and testing (and also reports unfreed memory via the API)
This will find corruptions that happen before or after any malloc'ed data and report the line of code that allocated the data and if the corruption falls under a common subset, also crash cgminer when the corruption actually happens so the traceback shows the code that caused it
It wont find corruptions inside data - but hopefully, if there is a problem, it happens randomly enough to not just land in the middle of data
It's my lazy way for debugging bad pointers - coz reading random code usually doesn't find such errors without a lot more details or knowing the change that caused the bug (e.g. using a git bisect)
But a git bisect isn't always going to work either since code changes can move bad pointers around and thus hide and reveal them independently of the bug still existing.

Anyway, if you could first do the tcpdump and find the matching packet to be sure it is cgminer,
then chase me up in #cgminer and we can work out what to do next

The reason for wanting the tcpdump is as mentioned further up - where he was only seeing it with the proxy, not with direct pool access - and that could be the same problem you are seeing (but of course both could still be cgminer and not the proxy's fault - I've no idea at this point)

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
1481236234
Hero Member
*
Offline Offline

Posts: 1481236234

View Profile Personal Message (Offline)

Ignore
1481236234
Reply with quote  #2

1481236234
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481236234
Hero Member
*
Offline Offline

Posts: 1481236234

View Profile Personal Message (Offline)

Ignore
1481236234
Reply with quote  #2

1481236234
Report to moderator
ocminer
Legendary
*
Online Online

Activity: 1582



View Profile WWW
January 24, 2013, 08:26:57 PM
 #8702

Any chance we can see x6500 support in cgminer ?

I really dont want to use rip-off-scumbag-bfgminer just because of this..
I'm currently running them on MPBM but I'm not happy with it.

oc

suprnova pools - reliable mining pools - #suprnova on freenet
https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
January 24, 2013, 09:08:54 PM
 #8703

Any chance we can see x6500 support in cgminer ?

I really dont want to use rip-off-scumbag-bfgminer just because of this..
I'm currently running them on MPBM but I'm not happy with it.

oc
You have things backward: cgminer is trying to rip off BFGMiner.
From January until the middle of May (2012), I was the only one who had anything to do with device driver or FPGA support, with exception to Xiangfu who contributed a complete Icarus driver (based on my BitForce driver) in Feburary (which I maintained afterward). While Con was copying these improvements back into cgminer, I had no reason to make a separate release under another name - obviously a mistake that in hindsight has allowed Con & Kano to steal credit for it. It wasn't until April that Kano decided to begin forking the code (in the process reverting numerous bugfixes and improvements since he doesn't know how to use git), and Con backed him up on it because of their long history as friends. Shortly after Con got pissed off at ASICs being announced (since they obsolete the GPUs he had only ever worked with), he threw a fit on the forums making accusations that vendors didn't provide him devices (despite his never having been involved with this up to that point), and stopped accepting even bugfixes to the code he maintained from me, forcing me to effectively fork the rest of the codebase as well just to have the bugs fixed.

BFGMiner continues to advance in both core functionality and FPGA (and soon ASIC) support, as should be obvious by now.

Edit: Forgot to mention, nelisky contributed and maintained the Ztex driver from March until May.

Edit: I should perhaps also mention, there have been at least a couple of significant reorganizations delayed due to the cgminer team's aversion to collaboration and cooperation, but BFGMiner will be getting the result of this work very soon, maybe even before ASICs. It's a shame it took this long, though; Con is a great programmer, I don't know why he can't just work as a team.

Edit: Observe for yourselves, the authors of the code in question the moment before Kano forked it (in cgminer's own repository): BitForce and Icarus

streetuff
Full Member
***
Offline Offline

Activity: 150



View Profile
January 24, 2013, 09:10:20 PM
 #8704

go away!
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
January 25, 2013, 01:21:47 AM
 #8705

Any chance we can see x6500 support in cgminer ?

I really dont want to use rip-off-scumbag-bfgminer just because of this..
I'm currently running them on MPBM but I'm not happy with it.

oc
You have things backward: cgminer is trying to rip off BFGMiner.
From January until the middle of May (2012), I was the only one who had anything to do with device driver or FPGA support, with exception to Xiangfu who contributed a complete Icarus driver (based on my BitForce driver) in Feburary (which I maintained afterward). While Con was copying these improvements back into cgminer, I had no reason to make a separate release under another name - obviously a mistake that in hindsight has allowed Con & Kano to steal credit for it. It wasn't until April that Kano decided to begin forking the code (in the process reverting numerous bugfixes and improvements since he doesn't know how to use git), and Con backed him up on it because of their long history as friends. Shortly after Con got pissed off at ASICs being announced (since they obsolete the GPUs he had only ever worked with), he threw a fit on the forums making accusations that vendors didn't provide him devices (despite his never having been involved with this up to that point), and stopped accepting even bugfixes to the code he maintained from me, forcing me to effectively fork the rest of the codebase as well just to have the bugs fixed.

BFGMiner continues to advance in both core functionality and FPGA (and soon ASIC) support, as should be obvious by now.

Edit: Forgot to mention, nelisky contributed and maintained the Ztex driver from March until May.

Edit: I should perhaps also mention, there have been at least a couple of significant reorganizations delayed due to the cgminer team's aversion to collaboration and cooperation, but BFGMiner will be getting the result of this work very soon, maybe even before ASICs. It's a shame it took this long, though; Con is a great programmer, I don't know why he can't just work as a team.

Edit: Observe for yourselves, the authors of the code in question the moment before Kano forked it (in cgminer's own repository): BitForce and Icarus
The whole icarus issue is not up for debate.
I've posted about it many times.
You even once offered to PAY ME, the time I had spent to find the proof, when I proved you were wrong.

Then of course there is the code line count I did recently that ALSO proves: even in your git, there is more code by me than by you.
In the cgminer git there is ALMOST NO CODE by you in the driver-icarus.c file.

As for the BFL code - well firstly there is the obvious point about why conman got involved in the BFL code.
I have posted about this in detail before also.
I asked Luke-Jr to make a change and his reply implied it was too difficult for him to do it.
I wasn't going to change it coz I wasn't interested in spending time on code that could be rejected because at that point Luke-Jr had veto over the BFL code.
So eventually conman was convinced to make the code change himself.

Luke-Jr is just a complete fucking liar and I do not understand why anyone believes a word he says.
He is trash at the highest level when it comes to trying to claim ownership of code - he wants credit for other peoples work all the time.

What the heck, I'll do a code count also based on the clone git and the cgminer git:
Code:
git blame driver-bitforce.c | perl -n -e '/\s\((.*?)\s[0-9]{4}/ && print "$1\n"' | sort -f | uniq -c -w3
On the clone:
Code:
   191 Con Kolivas  
     61 Kano        
    222 Luke Dashjr  
    169 Paul Sheppard
      5 Xiangfu

And in my git - the new BFL code
Code:
   167 Con Kolivas  
    399 Kano        
    101 Luke Dashjr  
    100 Paul Sheppard

Note - I joined the two numbers together for ckolivas - he has two names in the counters that I totalled into one name.

So yes Luke wrote the biggest % of code in the old BFL driver (but not the biggest by much) - conman's rewrite code is almost as much as Luke-Jr's code (same for Paul Sheppard % also almost as high) - in the old code.
But again the reason for conman's rewrite of some of the code, that was a good performance gain, was because Luke-Jr had implied it was too difficult for him to do it.
Luke-Jr even copied ckolivas change back from cgminer to his clone as the git line counts clearly show ... and he has copied code back from my recent changes also.

His whole argument can be compared to this (that I'm sure most but the blind will see clearly):
When someone releases some code - you usually get the 'wow great' new code response from all who want it.
When the code is updated you also usually get the 'wow great' new code response from most who want the update.
Does everyone say 'wow yes I want the old original code from a year ago with bugs and problems and slower performance'? .....

Not even Luke-Jr says that - he wants the new better code from cgminer all the time - look at his latest release, how much code there is copied directly from cgminer?

However, does cgminer copy code back from Luke-Jr?
In the past 6 months we have rarely copied anything back.
We have made a lot of changes and a lot of new features wanted by many - that have been copied to the clone.

cgminer isn't a clone in any way - it is quite clearly the opposite! The clone releases, regularly contain many changes copied from cgminer.
Luke-Jr, seriously, GTFO of here.
Your lies are so damn blatantly easy to prove they are lies and so damn annoying how often you regurgitate these lies ... even here in the cgminer thread.
Go spew them to your ignorant acolytes in your clone thread - not here.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
January 25, 2013, 01:57:28 AM
 #8706

https://www.youtube.com/watch?v=j_oUjMxR0YU

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
January 25, 2013, 03:57:33 AM
 #8707

Welcome back. Home sweet home, eh?  Wink

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
January 25, 2013, 04:03:45 AM
 #8708

Thanks, I guess  Wink

I see nothing has changed while I was away... not that I expected anything more  Roll Eyes. Fortunately, I predicted well that 2.10.4 would be a cracker release and it has lived up to my expectations.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
January 25, 2013, 06:07:02 AM
 #8709

...
From January until the middle of May (2012), I was the only one who had anything to do with device driver or FPGA support, with exception to Xiangfu who contributed a complete Icarus driver (based on my BitForce driver) in Feburary (which I maintained afterward).
...
That's an easy one to prove is a lie ... and worth brining it up due to the outrageous ridiculousness of the claim.

I was the one who worked out problems with Xiangfu's Icarus driver before it worked ... and helped find the problems to get it working.
Go ask him yourself, you fool.
That's why I was given an Icarus board (and bought one at the same time)
The #cgminer IRC log shows that also ... and that you were in that IRC discussion ... around Feb 13 to Feb 15 2012

Now this leads to a very interesting question ... since Luke-Jr is so adamant about how he is the one and only with regards to all this device driver and FPGA code back when it was first written and anyone else's original involvement in it was next to nothing, why didn't he help Xiangfu fix his FPGA code interfacing with Luke-Jr's all brand new only he wrote it all code?
(I ended up helping Xiangfu coz Luke-Jr stopped helping before Xiangfu got anywhere near the driver/FPGA code ... Luke-Jr only helped Xiangfu make a test nonce and then disappeared for 24 hours ... followed by a reject to help with a question Xiangfu asked when he came back,  then comments about a bin2hex fix and a few OT comments for the following days)

The answer is simple, Luke-Jr's changes were not as all encompassing and self generated as he makes them out to be.
As one (of many) simple examples: his changes included copying ideas from ckolivas' GPU code as he clearly even states here:
https://github.com/ckolivas/cgminer/commit/a4d1fe1e5d116851d45624496327445db9660ff0

Again, as usual, he is copying ideas and claiming them to be his own.
In fact, as a lot of commits show around then, it is true to say that he often copied someone else's code from one place to another (and thus the git gives him credit to writing it) and the amount of code he actually provided to cgminer is less than even the git says it is.
... though I have already proven that: with the code I wrote in a file in his git that says he wrote it all, but indeed I wrote most of it - as is easy to see in the gits

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
ocminer
Legendary
*
Online Online

Activity: 1582



View Profile WWW
January 25, 2013, 07:18:39 AM
 #8710

So... Will there be x6500 support.. or not ?! Smiley

suprnova pools - reliable mining pools - #suprnova on freenet
https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 25, 2013, 07:41:51 AM
 #8711

Code:
Cannot decode message '{"params": ["gigavps.000", "8� 0002", "H��0000", "Hh� b334", "4c39cdf0"], "id": 2320, "method": "mining.submit"}'

Any other Stratum rejects will most likely represent a pool/proxy bug or cgminer problem

...

It would also be ideal to actually see the dump of the protocol on the wire.

Actually it is clearly bug in cgminer. That quoted json line is raw wire format and these binary data definitely should not be there. It looks like buffer overflow, there were such problems when stratum support has been introduced in cgminer.


Thank you for looking at this problem.

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
January 25, 2013, 07:52:21 AM
 #8712

So... Will there be x6500 support.. or not ?! Smiley
As I have answered indirectly all over the forum and directly in IRC as well.
I certainly will not be supporting x6500.

Without the hardware, there is no point in writing a new driver, as there are many issues with development and support of hardware that I do not have.

There is also the new issue that many devices will indeed no longer be worth even running shortly with the advent of ASIC ... though there is still no proof of anyone actually releasing any ASIC as yet.

I certainly see no reason at least for me to pour any effort into it.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
January 25, 2013, 08:00:53 AM
 #8713

Code:
Cannot decode message '{"params": ["gigavps.000", "8� 0002", "H��0000", "Hh� b334", "4c39cdf0"], "id": 2320, "method": "mining.submit"}'

Any other Stratum rejects will most likely represent a pool/proxy bug or cgminer problem

...

It would also be ideal to actually see the dump of the protocol on the wire.

Actually it is clearly bug in cgminer. That quoted json line is raw wire format and these binary data definitely should not be there. It looks like buffer overflow, there were such problems when stratum support has been introduced in cgminer.


Thank you for looking at this problem.
As I have already explained in IRC to gigavps - I'll need the raw wire tcpdump, for me to be sure it is cgminer (or the cgminer "Reject" showing it corrupt)
I have not said anywhere that it certainly "isn't" cgminer.
However, that dump is a dump from another piece of software that I don't even have the source code for, so I've no idea if that software was the cause of it or not.
No software is perfect, all code has bugs.
The tcpdump will clearly show which piece of software is the cause and the cgminer "Reject" message will also help to point out 'where' in cgminer it is, if it is cgminer.

As for your last comment (after the ',') that is meaningless.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 25, 2013, 08:13:23 AM
 #8714

kano, what exactly do you expect to see from that tcpdump? We gave you raw data which come to the server software (which is opensource, so you can check there's no obvious bug).

That line is untouched by the server side (except that receiving buffer is parsed by newlines) and you can see that only values in brackets are malformed. The chance that they got corrupted during the transfer or by server side is (comparing to possible bugs on sending side which prepares the message) *really* minimal.

I don't have a chance to take a dump of that communication, because my miner isn't affected by this bug, but I don't think we'll see anything helpful in tcpdump anyway.

I'm not bashing you or ckolivas for a bug in miner, we're just reporting it. That part after ',' wasn't meaningless, I just reminded that the problem may be in the similar area (buffer overflow) like in previous case. Please take a look at recent changes as this didn't happen in previous versions.

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 25, 2013, 10:12:25 AM
 #8715

Quote
and the cgminer "Reject" message will also help to point out 'where' in cgminer it is, if it is cgminer.

I forgot to respond this. When stratum server detects malformed message, it forcibly closes the connection (one cannot expect that server can read ID of message when message payload is malformed). So cgminer don't receive anything in this case.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
January 25, 2013, 12:24:35 PM
 #8716

So... Will there be x6500 support.. or not ?! Smiley
You heard them, they don't want to copy and more updates to the FPGA code because they think not doing so now helps their case for pretending it never happened.

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
January 25, 2013, 01:32:40 PM
 #8717

So... Will there be x6500 support.. or not ?! Smiley
You heard them, they don't want to copy and more updates to the FPGA code because they think not doing so now helps their case for pretending it never happened.
No moron, coz I've completely rewritten/replaced that retarded serial-USB library and we are working on our code as it stands - we don't want your code, that's why we haven't got much/any of it from you for a very long time.
The last major piece of code in cgminer from you was the piece of shit MMQ code that didn't even fucking work until I rewrote some of it.
Complete pain in the ass that you committed code to cgminer that didn't even work and you hadn't tested it ... or hadn't bothered to send the updates to actually make it work ... not the first time you've done that ...
Will be interesting to see what happens when some ASIC code is actually written and how it compares ... and if you just copy it from me or copy it and pretend you wrote it yourself or write it yourself from scratch Smiley

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
January 26, 2013, 12:00:06 PM
 #8718

2.10.4j 2.10.4m
An Xubuntu 11.04 x86_64 executable is in my github called cgminer-2.10.4j cgminer-2.10.4m
https://github.com/kanoi/cgminer-binaries
(it also works on Fedora 16 and 17)

Anyone interested in testing it (or my current git https://github.com/kanoi/cgminer if you wish to compile it yourself) please do.
I do not expect problems with it - but I'm pretty much the only one I'm certain who has tested it all - though others have tested some of the changes.

This includes all the pull request changes I've made since 2.10.4 including 1 since 2.10.4j up to 2.10.4m

oldest first:

   Kano    BFL libusb driver    cbf6c71
   Kano    BFL USB build changes    040ec58
   Kano    BFL report USB device numbers for init errors and allow faster 'reinit'    b099615
   Kano    BFL USB - README and FPGA-README    70b47a7
   Kano    BFL include all USB requirements    03c2cab
   Kano    BFL USB api.c usbstats    07db1ed
   Kano    BFL USB longer timeout    211b0f4
   Kano    Remember best share per pool and return in API pools    03f626e
   Kano    Correct API version to match docs    abaaf93
   Kano    zero (most) API stats    4c2f26e
   Kano    BFL USB correct usb stats id    44ec755
   Kano    miner.php optional user/pass login restrictions    910764d
   Kano    miner.php user/pass fix 'usr' is readonly    aaddf5b
   Kano    diffexactone pool diff1 used for share value calculation is ffffffff.… …    6382b0c
   Kano    rename device_api -> device_drv and all related api -> drv and add a … …    fe508ba
   Kano    device_drv missing drv for cpu and incorrect test    774944c
   Kano    device_drv - allow .name to be changed before add_cgpu()    f9b0751
   Kano    increase device status string length    400dc17
   Kano    api.c pgaenable not re-enabling the device - plus related debug    8b078fc
   Kano    API zero - zero statistics - all or bestshare - with optional on scre… …    8d59ab5
   Kano    BFL minimise first initialisation failure delay since it is common    72253d2
   Kano    Best Share readme    b169aa7
   Kano    USB automatically handle losing the device and report nodev in the API    2c16a73
   Kano    api.c update copyright year    0f6f6e3
   Kano    USB BFL transfer is only 64 bytes in a USB1.1 socket    cb0157a
   Kano    MMQ it's a bitstream    1162861
   Kano    MMQ include USB devpath in detection error messages    e10d766
   Kano    API stats - include pool network bytes + in miner.php    d3d8772
   Kano    usbutils.c release_cgpu() sets nodev    56b7396
   Kano    ICA use drv->name    be6f37b
   Kano    miner.php trim trailing zeros on some of the STATS numbers    a536eda
   Kano    BFL use #defined strings for work replies    f66818c
   Kano    BFL allow a 2nd init attempt if the 1st reply is unknown    54fc340
   Kano    USB move usbdev info that needs to stay around into usbinfo    b9c4769
   Kano    Capitalise driver long names used in applog messages    a2d83ad
   Kano    usbutils.c use correct config from found (not 0)    5f978c0
   Kano    USB usb_init() consistent err/warning/debug messages    61f5531
   Kano    USB system wide device locking on linux    2ab986a
   Kano    USB device locking NOOP for windows (for now)    eddd739
   Kano    usbutils free found if not used    753eeb3
   Kano    usbutils stats_initialised not set    78bbd60
   Kano    USB system wide device locking on windows    a324f52
   Kano    USB in linux use the expected kernel config to check and detach - and… …    8e4c3a5
   Kano    2.10.4j    a5139f4
   Kano    Stratum disconnect shares - count total against stale    ef5d3d8

additions since 2.10.4j
   Kano    MMQ must copy USB bus:device due to usbinfo change    381536a
   Kano    Split thr_info array into control_thr and mining_thr pointers so more… …    d6e5313
   Kano    mutex all access to mining_thr    421a364
   Kano    2.10.4m


English version of the most notable of the above:
New BFL USB driver that only uses libusb (and autodetects all BFLs)
miner.php optional password security
Best Share also recorded per pool and available from the API
API pgaenable fix (didn't work for multiple devices)
API zero statistics
BFL faster initialisation (noticeable if you have a MiniRig or multiple Singles)
USB automatically handle device disconnects and mark them 'nodev'
API stats include network byte stats (now count, data byte stats and network byte stats)
BFL try to initialise a second time if first time fails
USB system wide device locking if you run 2 or more cgminers they wont access the same device twice (windows and linux)
Make the work thread variable able to be dynamic

My git contains the updated API-README, FPGA-README and README
https://github.com/kanoi/cgminer

Now some important information about the BFL USB driver.
On linux, if you wish to switch back to the old 2.10.4a or earlier version, you'll need to unplug and re-plug in your FPGAs or reboot your rig.
On windows (as described in FPGA-README) you'll need to update your windows USB driver
I've tested it on linux and windows with a BFL FPGA Single and also on linux had someone test with a BFL FPGA MiniRig
I've asked Josh for access to a MiniRig for at least a few hours to test a larger number of connected USB devices, but not got that access yet.
I found it used to sometime miss finding the BFL due to getting the init message chopped in half, so it tries twice now - and I've not had it fail to spot the BFL, found either on the first or the second time, in all the restarts I've done since then - the first failure seems to be when cgminer is first run and the kernel driver is disconnected just before resetting and sending the init string

To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.4j
chmod +x cgminer-2.10.4j
md5sum cgminer-2.10.4j

9c17eb376d601cf1c5d19b83255e780e  cgminer-2.10.4j

wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.4m
chmod +x cgminer-2.10.4m
md5sum cgminer-2.10.4m

74567a1384fc5fdad9e0a6e6d9e04597  cgminer-2.10.4m


For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'
(however, as I mentioned above, there are new *README files in my git)

No problems so far on my GPU, 'BFL+MMQ+2xICA'

Since I'm no longer GPU mining, I just run it for a while on my single 6950 to see what happens

BFL+MMQ+ICAs (2.4GH/s) on OzCoin Stratum with fixed 8 diff

Almost the same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-g -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make

The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has cores enabled, it will dump a much more useful debug core.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
rs77063
Newbie
*
Offline Offline

Activity: 14


View Profile
January 27, 2013, 04:34:07 AM
 #8719

First, before we get to the problems, congrats on the fine software. This is the first miner I've actually gotten working on Linux, and it's not the first I tried either.

As you might guess, I've gotten it compiled under Linux (Debian Wheezy, 64bit) and it works. I did enable cpu mining as well as gpu. The configure results say everything is good, and getting the OpenCL found was a much longer journey than I thought it would be...

Code:
cgminer 2.10.4
------------------------------------------------------------------------

Configuration Options Summary:

  curses.TUI...........: FOUND: -lncurses
  OpenCL...............: FOUND. GPU mining support enabled
  scrypt...............: Disabled
  ADL..................: SDK NOT found, GPU monitoring support DISABLED


However when I run it with GPU mining, it segfaults. But if I disable GPU, it works.

Works:
Code:
cgminer -o http://pool.50btc.com:8332 -u username -p password -G -C

Segfaults:
Code:
cgminer -o http://pool.50btc.com:8332 -u username -p password

[2013-01-26 22:29:43] Started cgminer 2.10.4
 [2013-01-26 22:29:43] Started cgminer 2.10.4
 [2013-01-26 22:29:43] Probing for an alive pool
 [2013-01-26 22:29:44] Long-polling activated for http://5.9.207.236:8331/LPSegmentation fault


In case you need the -n output:
Code:
cgminer -n
 [2013-01-26 22:30:46] CL Platform 0 vendor: Advanced Micro Devices, Inc.                    
 [2013-01-26 22:30:46] CL Platform 0 name: AMD Accelerated Parallel Processing                    
 [2013-01-26 22:30:46] CL Platform 0 version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)                    
 [2013-01-26 22:30:46] Platform 0 devices: 1                    
 [2013-01-26 22:30:46]  0       Cedar                    
 [2013-01-26 22:30:46] 1 GPU devices max detected

What, if anything, am I doing wrong?
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
January 27, 2013, 04:40:09 AM
 #8720

Segfaults with GPU mining are usually one of: Dodgy hardware, dodgy driver or corrupted/mixed AMD APP SDK install. The last is the most common one. Clear out any SDK files you can find and install it again, and delete any .bin files generated in the cgminer directory.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 [436] 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!