OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[slush]

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]

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

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.

[kano]

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.

[slush]

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]

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]

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

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]

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

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

[kano]

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.

[rs77063]

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]

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.

[rs77063]

That did it. Thanks. BTW, out of all 5 miners I've tried to get working (and of the 3 I did), your instructions were the clearest, by far.

Two more questions: when I try to run cgminer under Windows, I don't get much in the way of feedback. In linux I get a nice text display with the first few lines looking like this:

Code:

cgminer version 2.10.4 - Started: [2013-01-27 09:29:48] CPU Algo: sse2_64
--------------------------------------------------------------------------------
 (5s):204.02M (avg):203.37Mh/s | Q:4  A:0  R:0  HW:0  E:0%  U:0.0/m
 ST: 2  SS: 0  DW: 0  NB: 1  LW: 18  GF: 0  RF: 0  WU: 0.6
 Connected to pool.50btc.com diff 1 with LP as user username
 Block: 002bcdecd0575daf...  Diff:2.97M  Started: [09:29:48]  Best share: 0

<more lines snipped>

But in Windows, using the pre-compiled binaries, all I get is this:

Code:

[2013-01-27 09:36:09] Started cgminer 2.10.4
 [2013-01-27 09:36:09] Probing for an alive pool
 [2013-01-27 09:36:10] Long-polling activated for http://5.9.207.236:8331/LP
 [2013-01-27 09:36:10] Disabling extra threads due to dynamic mode.
 [2013-01-27 09:36:10] Tune dynamic intensity with --gpu-dyninterval
 [2013-01-27 09:36:12] Thread 1 being disabled

None of the keys work either, such as q, d, s, p, g. It does seem to use a good bit of CPU time though. Is this normal?

Second question: Looking back at my now running GPU mining in Linux, I'm getting

Code:

GPU0: invalid nonce - HW error

Does this mean my video card is bad? Certainly seems to output video OK.

[-ck]

The windows and linux output is meant to look the same. Usually when something doesn't work on the windows version, like the text user interface, your virus software has been silently fucking you over by deleting files without you knowing - mining software is often falsely accused of being viruses.

Hardware errors are not uncommon at high overclocks or high temps. Just bump the clocks down a little or drop temps further. If you haven't overclocked, it may be a sign of some hardware instability but likely is harmless.

[rs77063]

Just bump the clocks down a little or drop temps further. If you haven't overclocked, it may be a sign of some hardware instability but likely is harmless.

Never overclocked it. In fact, after reading your post, I've now underclocked it*. Way underclocked it and I'm still getting those errors.

Before (original factory settings):

Code:

(~)$ aticonfig --adapter=0 --od-getclocks

Adapter 0 - ATI Radeon HD 5450     
                            Core (MHz)    Memory (MHz)
           Current Clocks :    650           450
             Current Peak :    650           450
  Configurable Peak Range : [400-880]     [450-900]
                 GPU load :    96%

After:

Code:

(~)$ aticonfig --adapter=0 --od-getclocks

Adapter 0 - ATI Radeon HD 5450     
                            Core (MHz)    Memory (MHz)
           Current Clocks :    250           300
             Current Peak :    250           300
  Configurable Peak Range : [400-880]     [450-900]
                 GPU load :    96%

The "hardware instability" interests me though. Wondering if cgminer could be used to test for flakey video cards...

As for harmless, I beg to differ on that. It's stopping me from GPU mining effectively. Not a single share off my GPU.
* For anyone who finds this post and wonders how I did that: aticonfig --adapter=0 --od-setclocks=250,300

[galaxyAbstractor]

I don't seem to be able to download, because: https://i.imgur.com/dJMcv0G.png. Seems like the only way to download and install would be to disable avast all together, as I would assume it would continue popup as long as the file is on the drive. Ideas?

[BitMinerN8]

I don't seem to be able to download, because: https://i.imgur.com/dJMcv0G.png. Seems like the only way to download and install would be to disable avast all together, as I would assume it would continue popup as long as the file is on the drive. Ideas?

I'm not familiar with Avast, but maybe you could look into file/folder exclusions? I believe that has worked for others in the past with other AV products.

[MashRinx]

When I initially started mining, I had issues with false-positives from several different Antivirus products and even adding the file/folder exclusions didn't help.  If I remember correctly, Avast was one that I never was able to resolve so I moved on to something else. 

That's been over a year ago though, so they may have improved how their exclusions worked from when I tried.

[crazyates]

2.10.4j

Question: Will these updates be merged into conman's 2.10.5? When will that happen?

[kano]

2.10.4j

Question: Will these updates be merged into conman's 2.10.5? When will that happen?

Yes they are very likely to be part of 2.10.5 - but all the major changes in there are USB/FPGA/ASIC related so until an actual ASIC turns up, I'm not sure if ckolivas wants the terror of looking through my changes and committing (or rejecting) them yet

This pull request to ckolivas has them all up to 'm':
https://github.com/ckolivas/cgminer/pull/380

It's currently at + 1,859 additions - 924 deletions
So there's quite a bit to it.

Actually I probably should delete 2.10.4j ... and make a 2.10.4m ... 'm' will be the last safe one for a short while.
... also, 'j' causes an incorrect message if your MMQ fails - and I'm not sure if there are other side effects to that message.

Well I'm working on USB hotplug at the moment.
Though I'll work in the usb2 branch - not the master for the real hotplug code.
The last lot of changes (m) were the lead up to getting it ready for USB hotplug, now I gotta actually do it

Actually - that made me decide - OK I've made an 'm' now in my downloads and also - that's where my master branch in my git will stop while I work on hotplug
I've also deleted the 2.10.4j version since it had that minor bug that is fixed in 2.4.10m
https://github.com/kanoi/cgminer-binaries

And of course my git master branch:
https://github.com/kanoi/cgminer

Edit: 'j' post on the previous page now updated to 'm'
https://bitcointalk.org/index.php?topic=28402.msg1480806#msg1480806

[PatMan]

2.10.4j

Question: Will these updates be merged into conman's 2.10.5? When will that happen?

Yes they are very likely to be part of 2.10.5 - but all the major changes in there are USB/FPGA/ASIC related so until an actual ASIC turns up, I'm not sure if ckolivas wants the terror of looking through my changes and committing (or rejecting) them yet

This pull request to ckolivas has them all up to 'm':
https://github.com/ckolivas/cgminer/pull/380

It's currently at + 1,859 additions - 924 deletions
So there's quite a bit to it.

Actually I probably should delete 2.10.4j ... and make a 2.10.4m ... 'm' will be the last safe one for a short while.
... also, 'j' causes an incorrect message if your MMQ fails - and I'm not sure if there are other side effects to that message.

Well I'm working on USB hotplug at the moment.
Though I'll work in the usb2 branch - not the master for the real hotplug code.
The last lot of changes (m) were the lead up to getting it ready for USB hotplug, now I gotta actually do it

Actually - that made me decide - OK I've made an 'm' now in my downloads and also - that's where my master branch in my git will stop while I work on hotplug
I've also deleted the 2.10.4j version since it had that minor bug that is fixed in 2.4.10m
https://github.com/kanoi/cgminer-binaries

And of course my git master branch:
https://github.com/kanoi/cgminer

Edit: 'j' post on the previous page now updated to 'm'
https://bitcointalk.org/index.php?topic=28402.msg1480806#msg1480806

Thanks again Kano. Loaded & running, all good.

[YipYip]

Trying to get a Saphire 5970 to run up

I have 3 XFX Blk Edition untis that are working well

The Saphire just by itself will run for about 30 seconds and then White/blue screen  ...from reading it is being driven too hard

Here are the settings

cgminer --scrypt -o http://yourpool.com -u username -p password --thread-concurrency 5000-8000 -I 18 -g 1 -w 256

ATI drivers 12.8

What cgminer settings can you suggest to give it an easier time and also what clock & memory settings should i have as well ?

(This may not be relevant....if i run it as part of a 3 cards 1 of the GPU's goes SICK and then eveything crashes after 1-2 mins)