OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 464.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Frizz23 on October 20, 2012, 07:43:33 AM

Quote from: AxelMi on October 20, 2012, 06:42:18 AM

Cgminer 2.8.4 crashes again on windows 7.

Same here.

2.8.3 and 2.8.4 crash after approx 2 days.

Have only tried Stratum (on BTCGuild) so far.

Host: OS: Win7x64, GPU: 1 x 6970.

@ckolivas: what information can I provide to help you fix this bug?

This is painful since the mode of failure on windows is really a mystery. The best thing you can do for now is run in debug mode to give me even more indication of where the problem lies. Run it with "--verbose -D -T -P" and see what the last messages are before it crashes.

Even better would be a custom debug build running in gdb but I doubt any of you are up for that Undecided

I'm trying that on my laptop which is the only thing that has windows. Hopefully I don't fry it in the process, but at 10MH/s I also doubt it will recreate the problem.

Sigh. I wish it were only linux...

Frizz23

hero member

Activity: 1162

Merit: 500

Quote from: AxelMi on October 20, 2012, 06:42:18 AM

Cgminer 2.8.4 crashes again on windows 7.

Same here.

2.8.3 and 2.8.4 crash after approx 2 days.

Have only tried Stratum (on BTCGuild) so far.

Host: OS: Win7x64, GPU: 1 x 6970.

@ckolivas: what information can I provide to help you fix this bug?

amigaman

sr. member

Activity: 406

Merit: 250

Quote from: AxelMi on October 20, 2012, 06:42:18 AM

Cgminer 2.8.4 crashes again on windows 7.
The funny thing is, that i am running some machines with 2.8.3 and some with 2.8.4.
All Machines are using Stratum.
the 2.8.4 machine crashes 80 Minutes later than the 2.8.3 Machines.

I have experienced similar, that's why my rigs have stratum proxy 1.1.1 running with 2.7.6, flawless for days without interruption, on a shaky DSL that disconnects ten times a day.
Also, higher hashrates than on 2.8.x.
I have that proxy as pool one, the pool the proxy points to as pool two and two other non-stratum pools as pool 3 and 4.
To my surprise, 98% of the work go to the proxy or the direct pool, 1% each to my reserve pools.
I have seen that after a DSL reconnect the proxy sometimes is a little picky, then after a few minutes all work resumes to it.

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: chewie on October 17, 2012, 06:04:00 AM

I've ran into "CGminer has suddenly stopped" crash error message on my rigs the past few days. I've had to restart CGminer over a dozen times so far. Please help. Thanks. Cgminer is currently running on a W7 64 bit OS system with 4x7970 and a BFL Single.

Post cgminer version, the error message (WER report) along with your configuration. I don't think anyone will be able to help you when you only say "cgminer has suddenly stopped".

AxelMi

newbie

Activity: 43

Merit: 0

Cgminer 2.8.4 crashes again on windows 7.
The funny thing is, that i am running some machines with 2.8.3 and some with 2.8.4.
All Machines are using Stratum.
the 2.8.4 machine crashes 80 Minutes later than the 2.8.3 Machines.

nitrox

member

Activity: 136

Merit: 10

tester

Quote from: -ck on October 19, 2012, 07:30:02 PM

Bug I guess. It's extraordinarily hard balancing things out when there are vastly different ways of getting the same amount of work and handing out depending on pool configuration.
If you strictly want a fixed proportion to each pool only the rotate strategy can guarantee that.

yes i use the rotate strategy.
just report what I saw for the record. Cool

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ice_chill on October 20, 2012, 01:20:59 AM

Quote from: -ck on October 20, 2012, 01:15:41 AM

Quote from: ice_chill on October 20, 2012, 12:39:52 AM

2.8.4 crashed under Windows 7 32Bit, would I have more luck running CGMiner from XP Mode within Windows 7 ?

I assume this is mining with stratum? Darn... the cause of this crash remains a mystery then. Perhaps someone with some windows debugging skills that can reproduce it (cause I can't reproduce it) can build a debug version and see.

As for XP mode helping? I doubt it, but it's worth a shot. Probably disabling stratum is the only way to guarantee it not crashing since it's a stratum error (give it regular server details and --fix-protocol)

It was stratum connection to BTC Guild. Would it help posting the crash error log ? or are they of limited use ?

Limited yes, useless no.

ice_chill

sr. member

Activity: 336

Merit: 250

Quote from: -ck on October 20, 2012, 01:15:41 AM

Quote from: ice_chill on October 20, 2012, 12:39:52 AM

2.8.4 crashed under Windows 7 32Bit, would I have more luck running CGMiner from XP Mode within Windows 7 ?

I assume this is mining with stratum? Darn... the cause of this crash remains a mystery then. Perhaps someone with some windows debugging skills that can reproduce it (cause I can't reproduce it) can build a debug version and see.

As for XP mode helping? I doubt it, but it's worth a shot. Probably disabling stratum is the only way to guarantee it not crashing since it's a stratum error (give it regular server details and --fix-protocol)

It was stratum connection to BTC Guild. Would it help posting the crash error log ? or are they of limited use ?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ice_chill on October 20, 2012, 12:39:52 AM

2.8.4 crashed under Windows 7 32Bit, would I have more luck running CGMiner from XP Mode within Windows 7 ?

I assume this is mining with stratum? Darn... the cause of this crash remains a mystery then. Perhaps someone with some windows debugging skills that can reproduce it (cause I can't reproduce it) can build a debug version and see.

As for XP mode helping? I doubt it, but it's worth a shot. Probably disabling stratum is the only way to guarantee it not crashing since it's a stratum error (give it regular server details and --fix-protocol)

ice_chill

sr. member

Activity: 336

Merit: 250

2.8.4 crashed under Windows 7 32Bit, would I have more luck running CGMiner from XP Mode within Windows 7 ?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: TheHarbinger on October 19, 2012, 11:14:22 AM

Quote from: TheHarbinger on October 17, 2012, 10:50:10 PM

Con, I'll give the new build a whirl tomorrow since I was one of the ones that was having issues with dynamic difficulty. 2.7.6 is what I've been running, and has been rock solid for me, although it seems a few others still had problems. The only thing I did notice is that if I loose my network, the queued value (Q:) shoots through the roof and then drives the efficiency (E:) down through the floor. But it doesn't actually effect anything since those are just displayed values, and I know the queued work isn't actually increasing like a rocket ship because it can't get the work if the network is down. Roll Eyes

Okay, not seeing any issues with dynamic difficulty with 2.8.4, so hopefully that issue is dead and truly buried. I'm still seeing the weird behavior with queued work after a network loss, though this is clearly a very minor issue as it does not truly affect anything except displayed stats.

Great thanks

I wouldn't worry about the Q value... hopefully the old getwork queue thing will be a thing of the past as pools move to better protocols like stratum.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: nitrox on October 19, 2012, 04:46:23 PM

something strange whit MULTIPOOL and LOAD BALANCE and BALANCE.

a try to mining on 3 pools whit LOAD BALANCE or BALANCE strategy and the result is the same
first : http://pool.50btc.com
second : http://pool2.50btc.com
third : http://pool.coinlab.com

result for LOAD BALANCE after several hours
first pool : 227 shares
second pool : 168 shares
third pool : 1412 shares

result for BALANCE after several hours
first pool : 213 shares
second pool : 191 shares
third pool : 1624 shares

it is a bug something ?
or i don't get right the value of BALANCE and LOAD BALANCE strategy.
why is there such a big difference between shares count ?

Bug I guess. It's extraordinarily hard balancing things out when there are vastly different ways of getting the same amount of work and handing out depending on pool configuration.
If you strictly want a fixed proportion to each pool only the rotate strategy can guarantee that.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: sharky112065 on October 19, 2012, 04:11:03 PM

C. Kolivas

I am having trouble compiling cgminer 2.8.4 on MinGW 32 (Windows 7 x64). The last version I compiled was 2.7.5 and that version had no problems.

Compiling from "cgminer-2.8.4.tar.bz2" on your site.

Configure complains about not having any GPU/CL support.

If I remark out the following lines in configure.ac

#if test "x$ATISTREAMSDKROOT" != x; then
#   OPENCL_FLAGS="-I$ATISTREAMSDKROOT/include $OPENCL_FLAGS"
#   OPENCL_LIBS="-L$ATISTREAMSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
#fi

#if test "x$AMDAPPSDKROOT" != x; then
#   OPENCL_FLAGS="-I$AMDAPPSDKROOT/include $OPENCL_FLAGS"
#   OPENCL_LIBS="-L$AMDAPPSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
#fi

and then type:
autoreconf -fvi
  and then
CFLAGS="-O2 -msse2" ./configure
  and then
make

And now, cgminer 2.8.4 compiles just fine with AMD GPU support.

$ATISTREAMSDKROOT = Empty; Does not exist on MinGW 32
$AMDAPPSDKROOT = C:\Program Files (x86)\AMD APP\ and is a valid directory.
$ARCH_DIR = Empty; Does not exist on MinGW 32

There is a $PROCESSOR_ARCHITECTURE environment variable and it is set to "x86" but using this variable could be problematic as the two AMD directories are "x86" and "x86_64" and the possible settings for the variable are "x86", "AMD64", and "IA64".

I'm sure windows users that compile on MinGW will have problems with this and it should probably be fixed.

Yes you're not the only one to report this. Curious. I guess I can just ignore those defines on anything but linux.

nitrox

member

Activity: 136

Merit: 10

tester

something strange whit MULTIPOOL and LOAD BALANCE and BALANCE.

a try to mining on 3 pools whit LOAD BALANCE or BALANCE strategy and the result is the same
first : http://pool.50btc.com
second : http://pool2.50btc.com
third : http://pool.coinlab.com

result for LOAD BALANCE after several hours
first pool : 227 shares
second pool : 168 shares
third pool : 1412 shares

result for BALANCE after several hours
first pool : 213 shares
second pool : 191 shares
third pool : 1624 shares

it is a bug something ?
or i don't get right the value of BALANCE and LOAD BALANCE strategy.
why is there such a big difference between shares count ?

sharky112065

sr. member

Activity: 383

Merit: 250

C. Kolivas

I am having trouble compiling cgminer 2.8.4 on MinGW 32 (Windows 7 x64). The last version I compiled was 2.7.5 and that version had no problems.

Compiling from "cgminer-2.8.4.tar.bz2" on your site.

Configure complains about not having any GPU/CL support.

If I remark out the following lines in configure.ac

#if test "x$ATISTREAMSDKROOT" != x; then
#   OPENCL_FLAGS="-I$ATISTREAMSDKROOT/include $OPENCL_FLAGS"
#   OPENCL_LIBS="-L$ATISTREAMSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
#fi

#if test "x$AMDAPPSDKROOT" != x; then
#   OPENCL_FLAGS="-I$AMDAPPSDKROOT/include $OPENCL_FLAGS"
#   OPENCL_LIBS="-L$AMDAPPSDKROOT/lib/$ARCH_DIR $OPENCL_LIBS"
#fi

and then type:
autoreconf -fvi
  and then
CFLAGS="-O2 -msse2" ./configure
  and then
make

And now, cgminer 2.8.4 compiles just fine with AMD GPU support.

$ATISTREAMSDKROOT = Empty; Does not exist on MinGW 32
$AMDAPPSDKROOT = C:\Program Files (x86)\AMD APP\ and is a valid directory.
$ARCH_DIR = Empty; Does not exist on MinGW 32

There is a $PROCESSOR_ARCHITECTURE environment variable and it is set to "x86" but using this variable could be problematic as the two AMD directories are "x86" and "x86_64" and the possible settings for the variable are "x86", "AMD64", and "IA64".

I'm sure windows users that compile on MinGW will have problems with this and it should probably be fixed.

TheHarbinger

sr. member

Activity: 378

Merit: 250

Why is it so damn hot in here?

Quote from: TheHarbinger on October 17, 2012, 10:50:10 PM

Con, I'll give the new build a whirl tomorrow since I was one of the ones that was having issues with dynamic difficulty. 2.7.6 is what I've been running, and has been rock solid for me, although it seems a few others still had problems. The only thing I did notice is that if I loose my network, the queued value (Q:) shoots through the roof and then drives the efficiency (E:) down through the floor. But it doesn't actually effect anything since those are just displayed values, and I know the queued work isn't actually increasing like a rocket ship because it can't get the work if the network is down. Roll Eyes

Okay, not seeing any issues with dynamic difficulty with 2.8.4, so hopefully that issue is dead and truly buried. I'm still seeing the weird behavior with queued work after a network loss, though this is clearly a very minor issue as it does not truly affect anything except displayed stats.

rav3n_pl

legendary

Activity: 1361

Merit: 1003

Don`t panic! Organize!

Quote from: -ck on October 19, 2012, 06:46:51 AM

I'm upgrading the status of cgminer 2.8.4 to stable status and removing 2.7.7 from the top directory. Even if some stratum bug does show up in the future, disabling stratum with --fix-protocol will still make it more stable than 2.7.7 is, and it's time to move on.

Good, but Q: is still counting in some odd way

Code:

 cgminer version 2.8.4 - Started: [2012-10-19 09:35:35]
-----------------------------------------------------------------------
 (5s):5.353M (avg):14.46Mh/s | Q:12  A:63  R:0  HW:0  E:525%  U:0.2/m
 TQ: 0  ST: 1  SS: 0  DW: 11  NB: 1  LW: 3816  GF: 0  RF: 0  WU: 0.2
 Connected to http://rav3n.dtdns.net:9332 with LP as user toy.gpu
 Block: 0000005defaf82b794f28a67e56e7482...  Started: [09:35:35]
-----------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  66.0C  56%    | 14.57M/14.47Mh/s | A:63 R:0 HW:0 U:0.20/m I: 3
-----------------------------------------------------------------------

 [2012-10-19 14:54:24] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:28] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:29] Accepted 89346c22 Diff 1/1 GPU 0
 [2012-10-19 14:54:29] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:33] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:34] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:41] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:50] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:51] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:54:56] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:55:24] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:55:33] LONGPOLL from pool 0 requested work restart
 [2012-10-19 14:55:43] LONGPOLL from pool 0 requested work restart

It is running about 6 hrs on p2pool so Q should be over 360/hour.
Where was more than 12 blocks too...

EDIT:
Some time later O_o

Code:

 cgminer version 2.8.4 - Started: [2012-10-19 09:35:35]
--------------------------------------------------------------------------------
 (5s):14.57M (avg):13.18Mh/s | Q:66382  A:81  R:5  HW:0  E:0%  U:0.2/m
 TQ: 0  ST: 1  SS: 0  DW: 34  NB: 1  LW: 4852  GF: 18  RF: 0  WU: 0.2
 Connected to http://rav3n.dtdns.net:9332 with LP as user toy.gpu
 Block: 0000005defaf82b794f28a67e56e7482...  Started: [09:35:35]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  65.5C  54%    | 14.56M/13.18Mh/s | A:81 R:5 HW:0 U:0.17/m I: 3
--------------------------------------------------------------------------------

 [2012-10-19 17:40:57] LONGPOLL from pool 0 requested work restart

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

I'm upgrading the status of cgminer 2.8.4 to stable status and removing 2.7.7 from the top directory. Even if some stratum bug does show up in the future, disabling stratum with --fix-protocol will still make it more stable than 2.7.7 is, and it's time to move on.

dlasher

sr. member

Activity: 467

Merit: 250

Quote from: -ck on October 18, 2012, 04:28:32 PM

Quote from: dlasher on October 18, 2012, 04:05:28 PM

Interesting failure state today.

2 minutes. It's there already.

Hmmm... I wonder what went wrong then.. I'll have to go back and look at logs again, see if I can dig anything up. In the mean time, I updated all the 2.8.3's to 2.8.4, hope there's magic in the upgrade.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: dlasher on October 18, 2012, 04:05:28 PM

Interesting failure state today.

I have some (2.8.3) miners behind stratum 1.1.1 proxy.. primary pool stratum was pointed at failed. (stratum crashed). cgminer stayed connected to proxy, which stayed up. proxy couldn't get work from primary pool, stayed idle, all miners went idle, cgminer never failed down to next pools in the chain.

It would be nice to be able to set some sort of threshold.. (And shoot me conman if you already do this and I just missed it)..in cgminer. If I don't get any work from a pool in {threshold} minutes, in spite of being TCP/UDP/etc up, I should mark it dead. (I swear cgminer already does this for getwork.. I see messages about "pool not providing work fast enough")

(FWIW, I'm going to post something over in Slush's proxy thread, because I think his proxy should have marked itself dead, but somehow cgminer should know a pool is "starving", shouldn't it?)

2 minutes. It's there already.

EDIT: The problem is the proxy may have been lying and continuing to send what looked like fresh work to cgminer. It's time to stop using the proxy Wink

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 464. (Read 5805537 times)