OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 75.

Buchi-88

legendary

Activity: 3934

Merit: 2634

Quote from: Jay_Pal on August 22, 2014, 06:47:28 AM

Quote from: -ck on August 21, 2014, 07:25:24 PM

Quote from: Buchi-88 on August 21, 2014, 07:21:20 PM

Hello guys anyone know this problem with Cgminer?

Code:

[2014-08-22 01:18:57] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:18:57] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:18:58] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:03] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:03] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:03] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:03] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:04] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:09] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:09] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:09] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:09] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:09] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:15] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:15] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:15] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:15] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:15] Icarus detect (1:20) failed to initialise (incorrect device?)

Can happen while devices are failing intermittently where they will reconnect as a new device, or failing more substantially, requiring them to be unplugged and plugged back in if they do not re-initialise.

I got lot's of those when my usb hubs failled.
Bad power and fried hubs.
They would read a pen drive but wouldn't power the BXM.
Invested in a pair of 10 ports Ankers and that problem has gone since.

THX for your answer, but I have this HUB so I think it's not the power supply or the HUB has an malfunction?

Industrial 19 port Steel casing USB Hub (with power cable & USB cable) 20 Amps @ 5v

https://bitcointalksearch.org/topic/sold-out-dipo-electronic-19-port-usb-hubs-418087

regards

Jay_Pal

legendary

Activity: 1493

Merit: 1003

Quote from: -ck on August 21, 2014, 07:25:24 PM

Quote from: Buchi-88 on August 21, 2014, 07:21:20 PM

Hello guys anyone know this problem with Cgminer?

Code:

[2014-08-22 01:18:57] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:18:57] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:18:58] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:03] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:03] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:03] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:03] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:04] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:09] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:09] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:09] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:09] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:09] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:15] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:15] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:15] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:15] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:15] Icarus detect (1:20) failed to initialise (incorrect device?)

Can happen while devices are failing intermittently where they will reconnect as a new device, or failing more substantially, requiring them to be unplugged and plugged back in if they do not re-initialise.

I got lot's of those when my usb hubs failled.
Bad power and fried hubs.
They would read a pen drive but wouldn't power the BXM.
Invested in a pair of 10 ports Ankers and that problem has gone since.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Buchi-88 on August 21, 2014, 07:21:20 PM

Hello guys anyone know this problem with Cgminer?

Code:

[2014-08-22 01:18:57] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:18:57] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:18:58] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:03] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:03] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:03] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:03] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:04] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:09] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:09] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:09] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:09] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:09] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:15] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:15] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:15] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:15] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:15] Icarus detect (1:20) failed to initialise (incorrect device?)

Can happen while devices are failing intermittently where they will reconnect as a new device, or failing more substantially, requiring them to be unplugged and plugged back in if they do not re-initialise.

Buchi-88

legendary

Activity: 3934

Merit: 2634

Hello guys anyone know this problem with Cgminer?

c

Code:

gminer version 4.5.0 - Started: [2014-08-22 01:18:18]
--------------------------------------------------------------------------------
(5s):40.06G (1m):21.89G (5m):5.968G (15m):2.103G (avg):35.78Gh/s
A:524 R:0 HW:17 WU:499.2/m
Connected to with stratum as user B
Block: 22f5d78f... Diff:23.8G Started: [01:18:18] Best share: 243
--------------------------------------------------------------------------------
USB management Pool management Settings Display options Quit
0: BXM 0 : | 3.050G / 2.388Gh/s WU:39.5/m
1: BXM 1 : | 3.750G / 3.013Gh/s WU:50.6/m
2: BXM 2 : | 3.394G / 2.837Gh/s WU:48.6/m
3: BXM 3 : | 3.775G / 3.800Gh/s WU:53.7/m
4: BXM 4 : | 3.569G / 3.212Gh/s WU:48.6/m
5: BXM 5 : | 3.080G / 2.791Gh/s WU:43.5/m
6: BXM 6 : | 3.931G / 3.064Gh/s WU:52.6/m
7: ANU 0 : | 1.980G / 1.915Gh/s WU:20.2/m
8: ANU 1 : | 1.981G / 1.898Gh/s WU:21.3/m
9: ANU 2 : | 1.975G / 1.842Gh/s WU:23.3/m
10: ANU 3 : | 1.971G / 1.862Gh/s WU:19.2/m
11: ANU 4 : | 1.958G / 1.871Gh/s WU:13.2/m
12: ANU 5 : | 1.987G / 1.874Gh/s WU:20.2/m
13: ANU 6 : | 1.929G / 1.916Gh/s WU:22.3/m
14: ANU 7 : | 1.978G / 1.890Gh/s WU:22.3/m
--------------------------------------------------------------------------------

[2014-08-22 01:18:57] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:18:57] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:18:58] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:03] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:03] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:03] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:03] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:04] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:09] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:09] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:09] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:09] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:09] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:15] BXM 0: SPI TX error -4, sent 0 of 11
[2014-08-22 01:19:15] BXM 0: SPI TX error -4, sent 0 of 12
[2014-08-22 01:19:15] FAIL: USB get_lock not found (1:20)
[2014-08-22 01:19:15] Icarus detect (1:20) failed to initialise (incorrect device?)
[2014-08-22 01:19:15] Icarus detect (1:20) failed to initialise (incorrect device?)

regards

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: -ck on August 19, 2014, 01:11:54 AM

BXM is however bitfury so assuming you don't have any other bitfury devices... restricting it as BF1 is the key there. (--usb BF1:0).

That did the trick. Thanks.

nst6563

sr. member

Activity: 252

Merit: 254

Quote from: loshia on August 20, 2014, 03:33:37 PM

Quote from: nst6563 on August 20, 2014, 03:14:39 PM

Quote from: loshia on August 20, 2014, 02:36:17 PM

Hey,
Next time before you buy something better think twice before jumping into china miners
What about the original software is it working?
I was playing with grind seed units just once grind seed chip
I can tell you that I was mining happily for hours and cgminer fork of greendsed was showing me hashes flowing when USB was not working at all
These guys are funny
So chose what you buy wisely for the feature
Never buy something with close source that is all

The original software works, and works great after I fixed it (their web gui was all screwed up pointing to the wrong files and such. Fixed the pointers, translated it all to english, and it's been mining 24x7 since I did that.). I get a steady 1.2Th/s from it. However I was contemplating putting it on leaserigs and all works except for the ability to change pools via API.

And for what it's worth, *I* didn't buy it but did agree to it. And as far as I know, most of the hardware is "made in china".

You did a nice job then. Being just a customer. Wink

And why you need stock cgminer then?
What are you after? After all these efforts and time spent to make a Chinese web translated and so on
A friendly advise do always check your pool stats against forks hash rate. It might turn out that 1.2t cgminer stats are 1t or less paid shares Wink

In my opinion for 1K+ we deserve at least shiny web translated Grin

But who cares.....

I wanted stock cgminer to see if I can get it to work with leaserigs. The original webinterface had both chinese and english in it, I simply removed the chinese as it made things look MUCH cleaner. Also, according to ghash.io, my poolside hashrate ranges anywhere from 1.05Th/s to 1.1Th/s.

And I may be "just a customer"...but I'm a highly technical one Wink

I just can't code in C Sad

loshia

legendary

Activity: 1610

Merit: 1000

Quote from: nst6563 on August 20, 2014, 03:14:39 PM

Quote from: loshia on August 20, 2014, 02:36:17 PM

Hey,
Next time before you buy something better think twice before jumping into china miners
What about the original software is it working?
I was playing with grind seed units just once grind seed chip
I can tell you that I was mining happily for hours and cgminer fork of greendsed was showing me hashes flowing when USB was not working at all
These guys are funny
So chose what you buy wisely for the feature
Never buy something with close source that is all

The original software works, and works great after I fixed it (their web gui was all screwed up pointing to the wrong files and such. Fixed the pointers, translated it all to english, and it's been mining 24x7 since I did that.). I get a steady 1.2Th/s from it. However I was contemplating putting it on leaserigs and all works except for the ability to change pools via API.

And for what it's worth, *I* didn't buy it but did agree to it. And as far as I know, most of the hardware is "made in china".

You did a nice job then. Being just a customer. Wink

And why you need stock cgminer then?
What are you after? After all these efforts and time spent to make a Chinese web translated and so on
A friendly advise do always check your pool stats against forks hash rate. It might turn out that 1.2t cgminer stats are 1t or less paid shares Wink

and it is not luck trust me. Con mentioned once that he can make any miner to show ANY hash rate with zero hw errors if we wish. But that is not the point. The point is that china forks do it on occasions now and then
In my opinion for 1K+ we deserve at least shiny web translated in English Grin

But who cares.....
If their cgminer was open source you can always merge it with cgminer official code right?

nst6563

sr. member

Activity: 252

Merit: 254

Quote from: loshia on August 20, 2014, 02:36:17 PM

Hey,
Next time before you buy something better think twice before jumping into china miners
What about the original software is it working?
I was playing with grind seed units just once grind seed chip
I can tell you that I was mining happily for hours and cgminer fork of greendsed was showing me hashes flowing when USB was not working at all
These guys are funny
So chose what you buy wisely for the feature
Never buy something with close source that is all

The original software works, and works great after I fixed it (their web gui was all screwed up pointing to the wrong files and such. Fixed the pointers, translated it all to english, and it's been mining 24x7 since I did that.). I get a steady 1.2Th/s from it. However I was contemplating putting it on leaserigs and all works except for the ability to change pools via API.

And for what it's worth, *I* didn't buy it but did agree to it. And as far as I know, most of the hardware is "made in china".

IYFTech

hero member

Activity: 686

Merit: 500

WANTED: Active dev to fix & re-write p2pool in C

Quote from: loshia on August 20, 2014, 02:36:17 PM

Never buy something with close source that is all

+1

loshia

legendary

Activity: 1610

Merit: 1000

Hey,
Next time before you buy something better think twice before jumping into china miners
What about the original software is it working?
I was playing with grind seed units just once grind seed chip
I can tell you that I was mining happily for hours and cgminer fork of greendsed was showing me hashes flowing when USB was not working at all
These guys are funny
So chose what you buy wisely for the feature
Never buy something with close source that is all

nst6563

sr. member

Activity: 252

Merit: 254

Quote from: zefir on August 20, 2014, 11:16:36 AM

Quote from: nst6563 on August 19, 2014, 06:37:59 PM

Quote from: nst6563 on August 02, 2014, 12:59:49 PM

Has anyone gotten CGMiner 4.5 to run with the Gridseed A1 units? I see A1 files in it, I've compiled it with the A1 support....but it never detects the A1 hardware when I run it.

command line: sudo ./cgminer -o pooladdress -u username -p password --bitmine-a1-options 16000:800000:2000

The unit has a built in rpi and the A1 controller board is connected to the GPIO pins. I've tried running on the image that came with the hardware, as well as compiling on a generic raspbian image....same result....it doesn't find the A1 hardware.

What am I missing?

The hardware I'm speaking of is this one in particular:
*Large image removed*

Anyone?
[...]

Look, as you noticed by the chosen config options, the upstream cgminer currently supports A1 products from Bitmine only. Without knowing the architecture of a Gridseed (or whatever product using the A1), you won't be able to get it mining (unless it is a 1:1 clone of one of Bitmine's products). If you had the required details, you (or the manufacturer) could write a variant of the A1-board-selector that abstracts the product specific properties and makes it accessible as a vector of A1-chip-chains.

Knowing more or less what I am talking about (I wrote those A1 driver and framework), I suggest you better bother the manufacturer and ask for upstream integration of their private driver (assuming there is one). They essentially have to, i.e. if your product was delivered with a private binary version of cgminer, GPL grants you the right to request the source code. If they refuse to deliver, there are means to deal with GPL violations.

But I guess you were not looking for troubles, so the short answer is this: no, it won't work.

Hey - an answer is an answer right? At least now I know I'm spinning wheels for nothing and can actually chase down the right path. I was under the assumption (I know...don't assume) that they were all at least very close hardware wise with the controller and board implementations.
If I were to get the source, what would I do with it then? I'm not a C coder, so having the source itself won't do me much good to get it working with a more recent version of cgminer. Would I give it to you to look at to gauge feasability of adding it to upstream?

zefir

donator

Activity: 919

Merit: 1000

Quote from: nst6563 on August 19, 2014, 06:37:59 PM

Quote from: nst6563 on August 02, 2014, 12:59:49 PM

Has anyone gotten CGMiner 4.5 to run with the Gridseed A1 units? I see A1 files in it, I've compiled it with the A1 support....but it never detects the A1 hardware when I run it.

command line: sudo ./cgminer -o pooladdress -u username -p password --bitmine-a1-options 16000:800000:2000

The unit has a built in rpi and the A1 controller board is connected to the GPIO pins. I've tried running on the image that came with the hardware, as well as compiling on a generic raspbian image....same result....it doesn't find the A1 hardware.

What am I missing?

The hardware I'm speaking of is this one in particular:
*Large image removed*

Anyone?
[...]

Look, as you noticed by the chosen config options, the upstream cgminer currently supports A1 products from Bitmine only. Without knowing the architecture of a Gridseed (or whatever product using the A1), you won't be able to get it mining (unless it is a 1:1 clone of one of Bitmine's products). If you had the required details, you (or the manufacturer) could write a variant of the A1-board-selector that abstracts the product specific properties and makes it accessible as a vector of A1-chip-chains.

Knowing more or less what I am talking about (I wrote those A1 driver and framework), I suggest you better bother the manufacturer and ask for upstream integration of their private driver (assuming there is one). They essentially have to, i.e. if your product was delivered with a private binary version of cgminer, GPL grants you the right to request the source code. If they refuse to deliver, there are means to deal with GPL violations.

But I guess you were not looking for troubles, so the short answer is this: no, it won't work.

nst6563

sr. member

Activity: 252

Merit: 254

Quote from: nst6563 on August 02, 2014, 12:59:49 PM

Has anyone gotten CGMiner 4.5 to run with the Gridseed A1 units? I see A1 files in it, I've compiled it with the A1 support....but it never detects the A1 hardware when I run it.

command line: sudo ./cgminer -o pooladdress -u username -p password --bitmine-a1-options 16000:800000:2000

The unit has a built in rpi and the A1 controller board is connected to the GPIO pins. I've tried running on the image that came with the hardware, as well as compiling on a generic raspbian image....same result....it doesn't find the A1 hardware.

What am I missing?

The hardware I'm speaking of is this one in particular:
*Large image removed*

Anyone?
I've re-cloned and recompiled with different configurations, all of which enable the bitmine_A1 (I also compiled with Avalon as was mentioned in a previous post, some I enabled ALL hardware). None detect the hardware.
Here are a couple screenshots of what happens when I run cgminer:

Using an rpi (obviously since it's built into the unit) and the following command line with the compiled versions of cgminer 4.5.0

Code:

sudo ./cgminer --hotplug=0 --bitmine-a1-options 0:900000:0:0 -o stratum+tcp://us1.ghash.io:3333 -u nst6563.A1 -p x

I've also tried

Code:

sudo ./cgminer --hotplug=0 --bitmine-a1-options 0:900000:0:0 -o stratum+tcp://us1.ghash.io:3333 -u nst6563.A1 -p x

as well as

Code:

sudo ./cgminer --hotplug=0 --bitmine-a1-options 0:900000:0 -o stratum+tcp://us1.ghash.io:3333 -u nst6563.A1 -p x

The command line for the version of cgminer that came with it (3.9.0) is:

Code:

sudo ./cgminer --hotplug=0 --cs=8 --hwreset --stmcu=1 --diff=8 -o stratum+tcp://us1.ghash.io:3333 -u nst6563.A1 -p x --api-listen --api-allow W:127.0.0.1 --api-port 4028 --real-quiet

canford

member

Activity: 89

Merit: 10

Quote from: -ck on August 19, 2014, 06:21:09 AM

Quote from: Jay_Pal on August 19, 2014, 06:12:19 AM

As far as I've understood, manufacturers have their share of guilty on this since they don't do any effort to distinguish how the devices get recognized.
I understand it isn't quite easy to do, it implies some effort.
But they prefer the easy way as they think we don't mix devices, we only use the ones they manufacture, they are the last water in the desert.
As far as I've followed this topic, I've seen a great effort from you, trying to have CGMiner to recognize them all, when it would be useful if they introduced themselves correctly! (Hey, Hi CGMiner! I'm a Ant Miner S3 siting on /dev/USB0! Could you please include me in the workload?)
Since you are not omniscient, you've been doing a hell of a job, given the lack of help some manufacturers provide.
At least from me, my sincere thank you!

Thanks very much

All it would have taken from the hardware manufacturers would have been to manually set the iManufacturer and/or iProduct code on the communication chip they used. Virtually all USB communication chips allow you to do this, but rushing to release shit as quickly as possible with the least effort seems to be the norm for them. I guess I can understand that but it's really not much work at all... it's just that they put precisely zero effort to anything that didn't get their hardware sold ASAP.

I suspect this situation will change now that the hardware wars are completely different and speed to marketing is no longer likely to give any competitive advantage at all now that we're in the power efficiency wars.

Given the chaos, I think cgminer is pretty amazing. The combination of a new industry, competition between vendors, and the rush-rush-rush mentality driven by constantly increasing bitcoin difficulty produces a lot of anxiety and hurried engineering. Hopefully things will settle a bit, manufacturers will make identifying their equipment easier, and bitcoin prices will rise enough that miners are not on the razor's edge of profitability all the time. That last is probably wishful thinking. I am running 12 U2s, 6 S1s and 3 SP10s, and cgminer powers all of them, no small accomplishment!

ManeBjorn

legendary

Activity: 1288

Merit: 1004

You definitely do not suck.
You have made one of the best mining software programs there is.
Because manufacturers have been lazy is not a reflection on you.
Keep up the great work. I know I appreciate as well as the mining community as a whole.
You are actually the next interview I am going to pursue for mining software in the next couple weeks after I heal from my surprise surgery on thurs.

I also agree with your stance on the violations of GPL.
Name and shame start the thread. I have also been starting an outline for an article about this situation.

Thanks again.

Quote from: -ck on August 19, 2014, 01:11:54 AM

Quote from: os2sam on August 18, 2014, 08:56:25 AM

Quote from: canford on August 18, 2014, 08:21:11 AM

That's the exact error message I get when I try your suggested --usb BXM:0

CGMiner misidentifies my Jalapeno as a BXM too.

I suck

The code only allows you to restrict by the parent driver type, and ANU and LIN are both icarus (ICA) so there's no workaround for that.

BXM is however bitfury so assuming you don't have any other bitfury devices... restricting it as BF1 is the key there. (--usb BF1:0).

Unfortunately the name is based on the first device that had that parent driver and I know BF1 doesn't make much sense for all bitfury devices...

Anyway we didn't anticipate other devices would use variants of the same driver and hadn't worked around this possibility to date, and I kinda forgot Embarrassed

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Jay_Pal on August 19, 2014, 06:12:19 AM

As far as I've understood, manufacturers have their share of guilty on this since they don't do any effort to distinguish how the devices get recognized.
I understand it isn't quite easy to do, it implies some effort.
But they prefer the easy way as they think we don't mix devices, we only use the ones they manufacture, they are the last water in the desert.
As far as I've followed this topic, I've seen a great effort from you, trying to have CGMiner to recognize them all, when it would be useful if they introduced themselves correctly! (Hey, Hi CGMiner! I'm a Ant Miner S3 siting on /dev/USB0! Could you please include me in the workload?)
Since you are not omniscient, you've been doing a hell of a job, given the lack of help some manufacturers provide.
At least from me, my sincere thank you!

Thanks very much

All it would have taken from the hardware manufacturers would have been to manually set the iManufacturer and/or iProduct code on the communication chip they used. Virtually all USB communication chips allow you to do this, but rushing to release shit as quickly as possible with the least effort seems to be the norm for them. I guess I can understand that but it's really not much work at all... it's just that they put precisely zero effort to anything that didn't get their hardware sold ASAP.

I suspect this situation will change now that the hardware wars are completely different and speed to marketing is no longer likely to give any competitive advantage at all now that we're in the power efficiency wars.

Jay_Pal

legendary

Activity: 1493

Merit: 1003

Quote from: -ck on August 19, 2014, 01:11:54 AM

Quote from: os2sam on August 18, 2014, 08:56:25 AM

Quote from: canford on August 18, 2014, 08:21:11 AM

That's the exact error message I get when I try your suggested --usb BXM:0

CGMiner misidentifies my Jalapeno as a BXM too.

I suck

The code only allows you to restrict by the parent driver type, and ANU and LIN are both icarus (ICA) so there's no workaround for that.

BXM is however bitfury so assuming you don't have any other bitfury devices... restricting it as BF1 is the key there. (--usb BF1:0).

Unfortunately the name is based on the first device that had that parent driver and I know BF1 doesn't make much sense for all bitfury devices...

Anyway we didn't anticipate other devices would use variants of the same driver and hadn't worked around this possibility to date, and I kinda forgot Embarrassed

IMHO, I don't think you suck.
As far as I've understood, manufacturers have their share of guilty on this since they don't do any effort to distinguish how the devices get recognized.
I understand it isn't quite easy to do, it implies some effort.
But they prefer the easy way as they think we don't mix devices, we only use the ones they manufacture, they are the last water in the desert.
As far as I've followed this topic, I've seen a great effort from you, trying to have CGMiner to recognize them all, when it would be useful if they introduced themselves correctly! (Hey, Hi CGMiner! I'm a Ant Miner S3 siting on /dev/USB0! Could you please include me in the workload?)
Since you are not omniscient, you've been doing a hell of a job, given the lack of help some manufacturers provide.
At least from me, my sincere thank you!

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: os2sam on August 18, 2014, 08:56:25 AM

Quote from: canford on August 18, 2014, 08:21:11 AM

That's the exact error message I get when I try your suggested --usb BXM:0

CGMiner misidentifies my Jalapeno as a BXM too.

I suck

The code only allows you to restrict by the parent driver type, and ANU and LIN are both icarus (ICA) so there's no workaround for that.

BXM is however bitfury so assuming you don't have any other bitfury devices... restricting it as BF1 is the key there. (--usb BF1:0).

Unfortunately the name is based on the first device that had that parent driver and I know BF1 doesn't make much sense for all bitfury devices...

Anyway we didn't anticipate other devices would use variants of the same driver and hadn't worked around this possibility to date, and I kinda forgot Embarrassed

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: canford on August 18, 2014, 08:21:11 AM

That's the exact error message I get when I try your suggested --usb BXM:0

CGMiner misidentifies my Jalapeno as a BXM too.

canford

member

Activity: 89

Merit: 10

Quote from: -ck on August 18, 2014, 06:37:23 AM

Quote from: canford on August 18, 2014, 06:29:15 AM

I am running 12 Antminer U2's off a dedicated Win7 box. Usually works fine, but lately I been getting tortured by cgminer thinking one of the 12 is a LIN device:

Rebooting results in the same problem. The only way to fix it is to shutdown the PC, unpower and repower all 12 of the U2s, then reboot, so it seems like something in the internal miner state itself is the cause. Then it works again for a couple of days before the problem recurs. I've tried moving things around between USB ports, same issue. Any ideas about what is causing this? Any and all help much appreciated, ckolivas you do an amazing job maintaining cgminer.

Unfortunately a lot of these devices don't have identifiers so the only thing that we have to identify them by is the communication chip they use or the protocol they share (like U2 and R-Box [LIN]), so telling them apart is precarious. You could try telling cgminer to not try to enable any lin devices by adding: --usb LIN:0

I tried that, but it just results in a cgminer error:

Is there any way to tell cgminer to look for 12 ANU devices and nothing else?

Thanks!

Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 75. (Read 5805508 times)