OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0

[jborkl]

I have spent quite a bit of time with the Chilis figuring out why they do what they do, the best and solid solution is

1. I run them all off of powered USB hubs, none are plugged directly into the computer.
2. They do not like USB 1.1 or USB 3.0 - they will eventually have a problem and hang (to me this seems to be the root issue, but I do not know for sure)

I do not know the cause or why, I really only try to fix things so they don't do it again. This has solved the problem for me.

This also solved the Hex2bin scan failed error, which might be related- I don't know

[1524697767]

1524697767

[1524697767]

1524697767

[MrTeal]

I have spent quite a bit of time with the Chilis figuring out why they do what they do, the best and solid solution is

1. I run them all off of powered USB hubs, none are plugged directly into the computer.
2. They do not like USB 1.1 or USB 3.0 - they will eventually have a problem and hang (to me this seems to be the root issue, but I do not know for sure)

I do not know the cause or why, I really only try to fix things so they don't do it again. This has solved the problem for me.

This also solved the Hex2bin scan failed error, which might be related- I don't know

That's kind of strange, the 5V line on the USB connector isn't even terminated on the board so it's drawing 0mA of current from the USB connector. I can't say I've ever tried using a USB 1.1 hub though, I'm not sure I have one.
When you say eventually they will hang with USB3, how long does it usually take for you? I've had some running for days at a time on USB3.0 on my desktop, but obviously using the USB2.0 differential pair.

[jborkl]

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.

[-ck]

Con,

Do you use a 32 bit integer for block reward difficulty anywhere?  eleuthria has pointed out that we are rapidly approaching the point where difficulty will overflow.

https://bitcointalk.org/index.php?topic=406420.0

No I don't.

[-ck]

Don't forget I always create drivers for cgminer that report hashrate based on real shares generated, not some arbitrary amount of hashes done (that doesn't translate into meaningful hashrate). I can happily make you a build that shows you making 2.5TH if you like. Make sure you check your pool to see how many effective shares you're submitting with your other drivers... People don't like the truth.

I want to test again for more long interval but keep getting this error

Looks like a real bug. Can you try a debug build following the directions here please:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

Ok, i will try  

Update:
From bt full command

Code:

#0  0x00016504 in hash_pop () at cgminer.c:5736
        work = 0x0
        tmp = <optimized out>
        hc = <optimized out>

Thanks for that.

This actually looks like a bug with the stratum reconnect code in cgminer since it's happening shortly after btcguild is issuing a reconnect (i.e. change address request), and is coincidental that it's happening for you with the nanofury. Unfortunately I don't have the time to debug and fix this at the moment so a workaround would be to use the redirection address you see in your logs directly instead of the standard btcguild pool address (or a different pool). I've just pushed some generic changes to git which might help this but I don't imagine it will be enough.

[-ck]

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?

[rgr_rgr]

Yes Sir :-)

Happy Holidays !

[Zich]

Thanks for that.

This actually looks like a bug with the stratum reconnect code in cgminer since it's happening shortly after btcguild is issuing a reconnect (i.e. change address request), and is coincidental that it's happening for you with the nanofury. Unfortunately I don't have the time to debug and fix this at the moment so a workaround would be to use the redirection address you see in your logs directly instead of the standard btcguild pool address (or a different pool). I've just pushed some generic changes to git which might help this but I don't imagine it will be enough.

No problem 

And yes, changing to the redirect address work, less error now. Thanks ck & happy holiday 

[-ck]

Thanks

Pushed a quick fix to git for a bug that would make cgminer crash on removing some usb devices.

[chek2fire]

happy holiday and take a rest men

[loshia]

Yes Sir :-)

Happy Holidays !

+1

[Amph]

there is a command that let you see all your best shares?

[induktor]

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.

could it be possible to include an exernal GPIO reset in the program, I mean if the software reset didn't go trough, wait a while, and if still not responding send a GPIO signal, we can use that GPIO port with a small relay and execute a hardware power cycle.

[Powell]

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!!!

[kano]

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.

[kano]

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!!!

Burn, baby burn.

[MrTeal]

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.

[techman05]

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

[kano]

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.
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

[rgr_rgr]

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.