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

[kano]

Thanks for the Drillbit Support!!!
ASIC-README hasn't been updated though with the --drillbit-options stuff...

Ah well - I didn't spot they missed that
I'll update it in git shortly.

[1501240042]

1501240042

[1501240042]

1501240042

[1501240042]

1501240042

[1501240042]

1501240042

[1501240042]

1501240042

[1501240042]

1501240042

[Notanon]

Much appreciated! Can now have my Pi using both the Drillbit thumbs and the Block Erupter in the same instance of CGMiner without needing to run two separate versions for each. And it will put my mind at ease a bit when I plan to go on a roadtrip for a couple of weeks over east next month and won't be able to reboot it from there.

[kano]

Much appreciated! Can now have my Pi using both the Drillbit thumbs and the Block Erupter in the same instance of CGMiner without needing to run two separate versions for each. And it will put my mind at ease a bit when I plan to go on a roadtrip for a couple of weeks over east next month and won't be able to reboot it from there.

Yep my RPi with the thumb also has 2 AMUs - all 3 in a USB3 hub attached to the RPi with an Arctic USB fan on them ... though I've been stealing the mining fans for myself the last few days ... been hot down here ...

If you have any Drillbit boards (not thumbs) I've been told by the drillbit guys, and noticed (though it's probably already been said elsewhere) that if it has problems you simply leave it idle (on power) for a few minutes and then it's OK again.

Also make sure they have the latest firmware 20131217
http://drillbitsystem.com/forum/index.php?topic=235.0

[jedimstr]

Much appreciated! Can now have my Pi using both the Drillbit thumbs and the Block Erupter in the same instance of CGMiner without needing to run two separate versions for each. And it will put my mind at ease a bit when I plan to go on a roadtrip for a couple of weeks over east next month and won't be able to reboot it from there.

Yep my RPi with the thumb also has 2 AMUs - all 3 in a USB3 hub attached to the RPi with an Arctic USB fan on them ... though I've been stealing the mining fans for myself the last few days ... been hot down here ...

If you have any Drillbit boards (not thumbs) I've been told by the drillbit guys, and noticed (though it's probably already been said elsewhere) that if it has problems you simply leave it idle (on power) for a few minutes and then it's OK again.

Also make sure they have the latest firmware 20131217
http://drillbitsystem.com/forum/index.php?topic=235.0

How'd you get the USB3 hub working on the Pi? I thought they had "issues". Is it daisy chained through a usb2 hub? I have a bunch of unused AITech and Anker USB3 Hubs that could be put to good use with my Mining Pi's.

[kano]

Direct.

There is a reason why we have spent a lot of time (Con most of the time for a while now) on working on libusb issues ...

If you use other software that uses libusb directly and doesn't deal with it properly you can expect problems.

[jedimstr]

Direct.

There is a reason why we have spent a lot of time (Con most of the time for a while now) on working on libusb issues ...

If you use other software that uses libusb directly and doesn't deal with it properly you can expect problems.

. Wow nice!  I'll try it out later.  Thanks!!!

[Karin]

3.9.0 compiles and runs great on Mac.  My updated unofficial binaries for Mac OS X are here.

Happy holidays to all the cgminer devs

[aigeezer]

Running 3.9.0 on two machines for a few hours now. One (very) minor issue - Some AMU devices are not getting recognized for several minutes after startup. The simplest example I had is 7 Eruptors on a single hub, with five recognized instantly and the other two automatically hotplugged about three minutes later. The issue seems to be replicable on both my machines - I imagine it could be exciting for 49-port hub users.

[os2sam]

Running 3.9.0 on two machines for a few hours now. One (very) minor issue - Some AMU devices are not getting recognized for several minutes after startup. The simplest example I had is 7 Eruptors on a single hub, with five recognized instantly and the other two automatically hotplugged about three minutes later. The issue seems to be replicable on both my machines - I imagine it could be exciting for 49-port hub users.

Just out of curiosity do you have

"--hotplug 60"

I do and that is my normal behavior.

[aigeezer]

Running 3.9.0 on two machines for a few hours now. One (very) minor issue - Some AMU devices are not getting recognized for several minutes after startup. The simplest example I had is 7 Eruptors on a single hub, with five recognized instantly and the other two automatically hotplugged about three minutes later. The issue seems to be replicable on both my machines - I imagine it could be exciting for 49-port hub users.

Just out of curiosity do you have

"--hotplug 60"

I do and that is my normal behavior.

No - I have no special settings at all in this version - just the pool identifiers. The behavior is new to 3.9.0 for me, I think. There have often been some AMU delays in previous versions, but only for a few seconds. Often I would get a delay on the machine that has a BAL unit, just after it was detected, but the rest of the AMUs would usually show up within seconds. I think Con has been tweaking delay times to keep AMUs from going zombie, so perhaps it's a side-effect from that.

[-ck]

I haven't changed any of the hotplug or usb detect in 3.9.0 compared with 3.8.5. If it's slower it may simply be the extra devices (drillbit) it's now looking for.

[aigeezer]

I haven't changed any of the hotplug or usb detect in 3.9.0 compared with 3.8.5. If it's slower it may simply be the extra devices (drillbit) it's now looking for.

Is that consistent with, say, five out of seven AMUs being recognized quickly/immediately followed by a three minute delay for the remaining two (identical devices, all on the same hub)?

I don't want to make this sound like a big deal that needs a fix - more of a small anomaly that might or might not be important in some bigger context.

[-ck]

I haven't changed any of the hotplug or usb detect in 3.9.0 compared with 3.8.5. If it's slower it may simply be the extra devices (drillbit) it's now looking for.

Is that consistent with, say, five out of seven AMUs being recognized quickly/immediately followed by a three minute delay for the remaining two (identical devices, all on the same hub)?

I don't want to make this sound like a big deal that needs a fix - more of a small anomaly that might or might not be important in some bigger context.

Like I said, I didn't change anything so nfi why it's affecting you.

[aigeezer]

I haven't changed any of the hotplug or usb detect in 3.9.0 compared with 3.8.5. If it's slower it may simply be the extra devices (drillbit) it's now looking for.

Is that consistent with, say, five out of seven AMUs being recognized quickly/immediately followed by a three minute delay for the remaining two (identical devices, all on the same hub)?

I don't want to make this sound like a big deal that needs a fix - more of a small anomaly that might or might not be important in some bigger context.

Like I said, I didn't change anything so nfi why it's affecting you.

Wow - my most recent cgminer launch has been strange. Two of the AMUs have not shown up yet, 11 minutes in, but one has had its LED on for 5(?) minutes as though it wants to be flagged a zombie. Yikes - the other one just got recognized. I'd toss it off as random goofiness except that my other machine had the odd delays also, and its configuration/load is fairly mundane. Fifteen minutes in now, no zombie but the LED still on.

Edit: Removed a lot of detail about problems that now seem unrelated to cgminer 3.9.0. One issue remains that might be relevant, namely AMU LEDs can come on, the units become cool to the touch and are no longer hashing, but they are not flagged as zombies or dead. On replug, they are recognized as hotplugged and they resume hashing. It's like the original zombie problem, but much less frequent and without the error flagging.
  

[daddyfatsax]

I have been getting these errors on my DB thumbs.
http://i.imgur.com/0LAEQWF.png?1
http://i.imgur.com/KpZz9KB.png?1

Thumbs have been running on MinePeon with the DB version of cgminer. Only difference now is windows 7, hub is the same, ports on the hub, and OC (ext:240:1:950).

[Notanon]

Much appreciated! Can now have my Pi using both the Drillbit thumbs and the Block Erupter in the same instance of CGMiner without needing to run two separate versions for each. And it will put my mind at ease a bit when I plan to go on a roadtrip for a couple of weeks over east next month and won't be able to reboot it from there.

Yep my RPi with the thumb also has 2 AMUs - all 3 in a USB3 hub attached to the RPi with an Arctic USB fan on them ... though I've been stealing the mining fans for myself the last few days ... been hot down here ...

If you have any Drillbit boards (not thumbs) I've been told by the drillbit guys, and noticed (though it's probably already been said elsewhere) that if it has problems you simply leave it idle (on power) for a few minutes and then it's OK again.

Also make sure they have the latest firmware 20131217
http://drillbitsystem.com/forum/index.php?topic=235.0

Yeah, the firmware bit will be tricky from what I've read (particularly making sure the two pins are shorted when the thumbs are powered on), but should be able to do it without extra help. Been lucky to get away with not needing fans, but it hasn't been overly scorching in Perth yet, so will see how that plays out.

[carly200]

Hi,

I understand that scrypt/GPU mining support was removed from cgminer. Still I think this would be the best place/resource to help me in understanding the following.

using cgminer 3.7.2 some people experience the following error
" error -4: enqueueing kernel onto command queue "

what exactly does it mean?

Mining on R9 290 hardware
people have noticed, that higher TC values can cause this;
also using less than 8GB RAM can cause this.


Any insight what this error means exactly?

[rgr_rgr]

I am happy to see that cgminer supports Bitmains U1: https://github.com/AntMiner/AntGen1/tree/master/cgminer

But I can't find the sources. I need a version running on raspberry. How could I get it?

I'll wait until they release the sources for close inspection.

It is available: https://github.com/bitmaintech/cgminer

[mdude77]

Hi,

I understand that scrypt/GPU mining support was removed from cgminer. Still I think this would be the best place/resource to help me in understanding the following.

using cgminer 3.7.2 some people experience the following error
" error -4: enqueueing kernel onto command queue "

what exactly does it mean?

Mining on R9 290 hardware
people have noticed, that higher TC values can cause this;
also using less than 8GB RAM can cause this.

Any insight what this error means exactly?

I see this when the driver crashes.  I'm running 3.7.2 on a good number of 280x GPUs, two of which have 4 gb of memory on win7 x64.

Check the litecoin wiki page for recommended settings for your card.

M

[Sir William]

Here's a stupid question, but I've run out of ideas.  First of all, I'm using Windows 8.1 64 bit and cgminer v3.7.2.  I have a BitFury that I'm running on a separate instance.  This one is working flawlessly.  The trouble I'm running into is trying to run an instance of cgminer for just my on board video.  The video is on a Lenovo G505s notebook and is a AMD Radeon 8650G with 384 shaders.  My batch file reads as follows...

Code:

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
cgminer --shaders 384 -I 9 --thread-concurrency 1536 -o 127.0.0.1:9999 -u Name -p password

While this works, this still detect my BitFury, and pops up an error, because it cannot use it (not that I want it to).  How do I keep cgminer from detecting the BitFury in this instance?  This is a scrypt solo mine, so the BitFury would be useless for it.  Thank you...