Notanon
Sr. Member
  
Offline
Activity: 390
Merit: 250
Pastor of Muppets
|
 |
December 23, 2013, 11:17:34 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.
|
AMHash
| ASICMINER ● ROCKMINER ● Purchase from: AMHash (20Th/s min) ● Havelock (1Gh/s min) Cloud-mining contracts: 0.0012 BTC per Gh ● Maintenance fee: $0.001551 per Gh per day ● Upto 6% Christmas Bonus
|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
|
kano
Legendary
Offline
Activity: 2436
Merit: 1039
Linux since 1997 RedHat 4
|
 |
December 23, 2013, 11:50:48 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
|
Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1 KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
|
|
|
jedimstr
|
 |
December 23, 2013, 12:24:12 PM |
|
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.0How'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
Legendary
Offline
Activity: 2436
Merit: 1039
Linux since 1997 RedHat 4
|
 |
December 23, 2013, 12:30:05 PM |
|
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.
|
Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1 KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
|
|
|
jedimstr
|
 |
December 23, 2013, 12:43:43 PM |
|
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
|
 |
December 23, 2013, 05:02:30 PM |
|
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
Legendary
Offline
Activity: 1423
Merit: 1009
Cryptanalyst castrated by his government, 1952
|
 |
December 23, 2013, 05:43:07 PM |
|
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
Legendary
Offline
Activity: 2408
Merit: 1001
Think for yourself
|
 |
December 23, 2013, 11:46:49 PM |
|
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.
|
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
|
|
|
aigeezer
Legendary
Offline
Activity: 1423
Merit: 1009
Cryptanalyst castrated by his government, 1952
|
 |
December 24, 2013, 02:21:45 AM |
|
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
Moderator
Legendary
Offline
Activity: 2506
Merit: 1047
Ruu \o/
|
 |
December 24, 2013, 02:26:48 AM |
|
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
Legendary
Offline
Activity: 1423
Merit: 1009
Cryptanalyst castrated by his government, 1952
|
 |
December 24, 2013, 02:31:31 AM |
|
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
Moderator
Legendary
Offline
Activity: 2506
Merit: 1047
Ruu \o/
|
 |
December 24, 2013, 02:33:01 AM |
|
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
Legendary
Offline
Activity: 1423
Merit: 1009
Cryptanalyst castrated by his government, 1952
|
 |
December 24, 2013, 03:42:27 AM |
|
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.
|
|
|
|
|
Notanon
Sr. Member
  
Offline
Activity: 390
Merit: 250
Pastor of Muppets
|
 |
December 24, 2013, 09: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.0Yeah, 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.
|
AMHash
| ASICMINER ● ROCKMINER ● Purchase from: AMHash (20Th/s min) ● Havelock (1Gh/s min) Cloud-mining contracts: 0.0012 BTC per Gh ● Maintenance fee: $0.001551 per Gh per day ● Upto 6% Christmas Bonus
|
|
|
|
carly200
|
 |
December 24, 2013, 10: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?
|
|
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
 |
December 24, 2013, 10: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 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
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
Sir William
Member

Offline
Activity: 117
Merit: 10
|
 |
December 25, 2013, 06: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... 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...
|
BTC: 1ArHufTKEQZoDzoNicVAt1rBqJrvrqVzEH
|
|
|
carly200
|
 |
December 25, 2013, 08: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 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?
|
|
|
|
|