I have a Ubuntu Linux server with all the current updates, running a variety of miners plugged into it on cgminer 3.10.0
I plugged a nanofury NF1 into a usb hub that has a few block erupters in it and the NF1 would only mine at just less than1GH/s.
I removed the block erupters and the NF1 started mining at full speed. Even if I add just one block erupter the NF1 instantly halves it's speed. The block erupter mines at full speed only the NF1 is effected, neither reports any errors that I can see.The power pack for the hub is 2.1Amps so it should be able to handle that, so I think it might be a conflict of some sort.
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 145. (Read 5805527 times)
January 15, 2014, 10:01:18 PM
January 15, 2014, 05:47:42 PM
Hi guys, I just added a mini rig to my setup and have been getting intermittent errors to do with usb I think. I have linked some screenshots of the output cgminer is giving. I am using the latest version on windows 7 x64. I already had a single and 50 Block Erupters running but when I added the mini rig cgminer kept crashing so I took one of the usb hubs out and connected the mini rig straight to the motherboard this stopped the crashes but I am now seeing the attached errors. Any help would be great.
Btw the hubs are all usb 3 and there are 7 of them with 6 miners each.
http://imgur.com/a/fHR6b/embed
Btw the hubs are all usb 3 and there are 7 of them with 6 miners each.
http://imgur.com/a/fHR6b/embed
January 15, 2014, 12:29:08 PM
Less than 12 hours normally, for 14 units on one host
It is associated with hex2bin scan failure I am pretty sure, but I do not really know what that is.
3.8.4 - it goes hex2bin scan failure and that unit hangs
3.8.5 or later cgminer will crash
I started debugging it, but ended up solving the problem by moving everything onto powered hubs and off USB 3.0
It has not crashed since, so I have not been able to debug it any further.
This was a problem on 2 different hosts, so I consolidated down to one host thinking the host was crashing/causing problems. I think the real problem is that host was a higher end and had more USB3.0 that were being used
I started noticing that the units on the USB hub were not hanging, then just started figuring it out from there.
I'll try replacing my hubs. I logged it happening this time, and while only 2 units ended up not coming back up there were 7 that just stopped working at the same time out of the blue. It is associated with hex2bin scan failure I am pretty sure, but I do not really know what that is.
3.8.4 - it goes hex2bin scan failure and that unit hangs
3.8.5 or later cgminer will crash
I started debugging it, but ended up solving the problem by moving everything onto powered hubs and off USB 3.0
It has not crashed since, so I have not been able to debug it any further.
This was a problem on 2 different hosts, so I consolidated down to one host thinking the host was crashing/causing problems. I think the real problem is that host was a higher end and had more USB3.0 that were being used
I started noticing that the units on the USB hub were not hanging, then just started figuring it out from there.
Are you using 3.8.4 or older or using 3.85 or newer?
The only other time I have had problems like that is a small power blink- the host will stay up but it is just enough to reset the units
January 15, 2014, 02:33:31 AM
I probably missed something, but I cannot get my USB Block Erupter to work with 3.10.0, currently using 3.6.6 and it detects the erupter with no problems. Am I missing a new command line option? I see there is no cgminer-nogpu.exe anymore (yeah, been some time since I checked for updates).
Using win7 64bit, thanks in advance.
Using win7 64bit, thanks in advance.
January 14, 2014, 09:52:36 PM
I thought the last time I called you a he and I got you disturbed. Sorry I'll edit it.
January 14, 2014, 08:45:05 PM
ckOlivias can add what she likes.
I agree my avatar is very cute, but I am not a she 
January 14, 2014, 01:10:19 PM
Hey I don't know if its something mingw is doing but I'm trying to compile jimjags version of cgminer and it keeps wanting winsock2.h instead of wstcpip.h (says not compatible with winsock.h) but I think its saying it wants winsock.h as well for cgminer build and not winsock2.h
Any idea how to force it to use winsock2.h if that's what cgminer really wants in its make file? I just want to use antminers and I'm unintentionally updating the how to install cgminer on window instructions.
After I figure out what the winsock problem is I'll fork the file and then ckOlivias can add whatshe he likes. Here's the error below
edit ... Seems I get the same error trying to compile with 3.10 from github with minGW
Any idea how to force it to use winsock2.h if that's what cgminer really wants in its make file? I just want to use antminers and I'm unintentionally updating the how to install cgminer on window instructions.
After I figure out what the winsock problem is I'll fork the file and then ckOlivias can add what
edit ... Seems I get the same error trying to compile with 3.10 from github with minGW
January 14, 2014, 04:21:37 AM
I've got cgminer 3.10.0 running on Debian ARM. It seems to just quit every 23-24 hours. The rest of the OS continues perfectly, but cgminer just quits. Seems to do it around 7.30am UTC. Anyone else have this issue?
January 13, 2014, 11:09:36 PM
Hi, got a quick question
I got some antminer u1's and they are not seen as antminers in version 3.10 and are seen as amu devices and stay along the speeds of my erroupters. I know I'm supposed to use a different version since its not in the normal version yet, but how do I keep them from being detected in 3.10 when I get a working zip file for the u1 version cgminer(I'm getting invalid file errors from https://github.com/AntMiner/AntGen1/tree/master/cgminer )?
Thanks
Yeah design fail there.I got some antminer u1's and they are not seen as antminers in version 3.10 and are seen as amu devices and stay along the speeds of my erroupters. I know I'm supposed to use a different version since its not in the normal version yet, but how do I keep them from being detected in 3.10 when I get a working zip file for the u1 version cgminer(I'm getting invalid file errors from https://github.com/AntMiner/AntGen1/tree/master/cgminer )?
Thanks
The U1 is exactly the same USB chip and naming at the USB level as the AMU - not even an iProduct, iManufacturer change.
As was discussed in IRC, the code solution would probably be to test for U1 first and expect a 5 byte reply and on failure (if 4 bytes instead of 5 bytes) hand it on to the Icarus driver.
To stop Icarus looking at any USB devices - as usual: --usb ICA:0
jimjag seems to already have a build that can do icarus and antminers but they only have compiled for Mac's. I'm trying to follow the instructions to compile with minGW to try it but the instructions are not working for me (darn program doesn't seem to work right with Win7 64bit)
January 13, 2014, 06:42:06 PM
To stop Icarus looking at any USB devices - as usual: --usb ICA:0
BTW: There is no possibility to do this with Bitfurry - right? There is nothing lik --usb bitfury:0? It doesn't work and I don't find anything in the docs.
Concerning Nanofury: The actual version runs fine on one host with 11 Nanofury. Another one is a problem. Try to figure out.
January 13, 2014, 06:25:18 PM
Hi, got a quick question
I got some antminer u1's and they are not seen as antminers in version 3.10 and are seen as amu devices and stay along the speeds of my erroupters. I know I'm supposed to use a different version since its not in the normal version yet, but how do I keep them from being detected in 3.10 when I get a working zip file for the u1 version cgminer(I'm getting invalid file errors from https://github.com/AntMiner/AntGen1/tree/master/cgminer )?
Thanks
Yeah design fail there.I got some antminer u1's and they are not seen as antminers in version 3.10 and are seen as amu devices and stay along the speeds of my erroupters. I know I'm supposed to use a different version since its not in the normal version yet, but how do I keep them from being detected in 3.10 when I get a working zip file for the u1 version cgminer(I'm getting invalid file errors from https://github.com/AntMiner/AntGen1/tree/master/cgminer )?
Thanks
The U1 is exactly the same USB chip and naming at the USB level as the AMU - not even an iProduct, iManufacturer change.
As was discussed in IRC, the code solution would probably be to test for U1 first and expect a 5 byte reply and on failure (if 4 bytes instead of 5 bytes) hand it on to the Icarus driver.
To stop Icarus looking at any USB devices - as usual: --usb ICA:0
January 13, 2014, 03:24:04 PM
Hi, got a quick question
I got some antminer u1's and they are not seen as antminers in version 3.10 and are seen as amu devices and stay along the speeds of my erroupters. I know I'm supposed to use a different version since its not in the normal version yet, but how do I keep them from being detected in 3.10 when I get a working zip file for the u1 version cgminer(I'm getting invalid file errors from https://github.com/AntMiner/AntGen1/tree/master/cgminer )?
Thanks
I got some antminer u1's and they are not seen as antminers in version 3.10 and are seen as amu devices and stay along the speeds of my erroupters. I know I'm supposed to use a different version since its not in the normal version yet, but how do I keep them from being detected in 3.10 when I get a working zip file for the u1 version cgminer(I'm getting invalid file errors from https://github.com/AntMiner/AntGen1/tree/master/cgminer )?
Thanks
January 13, 2014, 11:33:44 AM
Less than 12 hours normally, for 14 units on one host
It is associated with hex2bin scan failure I am pretty sure, but I do not really know what that is.
3.8.4 - it goes hex2bin scan failure and that unit hangs
3.8.5 or later cgminer will crash
I started debugging it, but ended up solving the problem by moving everything onto powered hubs and off USB 3.0
It has not crashed since, so I have not been able to debug it any further.
This was a problem on 2 different hosts, so I consolidated down to one host thinking the host was crashing/causing problems. I think the real problem is that host was a higher end and had more USB3.0 that were being used
I started noticing that the units on the USB hub were not hanging, then just started figuring it out from there.
I'll try replacing my hubs. I logged it happening this time, and while only 2 units ended up not coming back up there were 7 that just stopped working at the same time out of the blue. It is associated with hex2bin scan failure I am pretty sure, but I do not really know what that is.
3.8.4 - it goes hex2bin scan failure and that unit hangs
3.8.5 or later cgminer will crash
I started debugging it, but ended up solving the problem by moving everything onto powered hubs and off USB 3.0
It has not crashed since, so I have not been able to debug it any further.
This was a problem on 2 different hosts, so I consolidated down to one host thinking the host was crashing/causing problems. I think the real problem is that host was a higher end and had more USB3.0 that were being used
I started noticing that the units on the USB hub were not hanging, then just started figuring it out from there.
January 12, 2014, 09:14:10 AM
Heads up to everyone: I will be travelling from today for just over a week, and while I'll be checking in on the forums, I will be relatively unavailable and unable to do any significant debugging, fixes or updates. Everyone behave while I'm away, mkay?
Noooooo! What if Cgminer catches me on fire!!!
January 12, 2014, 09:13:44 AM
there is a command that let you see all your best shares?
No, just the value of the best share overall in on the screen.That is available also via the API summary command, and also best share value per pool via the API pools command.
January 11, 2014, 10:04:37 PM
Heads up to everyone: I will be travelling from today for just over a week, and while I'll be checking in on the forums, I will be relatively unavailable and unable to do any significant debugging, fixes or updates. Everyone behave while I'm away, mkay?
Noooooo! What if Cgminer catches me on fire!!!
January 11, 2014, 07:46:35 PM
With my Chilis I find that they tend to go out in groups as well. I need to start logging to confirm, but they'll run for a week or more without issue and then 4 seem to go out at the same time.
Yes that's common as the failure is at the usb hub level, not at the device level. cgminer tries to reset devices that stop responding but what really needs to be reset is the hub. I guess I could potentially look at the parent device and try to send it a reset but then that would be the wrong thing to do if the device was at fault and not the hub. The errors we get back at the software level are not entirely helpful to distinguish the two.
January 11, 2014, 10:06:10 AM
there is a command that let you see all your best shares?
January 11, 2014, 08:58:52 AM
Yes Sir :-)
Happy Holidays !
+1 Happy Holidays !
January 11, 2014, 08:46:50 AM
happy holiday and take a rest men 
Jump to: