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

[kano]

Sorry if this has been mentioned before.  I just wanted to let you know that ever since I got my little single late last week cgminer has stopped 3 times.  I just come back and the window for it isn't up anymore.  After the second time it happened I wrote a little batch file to check if the process is running and start it if it isn't and scheduled it to run every 5 minutes.  So it's not a big deal.  I just never saw that happen back with the GPUs.  My guess is that the little single is disconnecting or erroring or something and cgminer is seeing no device and closing.  But that is just a wild guess on my part.  Any thoughts?  I'm running the latest cgminer, with p2pool on windows 8 x64 (I know, I should probably switch to Linux, maybe eventually).

By the way, I just sent a small donation to Kano and ckolivas for all of your hard work.  You guys rock!

Donation received - thanks indeed
Since I am often making changes, testing stuff, I always run cgminer in a loop that simply restarts if it fails.
The windows version of this is

Code:

@echo off
REM cgminer
:Loop
Set NOW=%date:~10,4%%date:~7,2%%date:~4,2%.%time:~0,2%%time:~3,2%%time:~6,2%
.\cgminer.exe --no-restart --api-port 4028 --api-listen --api-allow W:127.0.0.1,W:192.168.1.0/24 --api-description Des -c pools.json 2> "run.%NOW%.log"
echo Sleeping for 5 seconds
ping -n 5 127.0.0.1 > NUL
GOTO Loop

The 5s sleep is good in case you change the options and it keeps hard looping due to a mistake

[1714045247]

1714045247

[1714045247]

1714045247

[kano]

I've been away for a while and decided to give 3.3 another shot since kano et al are singing its praises everywhere.

3.3.4 using libusb-1.0.16-rc10 compiled from sourceforge still shuts down half of my 4x AM USB eruptors when running on Debian amd64 with USB disconnects. If there's some sort of logs you would like let me to post, let me know what you would like to see, but compiling a newer libusb absolutely *does not* solve the problem.

Back to 3.1.1 where everything works fine.

I seem to be having a similar problem on Win7x64 with WinUSB (via Zadig).  I have 10 BEs, and every couple of hours, at least one will stop working with an error like this:

Code:

AMU0: Comms error (werr=-7 amt=0)

I tried using different hubs and tried using no more than 4 BEs in each 7-port HUB, in case it was a power issue, but nothing helps.

I have not tried using 3.1.1 yet, but I guess that is my next step.  This is very frustrating.

[Edit: I should add that if CGMiner is restarted, it will not pick up the BE that apparently failed.  It will seem to be OK, in that Windows says it is OK, and working, but the LED will stay on steady, and I have to manually unplug and replug it to get it to be seen by CGMINER.]

If anyone cares, I switched these Block Erupters over to my Linux box using BFGMiner, and now they are 100% rock solid.  I don't know if the problem is CGMiner or WinUSB, but my stuff works now.

So which is it?
Wrong version? Wrong libusb.dll? You built it yourself and didn't follow the libusb instructions?
... and cgminer will be rock solid on linux also if you do it as per instructions.

[Jriker1]

I have a bunch of cards using cgminer with.  Recently updated to 3.3.4 of CG.  Deleted the bin files and started up.  All worked ok except for one card on one computer.  I have one machine that has a 7950 and a 6950 in it.  Both running in harmony.  I updated my AMD drivers from 13.4 beta to 13.7 beta, current on at the time.  I can startup cg with the 7950 and a new bin file is compiled, but no version all the way back to 2.x will work with the 6950.  First I thought it was the cg version, until I tested a bunch and none worked.  The program starts, and hangs when it's creating a new bin file, and then just closes.  Using -T doesn't return anything.  If I go back to 3.3.1 which I was using originally, and restore the bin file from the trash, CG starts and runs without issue.  Thoughts?  Could 13.4 to 13.7 cause this many problems?  Or am I missing something?

Thanks.

JR

[xyzzy099]

I've been away for a while and decided to give 3.3 another shot since kano et al are singing its praises everywhere.

3.3.4 using libusb-1.0.16-rc10 compiled from sourceforge still shuts down half of my 4x AM USB eruptors when running on Debian amd64 with USB disconnects. If there's some sort of logs you would like let me to post, let me know what you would like to see, but compiling a newer libusb absolutely *does not* solve the problem.

Back to 3.1.1 where everything works fine.

I seem to be having a similar problem on Win7x64 with WinUSB (via Zadig).  I have 10 BEs, and every couple of hours, at least one will stop working with an error like this:

Code:

AMU0: Comms error (werr=-7 amt=0)

I tried using different hubs and tried using no more than 4 BEs in each 7-port HUB, in case it was a power issue, but nothing helps.

I have not tried using 3.1.1 yet, but I guess that is my next step.  This is very frustrating.

[Edit: I should add that if CGMiner is restarted, it will not pick up the BE that apparently failed.  It will seem to be OK, in that Windows says it is OK, and working, but the LED will stay on steady, and I have to manually unplug and replug it to get it to be seen by CGMINER.]

If anyone cares, I switched these Block Erupters over to my Linux box using BFGMiner, and now they are 100% rock solid.  I don't know if the problem is CGMiner or WinUSB, but my stuff works now.

So which is it?
Wrong version? Wrong libusb.dll? You built it yourself and didn't follow the libusb instructions?
... and cgminer will be rock solid on linux also if you do it as per instructions.

I was using the released binaries on Windows7 x64 and I was continuously getting the failures described above.

I tried BFGMiner first on Linux (which I did build myself), and it worked flawlessly - so I never tried building CGMiner.  My problem is fixed.

I am just posting this in case others have the same problems I did with the Windows binary release of CGMiner, and so that you guys are aware that there may be an issue.

[Askit2]

I'm having an issue with the newest CGMiner. I am sure it's my fault. At least 13 hours ago I was sure it was my fault. I am still sure I am messing up something.

I am running a raspberry pi, Raspbian, and have replaced my no longer reliable enough SD card with a new one.

13 hours ago the SD card became corrupted for the second time in a week. I didn't think much of it. I have been using it for months and likely it isn't well.

I re-imaged the card with raspbian, followed the instructions here https://bitcointalk.org/index.php?topic=138921.msg1509722#msg1509722

I downloaded CGMiner 3.3.4 into a folder. Configure with ./autogen.sh. make clean, make. While still using the old card as I wasn't nearly awake enough to go buy another and had no spares.

Once made I tried running and I am seeing 100% load with 9 BFL jalapeno's. 60% is cgminer, 40% is ksoftirqd/0. I assume ksoftirqd/0 is the K software irq daemon. When I have built before the same 9 units run more like 10% load. 

I know Raspberry pi's don't last long at 100% so I stopped cgminer and back to low load.

After some sleep I grabbed the HW compatibility list for Raspberry Pi to see what I could snag locally. I grabbed 2 cards so I could image my setup once working. flashed one card setup raspbian and ran the commands to get the required software to make cgminer. looked through the readme and asic readme finding another step that likely wasn't required months ago. Added the get for udev dev.

I  made the libusb for 1.0.16-rc10. After running the libusb_cflag line I couldn't get the usual command I used from that other topic to actually configure cgminer. Error was missing libusb install libusb1.0. I did (likely a mistake) apt-get install libusb-1.0.0-dev. After this I could run

Code:

CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc

successfully.

I am truly lost on how to put

Code:

CFLAGS="-g -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-bflsc

together with

Code:

LIBUSB_CFLAGS="-I./libusb/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="./libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev" ./configure --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon

I assume the "-g -W -Wall" ./autogen.sh would have to be added to the second one. I am not sure as I don't remember that working before. Since I can't put the two cflags together I know I had been running this without the newer libusb before the SD card issues. Since all devices are BFL sc and not apparently affected by the usb1.1 device on usb 3.0 hubs I should be ok with the other libusb I think.

Any help is greatly appreciated.

[kano]

Yeah the configure still checks for libusb at the system level - but installing to resolve that doesn't (negatively) affect the command below

As for the command to combine them it is:
LIBUSB_CFLAGS="-I./libusb/libusb-1.0.16-rc10/libusb" LIBUSB_LIBS="./libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev" CFLAGS="-g -W -Wall" ./configure --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-ztex --enable-avalon

[candoo]

Hey

i tried to write the following code in the cgminer.conf file. but he doesnt accept it

"avalon-cutoff"    : "90"
"avalon-temp"    : "90"
"avalon-opions"    : "115200:32:10:35:360"

may anyone please be so kindly and correct it? avalon-temp is fine, because my fans are spinning at 100% all the time. It never goes above 70

[-ck]

Hey

i tried to write the following code in the cgminer.conf file. but he doesnt accept it

"avalon-cutoff"    : "90"
"avalon-temp"    : "90"
"avalon-opions"    : "115200:32:10:35:360"

may anyone please be so kindly and correct it? avalon-temp is fine, because my fans are spinning at 100% all the time. It never goes above 70

opions...

[candoo]

Hey

i tried to write the following code in the cgminer.conf file. but he doesnt accept it

"avalon-cutoff"    : "90"
"avalon-temp"    : "90"
"avalon-opions"    : "115200:32:10:35:360"

may anyone please be so kindly and correct it? avalon-temp is fine, because my fans are spinning at 100% all the time. It never goes above 70

opions...

goddamn it!!

Is there any method to start a specific Avalon? I might want to connect a couple of Avalons to my windows pc. I like cgminer in combination with cgwatch. CGwatch restarts cgminer when there are 0 new accept shares after XX minutes. How can i specific which com port he should use?

Thanks in advance for your patience

[-ck]

You should really set your temp to lower than your cutoff as well. It might not like them being the same, and I certainly wouldn't want 90 degrees as my target, I'd recommend 70.

[candoo]

You should really set your temp to lower than your cutoff as well. It might not like them being the same, and I certainly wouldn't want 90 degrees as my target, I'd recommend 70.

Thanks. I have custom fans with 5400 RPM with fixed 12volt. (connected via molex) They cant overheat, but I will look into it

Is there any method to start a specific Avalon? I might want to connect a couple of Avalons to my windows pc. I like cgminer in combination with cgwatch. CGwatch restarts cgminer when there are 0 new accept shares after XX minutes. How can i specific which com port he should use?

Thanks in advance for your patience

[pawlak2]

Since I am often making changes, testing stuff, I always run cgminer in a loop that simply restarts if it fails.
The windows version of this is

Code:

@echo off
REM cgminer
:Loop
Set NOW=%date:~10,4%%date:~7,2%%date:~4,2%.%time:~0,2%%time:~3,2%%time:~6,2%
.\cgminer.exe --no-restart --api-port 4028 --api-listen --api-allow W:127.0.0.1,W:192.168.1.0/24 --api-description Des -c pools.json 2> "run.%NOW%.log"
echo Sleeping for 5 seconds
ping -n 5 127.0.0.1 > NUL
GOTO Loop

The 5s sleep is good in case you change the options and it keeps hard looping due to a mistake

If someone is interested, here is my linux version:

Code:

#!/bin/bash
for (( ; ; ))
do
cgminer --config cg_$1_$2.conf 2>log$2.log
echo sleeping.....
sleep 5
echo done sleeping
done

I'm using few instances of cgminer for different devices and with parameters I can start different configs.

For example:
./gocg btc e
Runs config file cg_btc_e.conf logfile loge.log for my erupters.

[xyzzy099]

You should really set your temp to lower than your cutoff as well. It might not like them being the same, and I certainly wouldn't want 90 degrees as my target, I'd recommend 70.

Thanks. I have custom fans with 5400 RPM with fixed 12volt. (connected via molex) They cant overheat, but I will look into it

Is there any method to start a specific Avalon? I might want to connect a couple of Avalons to my windows pc. I like cgminer in combination with cgwatch. CGwatch restarts cgminer when there are 0 new accept shares after XX minutes. How can i specific which com port he should use?

Thanks in advance for your patience

What if a fan fails?

[candoo]

You should really set your temp to lower than your cutoff as well. It might not like them being the same, and I certainly wouldn't want 90 degrees as my target, I'd recommend 70.

Thanks. I have custom fans with 5400 RPM with fixed 12volt. (connected via molex) They cant overheat, but I will look into it

Is there any method to start a specific Avalon? I might want to connect a couple of Avalons to my windows pc. I like cgminer in combination with cgwatch. CGwatch restarts cgminer when there are 0 new accept shares after XX minutes. How can i specific which com port he should use?

Thanks in advance for your patience

What if a fan fails?

You hear a dying fans weeks before he's dead. Even though 90°C cutoff is the setting in the stock avalon firmware from the new batch 3.

[Xian01]

 Reporting in from the field, my 3.3.4 setup under Windows has experienced a few General Protection Faults over the past couple days driving ~50 AMU's per instance, where the cgminer.exe crashes and I need to kill the cmd.exe session to relaunch a new instance.

 Happens on both USB 2.0 and 3.0 systems.

[kano]

Since I am often making changes, testing stuff, I always run cgminer in a loop that simply restarts if it fails.
The windows version of this is

Code:

@echo off
REM cgminer
:Loop
Set NOW=%date:~10,4%%date:~7,2%%date:~4,2%.%time:~0,2%%time:~3,2%%time:~6,2%
.\cgminer.exe --no-restart --api-port 4028 --api-listen --api-allow W:127.0.0.1,W:192.168.1.0/24 --api-description Des -c pools.json 2> "run.%NOW%.log"
echo Sleeping for 5 seconds
ping -n 5 127.0.0.1 > NUL
GOTO Loop

The 5s sleep is good in case you change the options and it keeps hard looping due to a mistake

If someone is interested, here is my linux version:

Code:

#!/bin/bash
for (( ; ; ))
do
cgminer --config cg_$1_$2.conf 2>log$2.log
echo sleeping.....
sleep 5
echo done sleeping
done

I'm using few instances of cgminer for different devices and with parameters I can start different configs.

For example:
./gocg btc e
Runs config file cg_btc_e.conf logfile loge.log for my erupters.

Oh on linux - here's a better way
(how I do it - though I do it in 2 scripts one that calls the other - this is essentially what it is)

Code:

#!/bin/bash
#
nam="$HOME/cgminer-run.log"
while true ; do
 echo "`date`: Starting cgminer" 2>&1 | tee -a "$nam"
 ulimit -c 2097152
 now="`date +%Y%m%d%H%M%S`"
 ./cgminer --api-listen "$@" 2> "$HOME/run.$now.$$.log"
 s="$?"
 echo "`date`: cgminer exited status ($s)" 2>&1 | tee -a "$nam"
 echo "`date`: Sleeping for 5..." 2>&1 | tee -a "$nam"
 sleep 5
done

Add all your default options at line 8
Any other options you want you can add when you run it
So e.g. if you call it cgminer.sh
You can run it as:
./cgminer.sh -c pools.conf

In your $HOME directory you'll have cgminer-run.log that will list all the starts and stops
And run.YYYYMMDDHHMMSS.$$.log for each run

[kano]

...
I was using the released binaries on Windows7 x64 and I was continuously getting the failures described above.

I tried CrapMiner first on Linux (which I did build myself), and it worked flawlessly - so I never tried building CGMiner.  My problem is fixed.

I am just posting this in case others have the same problems I did with the Windows binary release of CGMiner, and so that you guys are aware that there may be an issue.

The problem there is that is failed logic (as a certain other developer enjoys ...)

Firstly, make sure you have the right libusb.dll - that is the actual cause of the problems.
If you use your old libusb.dll it of course will not work.

If, however, it still doesn't work, then it wont work with the clone either.
The problem will be either bad cables or a USB3 that causes it to fail.

On linux, it will work fine, but you simply are advertising using some other clone software coz you couldn't be bothered running cgminer.

i.e. go away.

[xyzzy099]

...
I was using the released binaries on Windows7 x64 and I was continuously getting the failures described above.

I tried CrapMiner first on Linux (which I did build myself), and it worked flawlessly - so I never tried building CGMiner.  My problem is fixed.

I am just posting this in case others have the same problems I did with the Windows binary release of CGMiner, and so that you guys are aware that there may be an issue.

The problem there is that is failed logic (as a certain other developer enjoys ...)

Firstly, make sure you have the right libusb.dll - that is the actual cause of the problems.
If you use your old libusb.dll it of course will not work.

If, however, it still doesn't work, then it wont work with the clone either.
The problem will be either bad cables or a USB3 that causes it to fail.

On linux, it will work fine, but you simply are advertising using some other clone software coz you couldn't be bothered running cgminer.

i.e. go away.

It's not clear to me what I did to get you into such a defensive stance.  Whatever it was, I apologize.

I thought I was just reporting an issue you might want to know about.

Again, I was using whatever binaries that were in your official Windows distribution, from the link at the beginning of this topic, and the zadig binary that is linked there also.

[bitpop]

Go away

[-ck]

Now now, no need to get narky. Most people aren't aware of the bitter history there and why Kano gets so pissed off at the mention of brickminer. It seemed an innocent enough report to me, he just didn't know that mere mention of the hostile fork makes it hard to see through the seething rage that it brings on.