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

[kano]

Also what I edited my post - but after you read it:

... API requires privileged access enabled.
Also miner.php has a enable/disable button if it has API privileged access ...
and set
$readonly = false;

[1715319135]

1715319135

[1715319135]

1715319135

[1715319135]

1715319135

[1715319135]

1715319135

[1715319135]

1715319135

[1715319135]

1715319135

[-ck]

I still have problems with 2.8.3.
Now i made a logfile : blogya.de/downloadsonlyforyou/logfile.txt
I crosscompile it for ARM7 maybe that is the problem.

is it normal, that in stratum protocol the nonce is different endian, than the nonce that is submitted by the worker ?

 [2012-10-12 12:49:27] Pushing submit work to work thread
 [2012-10-12 12:49:27] (3:5) submitted de65d291
 [2012-10-12 12:49:27] (3): entering poll loop
 [2012-10-12 12:49:27] (10): entering poll loop
 [2012-10-12 12:49:27] Popping work to work thread
 [2012-10-12 12:49:27] Creating extra submit work thread
 [2012-10-12 12:49:27] Submitting share 241c7c3e to pool 0
 [2012-10-12 12:49:27] SEND: {"params": ["MyUsername", "43402", "00000000", "5077f59c", "91d265de"], "id": 5, "method": "mining.submit"}

Later in the log you can see, that my driver is working together with 50BTC.com

Any Ideas ?

Are you saying your shares get refused? It is possible that it's an endian issue to do with ARM indeed.

These are the lines that convert the nonce value to a hex value to send to the server in cgminer.c:2849 if you wish to play...

Code:

		nonce = *((uint32_t *)(work->data + 76));
		noncehex = bin2hex((const unsigned char *)&nonce, 4);

[rav3n_pl]

Trying to compile on windows, it not see OpenCL...
Drivers installed, SDK etc installed, files copied...
Any ideas?

CFLAGS="-O2 -msse2" ./configure --enable-scrypt --enable-cpumining

Code:

------------------------------------------------------------------------
cgminer 2.8.3
------------------------------------------------------------------------


Configuration Options Summary:

  curses.TUI...........: FOUND: pdcurses
  OpenCL...............: NOT FOUND. GPU mining support DISABLED
  scrypt...............: Disabled (needs OpenCL)
  ADL..................: SDK NOT found, GPU monitoring support DISABLED

  BitForce.FPGAs.......: Disabled
  Icarus.FPGAs.........: Disabled
  ModMiner.FPGAs.......: Disabled
  Ztex.FPGAs...........: Disabled

  CPU Mining...........: Enabled
  ASM.(for CPU mining).: false

Compilation............: make (or gmake)
  CPPFLAGS.............:
  CFLAGS...............: -O2 -msse2
  LDFLAGS..............:
  LDADD................:  -LC:/MinGW/lib -lcurl -lcurldll   compat/jansson/libja
nsson.a -lpthread    -lws2_32 -lm

Installation...........: make install (as root if needed, with 'su' or 'sudo')
  prefix...............: /usr/local

[rcocchiararo]

I have 2 rigs with 2 gpus each (2 5830 and one with a 5830 and a 5850).

ONe has debian and the other ubuntu... both 32bits

is there any place to get precompiled binaries ? i compiled up to 2.3.something, and stoped

It was ... complicated xD

Might as well format the hell out of them and install ubuntu 12.04 x64, but that would take some time (and me getting to my parents home).

[louisBSAS]

I have three rigs - all Ubuntu 10.04LTS - ADL4.0 - SDK2.4 - and I followed the same instructions as everyone....

Why do these look different - (I don't get the nice layout on one of my rigs)

Any ideas - anyone?

[-ck]

I have three rigs - all Ubuntu 10.04LTS - ADL4.0 - SDK2.4 - and I followed the same instructions as everyone....

Why do these look different - (I don't get the nice layout on one of my rigs)

Any ideas - anyone?

It looks like you didn't have curses-development files installed when building cgminer on that rig.

[kano]

I have 2 rigs with 2 gpus each (2 5830 and one with a 5830 and a 5850).

ONe has debian and the other ubuntu... both 32bits

is there any place to get precompiled binaries ? i compiled up to 2.3.something, and stoped

It was ... complicated xD

Might as well format the hell out of them and install ubuntu 12.04 x64, but that would take some time (and me getting to my parents home).

Yes ... reinstall to x64

[louisBSAS]

I have three rigs - all Ubuntu 10.04LTS - ADL4.0 - SDK2.4 - and I followed the same instructions as everyone....

Why do these look different - (I don't get the nice layout on one of my rigs)

Any ideas - anyone?

It looks like you didn't have curses-development files installed when building cgminer on that rig.

That would be a quick fix - Will rebuild this evening - Thanks!
(Great piece of code BTW - expect a donation)

[PandaMiner]

im running this while not gaming "cgminer -o us2.eclipsemc.com:8337 -u xxxxxx -p xxxxx --shaders 1792 --intensity 12 --worksize 256 -v 1"

but how can i cut out gpu 0 when running bf3?

An alternate method that Kano didn't suggest is in the command line, use --device 1[,2,3,4,n] to turn "OFF" device 0, which is GPU 0.  If you are using batch files to start cgminer, use two files, one for gaming with "--device 1" and one for when not gaming.

[sharky112065]

New version: 2.8.3, 12th October 2012

Fixed a critical windows bug and added some goodies. Hopefully this version brings us close to making a stratum capable release the current stable version.

...

Thanx for the fast updates.
I replaced libpdcurses.dll that AVG virus warns about to other that AVG likes, and cgminer is still running fine =)

http://www.youtube.com/watch?v=BNsrK6P9QvI&noredirect=1

Or you could have just read the README which shows you that it is a false positive and setup AVG to ignore it. Or you could have read this forum thread and also come to the same conclusion.

[burger]

New version: 2.8.3, 12th October 2012

Fixed a critical windows bug and added some goodies. Hopefully this version brings us close to making a stratum capable release the current stable version.

...

Thanx for the fast updates.
I replaced libpdcurses.dll that AVG virus warns about to other that AVG likes, and cgminer is still running fine =)

http://www.youtube.com/watch?v=BNsrK6P9QvI&noredirect=1

Or you could have just read the README which shows you that it is a false positive and setup AVG to ignore it. Or you could have read this forum thread and also come to the same conclusion.

I have read the README and the forums... just that now I don't get that false positive at all =)

[Frizz23]

@ckolivas: Will cgminer support BFL ASICs? Are you already working on this?

[-ck]

@ckolivas: Will cgminer support BFL ASICs? Are you already working on this?

It will, along with ASICs from other manufacturers. I am not directly working on the driver for it yet because they have not released any specifications yet.

On the other hand, there have been numerous changes made to cgminer in preparation for those ASICs. This is precisely why cgminer now supports the stratum protocol, has massive rolltime support and can display devices up to exahash speed.

[louisBSAS]

I have three rigs - all Ubuntu 10.04LTS - ADL4.0 - SDK2.4 - and I followed the same instructions as everyone....

Why do these look different - (I don't get the nice layout on one of my rigs)

Any ideas - anyone?

It looks like you didn't have curses-development files installed when building cgminer on that rig.

That would be a quick fix - Will rebuild this evening - Thanks!
(Great piece of code BTW - expect a donation)

Like a charm - 2BTC sent!

[AxelMi]

I played a little around an found out, that the nonce does'nt have to change the endian on arm.

Is it normal that a Generated target looks like this:

Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d

on a working stratum machine, it look like this:

[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000

[-ck]

I played a little around an found out, that the nonce does'nt have to change the endian on arm.

Is it normal that a Generated target looks like this:

Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d

on a working stratum machine, it look like this:

[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000

No it is not normal. The last 8 hex characters should always be zero. The working stratum example is what a normal diff 1 target should look like.

[-ck]

Like a charm - 2BTC sent!

Thanks! Much appreciated 

[AxelMi]

I played a little around an found out, that the nonce does'nt have to change the endian on arm.

Is it normal that a Generated target looks like this:

Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d

on a working stratum machine, it look like this:

[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000

No it is not normal. The last 8 hex characters should always be zero. The working stratum example is what a normal diff 1 target should look like.

after the call  swab256(target, rtarget); the last bytes of target are destroyed.

But rtarget looks good. 

[-ck]

I played a little around an found out, that the nonce does'nt have to change the endian on arm.

Is it normal that a Generated target looks like this:

Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d

on a working stratum machine, it look like this:

[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000

No it is not normal. The last 8 hex characters should always be zero. The working stratum example is what a normal diff 1 target should look like.

after the call  swab256(target, rtarget); the last bytes of target are destroyed.

But rtarget looks good. 

Very weird. swab256 is a pretty simple function swapping the 8x4byte array members (which means 8 hex values) of rtarget to target and then byteswapping the values of each 4 byte value. It looks like something is stomping on the last few bytes on your arm build though. The endian issue could be coincidence and not the real problem.

[AxelMi]

I played a little around an found out, that the nonce does'nt have to change the endian on arm.

Is it normal that a Generated target looks like this:

Generated target 0000000000000000000000000000000000000000000000ffff00020d7800780d

on a working stratum machine, it look like this:

[2012-10-13 00:01:34] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000

No it is not normal. The last 8 hex characters should always be zero. The working stratum example is what a normal diff 1 target should look like.

after the call  swab256(target, rtarget); the last bytes of target are destroyed.

But rtarget looks good. 

Very weird. swab256 is a pretty simple function swapping the 8x4byte array members (which means 8 hex values) of rtarget to target and then byteswapping the values of each 4 byte value. It looks like something is stomping on the last few bytes on your arm build though. The endian issue could be coincidence and not the real problem.

I changed the default size of target and rtarget like this:

Code:

static void set_work_target(struct work *work, int diff)
{
        unsigned char rtarget[36], target[36];

Now i got targets like expected..
[2012-10-13 01:39:50] Generated target 0000000000000000000000000000000000000000000000000000ffff00000000

But still the same problem that i get rejected on stratum

 [2012-10-13 01:40:01] RECVD: {"error": [-2, "lowdifficulty", null], "id": 68, "result": false}
 [2012-10-13 01:40:01] PROOF OF WORK RESULT: false (booooo)
 [2012-10-13 01:40:01] Rejected 4e8ec61a Diff 3/1 MM 6 pool 0 (lowdifficulty)