Last time it crashed on 2 different XP rigs at the same time so I think it could be related to some network events processing.
Sorry, no logs
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 470. (Read 5806015 times)
October 13, 2012, 08:18:21 AM
2.8.3 on Win7 x64 and XP x32 crashes eventually.
Last time it crashed on 2 different XP rigs at the same time so I think it could be related to some network events processing.
Sorry, no logs
Last time it crashed on 2 different XP rigs at the same time so I think it could be related to some network events processing.
Sorry, no logs
October 13, 2012, 08:16:24 AM
@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.
Did Josh/BFL already contact you?
From https://forums.butterflylabs.com/showthread.php/125-Can-you-send-a-%28beta%29-ASIC-device-to-ckolivas-%28developer-cgminer%29?p=1667&viewfull=1#post1667
Q: Would it be possible that you send one of your (beta) ASIC devices to ckolivas (the developer of cgminer) so that he can start supporting it?
A: Yes, as soon as we have something available, we will be sending him one.
October 13, 2012, 01:24:53 AM
However 
If you see something with 3M and it isn't a BLOCK! - then it is time to weep
(coz it has to actually be above 3054627.5... at the moment)
If you see something with 3M and it isn't a BLOCK! - then it is time to weep
(coz it has to actually be above 3054627.5... at the moment)
October 13, 2012, 12:41:14 AM
I'm loving the new difficulty stats. It's cool getting to see what each share is.
Yes it makes it far more interesting just watching hashes go by... though of course it's a complete time waster. But if you see anything 3M or bigger, that would be exciting cause it would be a block solve 
October 12, 2012, 10:23:15 PM
Dynamic intensity is still messed up in 2.8.3. Now it's going up to 15. 
Eh? I tested it on windows and linux... 
October 12, 2012, 10:16:49 PM
Dynamic intensity is still messed up in 2.8.3. Now it's going up to 15.
Eh? I tested it on windows and linux... October 12, 2012, 10:07:36 PM
Dynamic intensity is still messed up in 2.8.3. Now it's going up to 15.
I'm loving the new difficulty stats. It's cool getting to see what each share is.
I'm loving the new difficulty stats. It's cool getting to see what each share is.
October 12, 2012, 08:42:58 PM
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.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
after the call swab256(target, rtarget); the last bytes of target are destroyed.
But rtarget looks good.
Code:
static void set_work_target(struct work *work, int diff)
{
unsigned char rtarget[36], target[36];
[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)
October 12, 2012, 06:44:34 PM
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.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
after the call swab256(target, rtarget); the last bytes of target are destroyed.
But rtarget looks good.
Code:
static void set_work_target(struct work *work, int diff)
{
unsigned char rtarget[36], target[36];
[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)
October 12, 2012, 06:19:17 PM
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.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
after the call swab256(target, rtarget); the last bytes of target are destroyed.
But rtarget looks good.
October 12, 2012, 06:09:01 PM
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.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
after the call swab256(target, rtarget); the last bytes of target are destroyed.
But rtarget looks good.
October 12, 2012, 05:51:04 PM
Like a charm - 2BTC sent!
Thanks! Much appreciated 
October 12, 2012, 05:50:06 PM
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. 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
October 12, 2012, 05:35:42 PM
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
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
October 12, 2012, 05:27:21 PM
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.Why do these look different - (I don't get the nice layout on one of my rigs)
Any ideas - anyone?
That would be a quick fix - Will rebuild this evening - Thanks!
(Great piece of code BTW - expect a donation)
Like a charm - 2BTC sent!
October 12, 2012, 05:13:38 PM
@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.
October 12, 2012, 03:43:57 PM
@ckolivas: Will cgminer support BFL ASICs? Are you already working on this?
October 12, 2012, 01:47:37 PM
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.
...
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 =)
October 12, 2012, 11:20:45 AM
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.
...
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.
October 12, 2012, 10:55:10 AM
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?
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.
Jump to: