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

How do you do that? I tried something a while back but didn't get it working.

What I want to do is run under gdb, save the environment when it crashes, then continue running so that it's not sitting all day locked up.

"Scrypt will now not fail when setting high thread concurrency values that still return some ram even if opencl returns an error on that ram allocation."

what exactly is considered "high"? I still cant get 2.8.4 to run on a 7950 with anything over 8192 (look-up gap2) unless i raise the look-up gap to 3 and go to 12224 (which i could do pre-2.8.4). Which allows intensity of 20 without HW errors. 3 vs 2 makes you lose some performance at the same concurrencies, but high intensities MORE than makes up for it. ( 3 @ 12224 @ 19 = ~400kh/s vs 2 @ 8192 @ 13 ~330kh/s)

Also... would you know why starting Cgminer @ 12 and raising to 13 gives HW errors, and using the -I 13 flag in my shortcut doesnt?

Thanks for your time.

Even better would be a custom debug build running in gdb but I doubt any of you are up for that   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...

dunno about getting sick, but my 6950 now able to run with I=12, whereas in 2.7.x and all previous versions anything above 9 was causing cgminer to use 100% of CPU. So, now I'm able to squeeze 400Mhs from 6950 with AMD APP 2.4 and catalyst 12.8 drivers, running at 965Mhz  and almost 440Mhs from 6970.

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?

Cgminer 2.8.4 crashes again on windows 7.

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'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.

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.

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

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)

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

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.

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 ?

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.