when or how can we have support for nanofury usb erupter with cgminer? Is the only programme that can work without problems under linux but it didnt support nanofury usb and i cant use it because i have some of them
When I get one and write a driver for it. 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 152. (Read 5805527 times)
December 26, 2013, 07:23:25 PM
December 26, 2013, 07:00:00 PM
when or how can we have support for nanofury usb erupter with cgminer? Is the only programme that can work without problems under linux but it didnt support nanofury usb and i cant use it because i have some of them
December 26, 2013, 06:53:12 PM
Downloaded and am running 3.8.1 on Windows XP. I chose 3.8.1 because it's also the version on my rPi.
Anyway, I got the config file set and it seems to run ok and says waiting for devices. However, when I plug in onee of my ASIC 333Mh/s devices I get this.
[2013-12-26 17:31:03] USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 2:1
[2013-12-26 17:31:03] Icarus detect (2:1) failed to initialise (incorrect device?)
Anyone able to help me et this working on the laptop ? I ask because my rPi is gonna be MIA for a while so I need to get CGMiner goin on the laptop.
Ty.
http://ck.kolivas.org/apps/cgminer/zadig/zadig_xp_v2.0.1.161.exe Anyway, I got the config file set and it seems to run ok and says waiting for devices. However, when I plug in onee of my ASIC 333Mh/s devices I get this.
[2013-12-26 17:31:03] USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 2:1
[2013-12-26 17:31:03] Icarus detect (2:1) failed to initialise (incorrect device?)
Anyone able to help me et this working on the laptop ? I ask because my rPi is gonna be MIA for a while so I need to get CGMiner goin on the laptop.
Ty.
December 26, 2013, 06:38:00 PM
Downloaded and am running 3.8.1 on Windows XP. I chose 3.8.1 because it's also the version on my rPi.
Anyway, I got the config file set and it seems to run ok and says waiting for devices. However, when I plug in onee of my ASIC 333Mh/s devices I get this.
[2013-12-26 17:31:03] USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 2:1
[2013-12-26 17:31:03] Icarus detect (2:1) failed to initialise (incorrect device?)
Anyone able to help me et this working on the laptop ? I ask because my rPi is gonna be MIA for a while so I need to get CGMiner goin on the laptop.
Ty.
Anyway, I got the config file set and it seems to run ok and says waiting for devices. However, when I plug in onee of my ASIC 333Mh/s devices I get this.
[2013-12-26 17:31:03] USB init, open device failed, err -12, you need to install a WinUSB driver for - AMU device 2:1
[2013-12-26 17:31:03] Icarus detect (2:1) failed to initialise (incorrect device?)
Anyone able to help me et this working on the laptop ? I ask because my rPi is gonna be MIA for a while so I need to get CGMiner goin on the laptop.
Ty.
December 25, 2013, 11:13:20 AM
I know you don't mean it, but this is unintentionally flamebait. All my responses about GPUs/scrypt/litecoin do is piss people off more since they can't accept I have no interest in them and then they resort to personal attacks.
I actually thought about sending you a PM for a fork recommendation instead of posting the question because I know how people like to start internet wars. My heart was in the right place...I know you're sick of all the GPU questions coming in.
Right now I foresee two scenarios. A) Someone steps up and support gathers around a fork. B) Some rich Good Samaritan/fool lays out enough coin to drag you back in like The Godfather movies. lol
Chad
If you've got an Nvidia card, will be worth your while hitting up the Cudaminer program in the altcoins section, written by cbuchner1. It's forked from CPUMiner, but he's put some solid work into it for almost a year now and it's making the cards punch above their weight a fair bit with regards to Scrypt mining, but not quite as much as the AMD cards. It wouldn't be too much of a stretch for someone to develop an AMD-dedicated version to better take advantage of them compared to a catch-all program.
That said, would love to be able to merge the relevant code from Cudaminer into a fork of CGMiner to be able to monitor the cards and switch pools more easily, but I have a very, very basic understanding of C. Could do it, but it would take a fair bit of time (i.e. months) for me to learn and try to do it.
December 25, 2013, 07:36:40 AM
I know you don't mean it, but this is unintentionally flamebait. All my responses about GPUs/scrypt/litecoin do is piss people off more since they can't accept I have no interest in them and then they resort to personal attacks.
I actually thought about sending you a PM for a fork recommendation instead of posting the question because I know how people like to start internet wars. My heart was in the right place...I know you're sick of all the GPU questions coming in.
Right now I foresee two scenarios. A) Someone steps up and support gathers around a fork. B) Some rich Good Samaritan/fool lays out enough coin to drag you back in like The Godfather movies. lol
Chad
December 25, 2013, 07:12:22 AM
ckolivas...I'm just being curious/nosey here, but is there an amount of BTC you have in mind that would bring back GPU mining support in cgminer? heh..
I originally wrote the scrypt code for cgminer for 100BTC, which was my "I don't want to do it" price back then. I wish I had said 1000BTC instead. That should give you some idea.While I have your attention I also wanted to ask if there is a scrypt specific fork of cgminer that you might recommend to people that want continued GPU development. The GPU questions seem to be coming more and more often as of late. I've tried a couple of the forks, but I'd love to hear if there was a particular developer you worked with on the hand off that stuck out from the rest. I really expected someone to be leading the pack on scrypt mining by now, but nothing just jumps out at me. I was wondering if maybe I wasn't looking in the right places. I'm not really sure where I would direct people with GPU questions these days...or myself for that matter. heh..
I know you don't want to be bothered with GPU questions anymore. Putting a specific fork of the code in the limelight would probably steer a lot of the questions in that direction.
I pay no attention whatsoever to forks or gpu or scrypt code so I have no idea nor can recommend anything. I know you don't want to be bothered with GPU questions anymore. Putting a specific fork of the code in the limelight would probably steer a lot of the questions in that direction.
I know you don't mean it, but this is unintentionally flamebait. All my responses about GPUs/scrypt/litecoin do is piss people off more since they can't accept I have no interest in them and then they resort to personal attacks.
December 25, 2013, 06:54:17 AM
ckolivas...I'm just being curious/nosey here, but is there an amount of BTC you have in mind that would bring back GPU mining support in cgminer? heh..
While I have your attention I also wanted to ask if there is a scrypt specific fork of cgminer that you might recommend to people that want continued GPU development. The GPU questions seem to be coming more and more often as of late. I've tried a couple of the forks, but I'd love to hear if there was a particular developer you worked with on the hand off that stuck out from the rest. I really expected someone to be leading the pack on scrypt mining by now, but nothing just jumps out at me. I was wondering if maybe I wasn't looking in the right places. I'm not really sure where I would direct people with GPU questions these days...or myself for that matter. heh..
I know you don't want to be bothered with GPU questions anymore. Putting a specific fork of the code in the limelight would probably steer a lot of the questions in that direction.
Thanks!
Chad
While I have your attention I also wanted to ask if there is a scrypt specific fork of cgminer that you might recommend to people that want continued GPU development. The GPU questions seem to be coming more and more often as of late. I've tried a couple of the forks, but I'd love to hear if there was a particular developer you worked with on the hand off that stuck out from the rest. I really expected someone to be leading the pack on scrypt mining by now, but nothing just jumps out at me. I was wondering if maybe I wasn't looking in the right places. I'm not really sure where I would direct people with GPU questions these days...or myself for that matter. heh..
I know you don't want to be bothered with GPU questions anymore. Putting a specific fork of the code in the limelight would probably steer a lot of the questions in that direction.
Thanks!
Chad
December 25, 2013, 06:51:20 AM
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 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
but the driver does not crash. using 4GB ram causes that error with high TC, using 8GB ram and everything is fine (or lowering TC).
I am trying to find out if this is a bug in cgminer that somehow requires PC-RAM...
what exactly does that error mean?
I think it relates to the driver. Wish I could help you more.
M
December 25, 2013, 04:17:46 AM
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 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
but the driver does not crash. using 4GB ram causes that error with high TC, using 8GB ram and everything is fine (or lowering TC).
I am trying to find out if this is a bug in cgminer that somehow requires PC-RAM...
what exactly does that error mean?
December 25, 2013, 02:26:22 AM
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...
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...
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
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...
December 24, 2013, 06:59:09 PM
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 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
December 24, 2013, 06:42:04 PM
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?
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
December 24, 2013, 06:35:19 PM
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 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?
December 24, 2013, 05:24:41 AM
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.
December 24, 2013, 02:01:43 AM
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).
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).
December 23, 2013, 11:42:27 PM
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.
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.
December 23, 2013, 10:33:01 PM
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.
December 23, 2013, 10:31:31 PM
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.
December 23, 2013, 10:26:48 PM
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.
Jump to: