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

[kano]

im trying to get 2>name.file logging working from a startup script that starts a cgminer instance inside a detached GNU screen window.


screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log



this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?

At a guess, the log is the output of 'screen' not 'cgminer' ?

[Taugeran]

im trying to get 2>name.file logging working from a startup script that starts a cgminer instance inside a detached GNU screen window.


screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log



this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?

At a guess, the log is the output of 'screen' not 'cgminer' ?

is there a hidden option to log to  a file or will i have to delve deep into the innards of linux to figure out how to redirect the output of cgminers display within that screen session to  file

[Askit2]

im trying to get 2>name.file logging working from a startup script that starts a cgminer instance inside a detached GNU screen window.


screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log



this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?

At a guess, the log is the output of 'screen' not 'cgminer' ?

is there a hidden option to log to  a file or will i have to delve deep into the innards of linux to figure out how to redirect the output of cgminers display within that screen session to  file

use other .sh file to call cgminer. with your ./cgminer and everything. call the .sh file from your current command. can even put the cgminer in a loop to make sure it restarts if it died.

Thank You for showing me how to finish my boot script. I Was trying to run the commands in order like I do from the console to start screen, then change directory, then start the cgminer script. Now I have it working. Cron will fire it up, my loop will keep it up. I can attach using putty.

[Askit2]

The IO error on the devices only seems to happen on Linux not my windows box. When I moved those units to the raspberry pi it started having issues.
I can't say for sure there isn't a problem with a cable but I can hook it back up to windows 7 tomorrow maybe and try that.

I built the version from the git. I don't so far dare to stop cron from killing it every half hour. I can't watch it constantly and so far my script to start them up at boot isn't working correctly.

I do have a side issue that isn't cgminer directly. I have been plagued by crashes for a while. I haven't in the past seen anything to make me think mining specifically caused it. The most recent crash left me with the following error. I am including the last line of cgminers output and the crash report. Crash was 3.5.1 not newest from git. crashed after 57 minutes of running. 3 more and it would have restarted at the hour.


After that is some unwind kdb info I can type that up if you would like. It seems like there is a kernel error. I got lucky as for a change the monitor was still getting a signal. Usually power management manages to keep the signal off making the crashes far less useful. I don't know that this will help anything.

There's no doubt the USB in the RPi is less reliable than a real PC. Part of the problem is that the network device is actually a USB device low down meaning USB comms are compromised as a result, and it's all on the same bus.

Code:

Bus 001 Device 004: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. LAN9500 Ethernet 10/100 Adapter / SMSC9512/9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Unfortunately I can't really start digging into kernel code, but I can at least suggest trying a different distro (though I believe I've said that before). I can reliably crash my RPi by just plugging something into the USB slot that draws more power than usual (such as the BF1 stick) without mining even running. Would be interesting to see now that you've built from git whether you get complete failures with transfer errors or just IO errors as a temporary glitch now.

Due to me fat fingering an edit on cron I think if my math is correct it never restarted cgminer with the newest built from git and made it overnight.
That having been said I am not sure that */220 wouldn't ever run the restart script. I intended to put the new version from */30 to */20 for minutes making it restart 3 times an hour. Since that had stopped the hanging before.

I have moved things around and I still do get errors of the IO type. While moving things I noticed no errors with only 4 jalapeno's. As I was adding the next 4 I didn't see IO errors until the third from that set was added. After having all 9 back on I have only noticed a couple of IO errors. Maybe I should spread the proverbial love to a couple of more raspberry pi's.

Upgrading in the past hasn't helped me at all. I get more crashes and more corrupted sd cards. I tried very shortly arch but my Linux command line is lack luster at best so I went back to raspbian. I even tried MinePeon but the image I downloaded was corrupted. I really do hope the newest version won't require as frequent of a restart.

[-ck]

Due to me fat fingering an edit on cron I think if my math is correct it never restarted cgminer with the newest built from git and made it overnight.
That having been said I am not sure that */220 wouldn't ever run the restart script. I intended to put the new version from */30 to */20 for minutes making it restart 3 times an hour. Since that had stopped the hanging before.

I have moved things around and I still do get errors of the IO type. While moving things I noticed no errors with only 4 jalapeno's. As I was adding the next 4 I didn't see IO errors until the third from that set was added. After having all 9 back on I have only noticed a couple of IO errors. Maybe I should spread the proverbial love to a couple of more raspberry pi's.

Upgrading in the past hasn't helped me at all. I get more crashes and more corrupted sd cards. I tried very shortly arch but my Linux command line is lack luster at best so I went back to raspbian. I even tried MinePeon but the image I downloaded was corrupted. I really do hope the newest version won't require as frequent of a restart.

Well that definitely sounds better than it was. The only other thing I've seen suggested is using a good powered USB supply to the RPi. Perhaps a shorter, thicker cable from a USB3 slot if running off a PC, or a well powered hub if not.

[kano]

im trying to get 2>name.file logging working from a startup script that starts a cgminer instance inside a detached GNU screen window.


screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log



this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?

At a guess, the log is the output of 'screen' not 'cgminer' ?

is there a hidden option to log to  a file or will i have to delve deep into the innards of linux to figure out how to redirect the output of cgminers display within that screen session to  file

As suggested above used a script to run cgminer (and log it) and have screen only run that script and do nothing else.
I think I've posted this or similar in here a few times now ...

Code:

while true ; do
 echo "`date`: Starting cgminer"
 ulimit -c 2097152
 #
 now="`date +%Y%m%d%H%M%S`"
 #
 ./cgminer --api-listen --api-allow W:127.0.0.1,R:0/0 --api-description MyMiner --api-mcast --api-mcast-des MyMiner --no-restart "$@" 2> ~/run.$now.$$.log
 s="$?"
 echo "`date`: cgminer exited status ($s)"
 echo "`date`: Sleeping for 5..."
 sleep 5
done

This will create a log file in your home directory for each time cgminer runs with the date stamp it started and the process number in case you run 2 at the same time.

[Askit2]

snip

Well that definitely sounds better than it was. The only other thing I've seen suggested is using a good powered USB supply to the RPi. Perhaps a shorter, thicker cable from a USB3 slot if running off a PC, or a well powered hub if not.

My Usb cable was the shortest I could find It looks like 12" it was a monster brand one. Supply is rated at 1.5A and all devices attached to raspberry pi have hubs (they are usb3...) and are powered off a 12V supply (they have an internal switch mode circuit) and will deliver 1.5A per port and only 4 ports so no internal hub on hub action. It shouldn't be a lack of power. Then again I can't be sure it isn't somehow related to power.

It could be USB 3 related but I have used these hubs since I started getting asics.  My only asics are BFL and don't seem to draw power from the USB. I am expecting this will be like it used to be stable 24/7 for months at a time.

Thank You for all that you do.

[juhakall]

If you don't specify stratum+tcp:// cgminer will try a few different ways to connect first. Some pools might not like the multiple attempts to connect so it is always cleaner and faster to specify the stratum+tcp:// prefix.

Thanks for mentioning this! I'd been having a problem connecting to ghash.io, it would always take ~5 minutes after a miner restart. Specifying the stratum+tcp:// removed this delay.

[kano]

snip

Well that definitely sounds better than it was. The only other thing I've seen suggested is using a good powered USB supply to the RPi. Perhaps a shorter, thicker cable from a USB3 slot if running off a PC, or a well powered hub if not.

My Usb cable was the shortest I could find It looks like 12" it was a monster brand one. Supply is rated at 1.5A and all devices attached to raspberry pi have hubs (they are usb3...) and are powered off a 12V supply (they have an internal switch mode circuit) and will deliver 1.5A per port and only 4 ports so no internal hub on hub action. It shouldn't be a lack of power. Then again I can't be sure it isn't somehow related to power.

It could be USB 3 related but I have used these hubs since I started getting asics.  My only asics are BFL and don't seem to draw power from the USB. I am expecting this will be like it used to be stable 24/7 for months at a time.

Thank You for all that you do.

The other thing to consider is Arch rather than Raspbian.
The Arch USB network driver seems to be more reliable than the Raspbian one.
As mentioned before, the network device on the RPi is actually USB.

The basics of RPi Arch setup:
http://www.kano-kun.net/?p=87

[greek_hephaestus]

Helo CKolivas and Kano,
Do you have any plans to release a KnCMiner version of CGMiner?
Thank you very much for your contribution to Cryptocoin Mining!!!

[-ck]

Helo CKolivas and Kano,
Do you have any plans to release a KnCMiner version of CGMiner?
Thank you very much for your contribution to Cryptocoin Mining!!!

KFC sent me a saturn unit for development. I am currently swamped with other work but will eventually get around to working on integrating support for it into master cgminer and hopefully improve on the driver too.

[wolfskill]

Still getting the error below with 3.6.4:

 [2013-10-21 20:25:38] BAL0: empty result (INPROCESS:10x0aCOUN0x00) ignored
 [2013-10-21 20:25:39] BAL0: Error: Get temp returned nothing (0:0)
 [2013-10-21 20:25:40] BAL0: GetResults failed no data returned  (err=0 amt=0)
 [2013-10-21 20:25:41] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:25:41] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:25:42] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:25:42] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:25:44] BAL0: GetResults failed (err=-7 amt=0)
 [2013-10-21 20:26:06] BAL0: GetResults failed (err=-7 amt=16)
 [2013-10-21 20:26:07] BAL0: GetResults failed no data returned  (err=0 amt=0)
 [2013-10-21 20:26:08] BAL0: GetResults failed (err=-7 amt=0)
 [2013-10-21 20:26:09] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:26:09] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:26:10] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:26:10] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:26:11] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:26:11] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:26:13] BAL0: GetResults failed no data returned  (err=0 amt=0)

Using USB 2.0 ports directly on the motherboard, restarting CGMINER seems to fix the issue.  Tried different USB ports, same issue.  Can happen 20 minuter or hours after CGMINER.

WolfSkill

[-ck]

Still getting the error below with 3.6.4:

 [2013-10-21 20:26:13] BAL0: GetResults failed no data returned  (err=0 amt=0)

Using USB 2.0 ports directly on the motherboard, restarting CGMINER seems to fix the issue.  Tried different USB ports, same issue.  Can happen 20 minuter or hours after CGMINER.

It's possible you're having a hardware issue that only shows up after it's been under load for a while. I had this sort of failure with a bad power brick on a single.

[wolfskill]

Ok, thank you for the information.

WolfSkill

[ewibit]

Still getting the error below with 3.6.4:
Using USB 2.0 ports directly on the motherboard, restarting CGMINER seems to fix the issue.  Tried different USB ports, same issue.  Can happen 20 minuter or hours after CGMINER.

here the same

Code:

[2013-10-22 11:43:43] AMU11: Comms error (werr=-7 amt=0)
 [2013-10-22 11:43:43] AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 11:43:43] AMU 8 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 11:43:43] AMU8: Comms error (werr=-7 amt=0)
 [2013-10-22 11:43:43] AMU 11 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 11:43:43] AMU11: Comms error (werr=-7 amt=0)
 [2013-10-22 11:43:43] AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 11:43:44] AMU 8 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 11:43:44] AMU8: Comms error (werr=-7 amt=0)
 [2013-10-22 11:43:44] AMU 11 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 11:43:44] AMU11: Comms error (werr=-7 amt=0)
 [2013-10-22 11:43:44] AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 11:43:44] AMU 8 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 11:43:44] AMU8: Comms error (werr=-7 amt=0)
 [2013-10-22 11:43:44] AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT

[greek_hephaestus]

Helo CKolivas and Kano,
Do you have any plans to release a KnCMiner version of CGMiner?
Thank you very much for your contribution to Cryptocoin Mining!!!

KFC sent me a saturn unit for development. I am currently swamped with other work but will eventually get around to working on integrating support for it into master cgminer and hopefully improve on the driver too.

Thank you Very much for your answer!!!

[c1010010]

Do you always plan to edit the subject line with the new version #?
Makes it easy to see if there was a change, or if there was just a comment on the thread.

[-ck]

...it is always edited with the current version.

[c1010010]

...it is always edited with the current version.

Thanks.  Apparently my window is truncating it... I see that you are completely right.

Thanks.

[mdude77]

More 3.6.4 feedback:

I moved all my USB erupters to another machine.  I found cgminer doesn't see any of those plugged into my blue USB 3.0 ports.  This is the same experience I had with my laptop.  They work fine on the non blue ports.  I'm also getting problems with devices zombifying, and the AMU write errors.  I did not see any of these errors on the old PC, so it seems once again this is hardware specific.  Last time it was AMU 7 that zombified.

Code:

 cgminer version 3.6.4 - Started: [2013-10-22 14:59:20]
-------------------------------------------------------------------------------
 (5s):11.27G (avg):10.52Gh/s | A:436  R:2  HW:14  WU:162.2/m
 ST: 2  SS: 1  NB: 2  LW: 791  GF: 0  RF: 0
 Connected to llllll diff 8 with stratum as user kkkkk
 Block: 0000075bdc49ed00...  Diff:268M  Started: [15:00:47]  Best share: 4.07K
-------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 AMU  0:                 | 335.4M/326.9Mh/s | A:17 R:0 HW:2 WU: 11.3/m
 AMU  1:                 | 335.7M/337.2Mh/s | A:40 R:0 HW:0 WU:  7.0/m
 AMU  2:                 | 335.7M/332.3Mh/s | A: 8 R:2 HW:0 WU:  4.8/m
 AMU  3:                 | 335.4M/325.6Mh/s | A:16 R:0 HW:0 WU:  2.9/m
 AMU  4:                 | 335.6M/332.1Mh/s | A: 8 R:0 HW:1 WU:  4.8/m
 AMU  5:                 | 335.4M/315.4Mh/s | A:24 R:0 HW:0 WU:  6.6/m
 AMU  6:                 | 335.5M/324.8Mh/s | A:16 R:0 HW:0 WU:  3.7/m
 AMU  7:                 | 335.7M/333.9Mh/s | A:12 R:0 HW:1 WU:  5.9/m
 AMU  8:                 | 335.6M/336.4Mh/s | A: 8 R:0 HW:0 WU:  4.8/m
 AMU  9:                 | 335.6M/334.5Mh/s | A: 8 R:0 HW:0 WU:  3.7/m
 AMU 11:                 | 335.6M/336.7Mh/s | A:17 R:0 HW:1 WU:  6.6/m
 AMU 12:                 | 335.6M/331.3Mh/s | A: 8 R:0 HW:1 WU:  2.2/m
 AMU 13:                 | 335.2M/325.4Mh/s | A: 0 R:0 HW:0 WU:  3.7/m
 AMU 14:                 | 335.8M/324.8Mh/s | A: 0 R:0 HW:1 WU:  4.0/m
 AMU 15:                 | 335.4M/332.2Mh/s | A:32 R:0 HW:0 WU:  5.5/m
 AMU 16:                 | 335.7M/332.6Mh/s | A:24 R:0 HW:0 WU:  4.4/m
 AMU 17:                 | 335.2M/313.6Mh/s | A:16 R:0 HW:0 WU:  6.2/m
 AMU 18:                 | 335.5M/315.4Mh/s | A: 1 R:0 HW:0 WU:  4.0/m
 AMU 19:                 | 335.7M/320.8Mh/s | A: 0 R:0 HW:1 WU:  3.3/m
 AMU 20:                 | 335.6M/334.4Mh/s | A: 0 R:0 HW:0 WU:  7.0/m
 AMU 21:                 | 335.5M/325.1Mh/s | A: 8 R:0 HW:0 WU:  4.4/m
 AMU 22:                 | 335.6M/335.8Mh/s | A:32 R:0 HW:0 WU:  3.3/m
 AMU 23:                 | 335.4M/329.7Mh/s | A:16 R:0 HW:1 WU:  5.9/m
 AMU 24:                 | 335.6M/315.4Mh/s | A: 1 R:0 HW:0 WU:  5.1/m
 AMU 25:                 | 335.7M/324.9Mh/s | A:48 R:0 HW:1 WU:  6.6/m
 AMU 26:                 | 335.7M/331.0Mh/s | A:32 R:0 HW:1 WU:  5.5/m
 AMU 27:                 | 335.6M/320.1Mh/s | A: 9 R:0 HW:0 WU:  2.2/m
 AMU 28:                 | 335.7M/329.1Mh/s | A: 1 R:0 HW:0 WU:  4.4/m
 AMU 29:                 | 335.5M/333.1Mh/s | A: 0 R:0 HW:1 WU:  5.9/m
 AMU 30:                 | 335.5M/324.5Mh/s | A:24 R:0 HW:0 WU:  6.6/m
 AMU 31:                 | 335.4M/330.4Mh/s | A: 8 R:0 HW:0 WU:  5.1/m
 AMU 32:                 | 335.8M/324.1Mh/s | A: 0 R:0 HW:2 WU:  4.4/m
 AMU 10:                 | ZOMBIE/93.54Mh/s | A: 2 R:0 HW:0 WU:  1.8/m
-------------------------------------------------------------------------------

 [2013-10-22 15:01:51] AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 15:01:52] AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 15:01:58] Accepted 1a733b3e Diff 9/8 AMU 21 pool 0
 [2013-10-22 15:02:01] AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 15:02:02] AMU 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-22 15:02:02] Accepted 08989b2a Diff 29/8 AMU 15 pool 0

M