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

Zich

legendary

Activity: 1190

Merit: 1000

Quote from: -ck on January 10, 2014, 05:33:40 PM

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 Grin

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

rgr_rgr

member

Activity: 115

Merit: 10

Yes Sir :-)

Happy Holidays !

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Zich on January 10, 2014, 04:32:37 AM

Quote from: -ck on January 10, 2014, 04:16:26 AM

Quote from: Zich on January 10, 2014, 03:02:38 AM

Quote from: -ck on January 10, 2014, 02:10:06 AM

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 =
hc =

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: ?? on ??

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://bitcointalksearch.org/topic/note-to-pool-operators-public-private-difficulty-and-your-softwaredatabase-406420

No I don't.

jborkl

sr. member

Activity: 246

Merit: 250

Team Heritage Motorsports

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.

MrTeal

legendary

Activity: 1274

Merit: 1004

Quote from: jborkl on January 10, 2014, 11:30:09 AM

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

sr. member

Activity: 246

Merit: 250

Team Heritage Motorsports

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

Fletch

full member

Activity: 168

Merit: 100

I'll have a steak sandwich and a... steak sandwich

Sorry if this has been addressed before, but I tried searching and came up empty. I'm trying to find out what the two hashrates for a particular GPU/ASIC/FPGA represent. The total hashrates shown at the top of the UI I understand - on the left a 5 second average and on the right the average since the app was started. For individual GPUs however, I'm confused.

One of my GPUs is currently showing 724.1K/728.7K. The value on the left is very stable and rarely changes, but the value on the right changes constantly (+-1K). It makes perfect sense to me that the value on the left is the 5s average for that particular card. However, if the value on the right is the "total" average since the card started mining, why isn't it even more stable than the value on the left?

Or have I missed anything?

Zich

legendary

Activity: 1190

Merit: 1000

I just test cgminer3.10.0 on raspi under wheezy without setting to USB 1(delete dwc_otg.speed=1)

Work fine except for the error when start cgminer. After several times restart, cgminer run fine with nanofury
But after some minute one of nanofury off

Code:

[2014-01-10 19:01:50] NF1 1: Error -7 receiving MCPSPITransfer received 0 of 64
[2014-01-10 19:01:50] NF1 1 failure, disabling!

Zich

legendary

Activity: 1190

Merit: 1000

Quote from: -ck on January 10, 2014, 04:16:26 AM

Quote from: Zich on January 10, 2014, 03:02:38 AM

Quote from: -ck on January 10, 2014, 02:10:06 AM

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 =
hc =
#1 get_work (thr=0x75838, thr_id=91372) at cgminer.c:5929
work = 0x0
#2 0x0004154c in nf1_scan (info=0x93918, bitfury=0x75580, thr=0x75838)
at driver-bitfury.c:910
ret = 0
#3 bitfury_scanwork (thr=0x75838) at driver-bitfury.c:949
bitfury = 0x75580
info = 0x93918
#4 0x0001e4fc in hash_driver_work (mythr=0x75838) at cgminer.c:6551
diff = {tv_sec = 0, tv_usec = 242146}
hashes =
tv_start = {tv_sec = 1389374622, tv_usec = 778640}
tv_end = {tv_sec = 1389374622, tv_usec = 778640}
cgpu = 0x75580
drv = 0x75940
thr_id = 1
hashes_done = 0
#5 0x0001090c in miner_thread (userdata=0x75838) at cgminer.c:6605
mythr = 0x75838
thr_id =
cgpu =
drv = 0x75940
threadname = "miner/1", '\000'
__func__ = "miner_thread"
#6 0x40267b04 in start_thread () from /lib/arm-linux-gnueabi/libpthread.so.0
No symbol table info available.
#7 0x4037965c in ?? () from /lib/arm-linux-gnueabi/libc.so.6
No symbol table info available.
#8 0x4037965c in ?? () from /lib/arm-linux-gnueabi/libc.so.6
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: Zich on January 10, 2014, 03:02:38 AM

Quote from: -ck on January 10, 2014, 02:10:06 AM

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

Zich

legendary

Activity: 1190

Merit: 1000

Quote from: -ck on January 10, 2014, 02:10:06 AM

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: zomnut on January 09, 2014, 11:51:07 AM

Quote from: netfun2000 on January 09, 2014, 07:00:28 AM

Raspberry PI Make Error:
...

...
CCLD cgminer

cgminer-libbitfury.o: In function `spi_reset':
/home/minepeon/cgminer/libbitfury.c:226: undefined reference to `mcp2210_set_gpio_settings'
/home/minepeon/cgminer/libbitfury.c:233: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:239: undefined reference to `mcp2210_set_gpio_settings'
cgminer-libbitfury.o: In function `spi_txrx':
/home/minepeon/cgminer/libbitfury.c:255: undefined reference to `mcp2210_spi_transfer'
/home/minepeon/cgminer/libbitfury.c:265: undefined reference to `mcp2210_spi_transfer'
collect2: error: ld returned 1 exit status
make[2]: *** [cgminer] Error 1
make[2]: Leaving directory `/home/minepeon/cgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/minepeon/cgminer'
make: *** [all] Error 2

Confirmed building on a Beaglebone as well:

Code:

autogen.sh && ./configure --enable-bflsc && make

That will fail when linking as shown in netfun2000's dump. Adding --enable-bitfury to the configure command will workaround the bug and build successfully.

Code:

autogen.sh && ./configure --enable-bflsc --enable-bitfury && make

It would seem that without --enable-bitfury, there is some partial libbitfury leakage into the build process.

Fixed in git, thanks.

chek2fire

legendary

Activity: 3430

Merit: 1142

Ιntergalactic Conciliator

Thanks again for your great work!

fcmatt

legendary

Activity: 2072

Merit: 1001

Does anyone know how to patch stratum proxy so that cgminer 3.7.2, for example, does not get constant target-miss errors when submitting shares when connected to a stratum to stratum proxy? 3.1.1 works fine.

I would rather patch the proxy then cgminer. Anyone have any advice or can i provide more info to debug this?

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Powell on January 09, 2014, 05:12:40 PM

Yup these units all have the USB port still. And awesome news! I have a BB Black that will be here Tuesday. Though I built a i5 4670k with 16 gigs to be my R&D box. I have Ubuntu server but was going to switch to Arch because this thing was built to be headless after OS install. I'll have to try it out tonight and see if I can get it to work.

Going to use the BB Black on a few other projects. The PI is nice but you are right the USB faults blow!

So when I get home I will read a few of the threads. When it plugs in the system should detect the Avalon control unit and its two blades. It will still control the fans and such (water cooling hopefully in next week). Then just setup cgminer for Avalon support as always, etc. If so will this be viable at with 7 boxes at 1.5 TH/s? Of course each would be on powered USB hubs connected to the Asus Premium mobo.

If you and anyone else would think this would work I would love you very very long time lol!!

Well ... I've managed to get an RPi to emulate more than 3TH/s ... on SPI
The only thing missing was getting work from the pool and submitting shares back to the pool.
Never tried it on USB though ...

MrTeal

legendary

Activity: 1274

Merit: 1004

Quote from: -ck on January 09, 2014, 05:48:33 PM

Quote from: MrTeal on January 09, 2014, 05:35:59 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.

Well, it's a 10 port hub, but that's most likely three 4 port hubs internally chained in one package.

Is there a way on Windows to force all the units to come up in the same order each time to isolate which hub is causing the issue?

Beastlymac

hero member

Activity: 630

Merit: 501

Miner Setup And Reviews. WASP Rep.

Quote from: -ck on January 09, 2014, 08:59:29 AM

Quote from: rgr_rgr on January 09, 2014, 08:50:05 AM

Please add one parameter for it. With 54 bits the nanofury runs outside usb2.0 specs. I was able to melt a psu of a cheap hub. I expect users having problems with nanofurys because the hub is to weak for 54 bits.

I think the default should be at 50 with a parameter to change it.

Will consider when I get back from holiday thanks. It's a one line change if you wish to alter it for your build in driver-bitfury.c line 417. When I almost burnt myself on one, I did think whoever called the devices I received "ice" was seriously smoking something.

It is advised to provide cooling when over clocking to 54 bits. 50 is the stock clock. At 50 the device doesn't get to hot. Also "Ice" mainly had to do with the white colour.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: MrTeal on January 09, 2014, 05:35:59 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.

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