Stop using fetch...


^ should be all you need...

git pull does a git fetch followed by a git merge, you should always use git pull to bring the repo up to date.

you've got btc

and cool, I just forked the repo for the hell of it thanks for the info.

I'm in for a sheet and 16 blanks, shipping to US; Shoot me a PM with total + btc address - thanks.

interesting, I may be down to get 1 sheet + 16 blanks just for kicks.

You don't agree with it when the libusb issue predates any drillbit devices? Seems ignorant to me.

The shitty thing about the ignore list, is most people will still click the 'show post', since you are very very ignorant, my bets are you'll click on the 'show post' just for the hell of it. And yes, it is an external dependency, as are a lot of things included in the CGMiner code base, just because they are included there doesn't mean their not from an external source, but given the competency level you have displayed thus far, I can see where you wouldn't understand that.

Not only that but now you are saying it was up to Drillbit to realize the code base in CGMiner (a software not created by them) is poorly handled and that they should fix CGMiner, when really all they did was add in their driver files and make it so you could compile with said driver files. They didn't re-write CGMiner, nor should they have to, lol.

If I wanted to personally attack you, I don't think I would need to at this point, you've already shown your intelligence (or lack there of).

I think you seem to be missing the point, or rather avoiding it...

The issue with LIBUSB is not drillbit related in any way shape or form (hence why OTHER products which are officially supported by CGMiner have the issue as well). It's blatantly obvious that you want to keep ignoring this fact just so you have something to bitch and run your mouth about, so nothing anyone says here will help you. The issue has been around since before the Drillbit 8 Boards were manufactured, since before Drillbit developers ever wrote code, etc...

So how about you do some actual reading for once and learn what LIBUSB is... it's a library written in C for USB communications, which omfg, has bugs, not to mention the implementation CGMiner uses it in, had & has bugs with it. http://www.libusb.org/

Not_a_damn_thing_to_do_directly_with_drillbit.

Granted I understand if you're mentally incapable of understanding logic, I won't make fun of you for being mentally handicap, so if that is the case please speak up. However I'll gladly point out how much of an idiot someone is when all the facts are right in front of their face yet they choose to still ignore them. So which is it with you?

Sold BryanK some erupters & 49-port hub;

Kept to his word on payment and updates, very trustworthy buyer

No idea, I haven't tried PM'ing him or asking on the BFG thread again. I may try to implement it myself after I take a breather from all the repairs & everyone has their boards back and hashing.

When I say go back through the thread, I mean like back to 3.1.1, lol, the biggest issue with CGMiner (from what I can tell and in my own personal experiences) is how it interacts with USB devices. Hot-plugging is great to have however, not always the best, I think the want to always have hot-plugging while using libsub is CGMiner's biggest down fall... which you don't really have with BFGMiner, as it doesn't support hot-plugging...

I have never seen the issue on BFL, I have seen the issue on Erupters when I got up to 122 erupters on one rPi, which caused me to switch to BFGMiner (CGMiner wasn't very stable after 30 erupters anyhow). I didn't see the issues on Blue/Red Fury devices until CGMiner 3.8.0/3.8.1; If you want to browse through the hell that is the CGMiner thread here on the forums, you will find other people with LIBUSB errors on other random hardware.

And by the way... Blue/Red Fury devices, flooded CGMiner 3.8.0 and 3.8.1 with "LIBUSB" errors until the day after 3.8.1 was released, ckolivas updated the repository with code that pulled back on the timing to make it "not as trigger happy". However since I got all those errors on CGMiner, I just said fuck it and stuck with BFGMiner for those devices, as it worked perfectly fine.


**cough, cough, I wish Luke-Jr or someone would add-in support for Drillbit devices on BFGMiner.. **

If you're referring to the libusb error; That's more of an issue with CGMiner, not the actual product, though there might be some firmware updates that could change the timing.

However, I can honestly say I've been running 6 boards for far over 72hrs added 2 boards to that setup 24hrs ago and not a single error, also, on a raspberryPi running MinePeon. However I did do somethings to achieve this, probably the major thing I did was change my difficulty at my pool as well as my queue on the miner software.

I figured the queue to be 4 per 20GH/s (so, 32 @ 8 boards) and I upped the difficulty to 64 at the pool. Since the difficulty is higher, the boards aren't vomiting information as fast (almost just as fast, but not as fast), therefore it allows for some small amount of breathing room between USB communications, where as it would normally just be flooding the miner software with messages.

Why did I do these things? Well, being completely honest, I hoped on my rPi for my Blue Fury miners and forgot the one thing I loved about BFGMiner versus CGMiner, it dynamically set the queue size and a few other variables, where as CGMiner, doesn't. So, I saw the setting for my 30GH/s on my Blue Fury devices and then calculated what I needed to set it to in CGMiner and did so accordingly; Likewise I accidentally forgot to turn off the MinePeon donations, so I saw my hash rate drop at the pool (ghash.io notifies me every 15min if there's a drop) and forgot that some pools dynamically set the difficulty, which BTCGuild does and it set it to 64, so I copied that setting.

Since doing all of the above, I haven't ran into a single LIBUSB error for over 3 days now...
(Yes, I did get them before doing that, about once every 7 hours on the rPi's and about every 15hrs on Windows7.)

Now, with that being said, stating that the product is faulty here, I'd declare that to be false; Maybe more so of people not knowing how to configure settings correctly, that may very well, be true. I'll let you all be the judge of that, but I've been mining on my rPi solid now. I think it's wise to factor in all the variables before making out right accusations that a product is faulty, especially when in mining, there are *a lot* of settings and configurations that most people aren't even aware of how to use. Are there improvements that can be made in the firmware to help this issue (maybe avoid it completely)? Probably, yes, of which Angus and the Drillbit team have stated they are looking into.

So, yea... 

this might help yea, maybe... https://www.spendbitcoins.com/places/?place_type=shopping

hybrid chip 

I haven't had any issues with USB hubs and the rPi since I switched to only using RHB-500's

My rPi w/Minepeon running 8x Blue Fury, 2x Red Fury, 6x ASIC Erupters on two hubs has been solid for over 13 days now. Haven't had the need to restart the miner or rPi, actually haven't even thought about it much since it's been running so smoothly.

I use my iPhone/iPod/iPad/iHaveTooMany_iDevices chargers without any issues.

have you updated the OS packages recently?  (sudo pacman -Syu)

Honestly that's the first thing I do after any new image I make.

Curious are you using a wired or wireless connection?

I noticed tons of sluggishness when using a wireless connection while using the pi as a proxy for blades, therefore i wouldn't really recommend using a wireless connection. Just thought I'd toss that out there.