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

[-ck]

My bad, it wasn't Roy's fault at all, it was mine. Quick update to 3.6.6 shortly.

EDIT: Updated to 3.6.6, uploaded, git pushed etc.

[1714212625]

1714212625

[1714212625]

1714212625

[1714212625]

1714212625

[kano]

Been a while

3.6.6a 3.6.6 recompiled on:
Fedora 18
64 bit xubuntu 11.04 (should also work on Fedora 16 and 17)
RPi 32bit Arch
RPi 32bit Raspbian

e.g. to get the 64 bit xubuntu 11.04 binary:
wget https://github.com/kanoi/cgminer-binaries/raw/master/Ubuntu_11.04_x86_64/cgminer-3.6.6a
chmod +x cgminer-3.6.6a

The 3 others are:
https://github.com/kanoi/cgminer-binaries/raw/master/Fedora18_x86_64/cgminer-3.6.6a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Arch/cgminer-3.6.6a
https://github.com/kanoi/cgminer-binaries/raw/master/RPi_Raspbian/cgminer-3.6.6a

The Xubuntu configure option (with GPU and scrypt):
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-avalon --enable-opencl --enable-scrypt --enable-bitfury --enable-klondike

The rest are USB only (no GPU):
CFLAGS="-g -W -Wall" ./autogen.sh --enable-bflsc --enable-icarus --enable-bitforce --enable-modminer --enable-avalon --enable-bitfury --enable-klondike

The -g (instead of -O2) means it's a debug build so if anyone finds a problem and has core dumps enabled, it will dump a much more useful debug core.

Note I have binary folders of ckolivas official release files in my binaries git also, for if you can't get to his downloads
To get them you select the folder (e.g. 3.6.6) then click on the file you want then right-click save-as the "View Raw" link.

Important: Read README, ASIC-README or FPGA-README about USB configuration on linux and windows

[kano]

3.1.1 doesn't talk usb but serial to those devices, so absolutely none of the rules apply comparing that version with the current cgminer. A zombie implies the usb effectively got disconnected at some stage. I'm just trying to find the mode of failure, looking for the last usb error that cgminer reports before it zombifies it.

OK, I get it now - my 3.1.1 test won't help you at all. As a user though, my temporary fix for zombies is to go back to a stable 3.1.1 when I need to, for example if I'm leaving a machine unattended for a long time.

What do you make of the "no zombies while logging" phenomenon? It could of course be just coincidence but it's still going on. I guess it won't prove anything if I turn logging off and quickly get a zombie as it might have happened anyway. I'll watch and wait some more. I wish I could be more helpful.

Just an aside ... 3.1.1 can't have a zombie AMU coz AMUs were not usbutils in 3.1.1, they were serial - and it's only usbutils that can flag a device as zombie

[aigeezer]

3.1.1 doesn't talk usb but serial to those devices, so absolutely none of the rules apply comparing that version with the current cgminer. A zombie implies the usb effectively got disconnected at some stage. I'm just trying to find the mode of failure, looking for the last usb error that cgminer reports before it zombifies it.

OK, I get it now - my 3.1.1 test won't help you at all. As a user though, my temporary fix for zombies is to go back to a stable 3.1.1 when I need to, for example if I'm leaving a machine unattended for a long time.

What do you make of the "no zombies while logging" phenomenon? It could of course be just coincidence but it's still going on. I guess it won't prove anything if I turn logging off and quickly get a zombie as it might have happened anyway. I'll watch and wait some more. I wish I could be more helpful.

Just an aside ... 3.1.1 can't have a zombie AMU coz AMUs were not usbutils in 3.1.1, they were serial - and it's only usbutils that can flag a device as zombie

I've been over-using the word zombie in my posts. It became a shorthand for "non-working Erupter". Usually it was literally flagged as a zombie by cgminer (versions after 3.1.1) but sometimes it was not mining for other reasons. The effect was always LED on solid and mining stopped. The cure varied. Sometime restarting cgminer worked, sometimes hot replug of the Erupter worked, sometimes hot replug of the hub's USB connection worked, very occasionally a whole hub needed to be powered down and restarted, and once in a rare while it took a system reboot to make things right.

I'll mention again though that 3.6.4 ran (still running) for 15+ hours with logging turned on. With logging off it has never lasted that long without a literal zombie or some other solid-light Erupter failure. It sounds like 3.6.6 has the right kinds of changes for my problems.

Magic.   

[techman05]

New release: Version 3.6.6 - 26th October 2013

A new stable release building on top of 3.6.4 that should be a safe upgrade path after the earlier unstable 3.6 releases. Please pay attention for the options have changed.

CKolivias, could next update have an error pop up if it doesn't find a file its looking for like the config file. When it doesn't find the file it just flashes and closes without any error. Maybe say "missing startup item "cgminer.conf" and a generic press any key to exit message?

Using windows 7 (though I'd think somthing like this would be same in linux versions).

Thanks, I've just been going up in versions so fast I'm forgetting to move my config file.

[aigeezer]

3.6.6 reports two zombies (literally) after about 20 minutes. I'll restart it shortly with logging on.

[techman05]

So far so good for me. Mines been running for about 40 minutes with load balancing.

[-ck]

3.6.6 reports two zombies (literally) after about 20 minutes. I'll restart it shortly with logging on.

3.6.6 is almost identical to the experimental .exe you last downloaded.

[aigeezer]

3.6.6 reports two zombies (literally) after about 20 minutes. I'll restart it shortly with logging on.

3.6.6 is almost identical to the experimental .exe you last downloaded.

OK, thanks for the info. Behavior seems about the same. Working fine with logging, only running with log for about half an hour so far though.

[-ck]

3.6.6 reports two zombies (literally) after about 20 minutes. I'll restart it shortly with logging on.

3.6.6 is almost identical to the experimental .exe you last downloaded.

OK, thanks for the info. Behavior seems about the same. Working fine with logging, only running with log for about half an hour so far though.

It's still bizarre that it would not go zombie with logging on only. Either way it will be nice to know what error specifically causes cgminer to consider the device dead. All we can do is keep watching and maybe capture something on the log.

[os2sam]

New release: Version 3.6.6 - 26th October 2013

A new stable release building on top of 3.6.4 that should be a safe upgrade path after the earlier unstable 3.6 releases. Please pay attention for the options have changed.

CKolivias, could next update have an error pop up if it doesn't find a file its looking for like the config file. When it doesn't find the file it just flashes and closes without any error. Maybe say "missing startup item "cgminer.conf" and a generic press any key to exit message?

Using windows 7 (though I'd think somthing like this would be same in linux versions).

Thanks, I've just been going up in versions so fast I'm forgetting to move my config file.

In the mean time a work around is to put a "pause" in your .bat file.

[Roy Badami]

No command line options, everything is inside the ~/.cgminer/cgminer.conf

Oh, thanks, Pontius - I'd not even known that one can set arbitrary options in the conf file.  That's just made my life complete

roy

[jmc1517]

Following this thread with interest.

I have been running 3.3.1 for - ooh ages - without problems.  I'm using a Windows 7 64bit core i7 cpu with 34 Erupters plugged in to 3 Anker 10-port hubs and a powered 4-port hub.  The hubs are all plugged into motherboard usb slots.

No real problems with 3.3.1 apart from the odd zombie maybe every 10-14 days.

Upgraded to 3.6.4 and loads of timeouts and zombies almost instantly.  Powered off hubs, restarted. Same problem, so went back to 3.3.1 - sweet as a nut!

Today I have tried 3.6.6 and it ran for about 15 minutes, then one zombie appeared and timeouts stated to come up.  Then another zombie and more timeouts.  Seems to get worse after the first timeout appears, then it's pretty much regular timeout after timeout. So I've reverted to 3.3.1, powered the hubs off/on and everything is working smoothly again.

Just for the info...


* Today I  have tried 3.6.6

[Krak]

I've been noticing a lot of these duplicate shares lately (3.5.0 and 3.6.6).

Code:

[2013-10-26 13:59:00] Accepted 2aa206aa Diff 6/4 BAJ 0 pool 0
[2013-10-26 13:59:00] Rejected 2aa206aa Diff 6/4 BAJ 0 pool 0

Is there something wrong with my Jalapeno or is this just normal crappy BFL behavior? It's been throwing out about 1% hardware errors too.

[-ck]

Following this thread with interest.

I have been running 3.3.1 for - ooh ages - without problems.  I'm using a Windows 7 64bit core i7 cpu with 34 Erupters plugged in to 3 Anker 10-port hubs and a powered 4-port hub.  The hubs are all plugged into motherboard usb slots.

No real problems with 3.3.1 apart from the odd zombie maybe every 10-14 days.

Upgraded to 3.6.4 and loads of timeouts and zombies almost instantly.  Powered off hubs, restarted. Same problem, so went back to 3.3.1 - sweet as a nut!

Today I have tried 3.6.6 and it ran for about 15 minutes, then one zombie appeared and timeouts stated to come up.  Then another zombie and more timeouts.  Seems to get worse after the first timeout appears, then it's pretty much regular timeout after timeout. So I've reverted to 3.3.1, powered the hubs off/on and everything is working smoothly again.

Do you see a message just before one of them goes zombie about any usb errors in particular?

[-ck]

I've been noticing a lot of these duplicate shares lately (3.5.0 and 3.6.6).

Code:

[2013-10-26 13:59:00] Accepted 2aa206aa Diff 6/4 BAJ 0 pool 0
[2013-10-26 13:59:00] Rejected 2aa206aa Diff 6/4 BAJ 0 pool 0

Is there something wrong with my Jalapeno or is this just normal crappy BFL behavior? It's been throwing out about 1% hardware errors too.

Probably hardware related, but probably also nothing to worry about as it's just how a form of hw errors manifest on that particular device.

[vayvanne]

Code:

AMU 0 SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
Accepted 00779ffc Diff 547/16 BAJ 0 pool 0
AMU 0 SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
AMU 0 SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
AMU 0 SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
AMU 0 SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
Accepted 0eb891f7 Diff 17/16 BAJ 0 pool 0
AMU 0 SendWork usb write err:(-7) LIBUSB_ERROR_TIMEOUT
Accepted 0e692c25 Diff 17/16 BAJ 0 pool 0

I got this with 3.6.4 temp binaries after tens hours of hashing. Regular binaries was producing this more quickly.
Driver version is 6.1.7600.16385.
Now testing 3.6.6. No issues yet during last hour.

[-ck]

Found another little buglet. Uploading another cgminer-nogpu.exe into the temp directory. Windows users with AMU issues please try it.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe

[-ck]

Found another little buglet. Uploading another cgminer-nogpu.exe into the temp directory. Windows users with AMU issues please try it.

http://ck.kolivas.org/apps/cgminer/temp/cgminer-nogpu.exe

I know you're all tested out, but this one's a big fix for AMUs...

[rav3n_pl]

Stared on 2x USB erupters + 1x BFL 30GH/s
What should I expect? ;]