Because xiangfu tested and found no issues I'm pretty sure nothing's wrong with the code itself. It's probably my toolchain or something with the device, I just mentioned the code because without calling that function my openwrt cgminer has been running for 2 days now and as soon as it gets called, segfault.

Thanks. I know about MAX_DEVICES and I don't yet have enough cards to make it worth changing

But doing  some more debug I realized the function that triggers the segfault (in an unrelated place, so I'm guessing memory mismanage) is cgminer.c:regeneatehash(work). This is only called if doing verbose output and since you are passing -q to your cgminer you do net follow this code path. Could you give it a try without the -q, just to make sure it's not some weird thing with my setup? It segfaults as soon as a nonce is submitted to the pool.

Also, did you have to do anything to handle the device's endianess? It's weird, because I had to swab32 the data I receive which is consistent with BIG_ENDIAN, but defining __BIG_ENDIAN__ breaks everything hard. Could be an effect of the bi-endianess of mips, dunno.

That's what I get for not reading through properly. I read "I got a Mt. Gox Free Yubikey" and skipped the rest... I already got one for free from MtGox so I'll just retract myself from further bidding.

2 btc shipped to Europe.

I've been trying to get cgminer working on another TP-LINK device (TL-MR3420) but every time it submits a proof of work to the pool it segfaults. I haven't been able to properly debug it but it seems the json_rpc_call() is returning an empty string, so I'm pointing my quicker finger at libcurl. Can you give me a quick overview of your build env and process?

Not really. It hasn't been up that long, but I guess it is easy for it to get "harvested" into a botnet list of usable IPs, I guess.

That's CRAZY!!!

That IP is mine, I have a bitcoind running there but not only are the generation addresses not mine but also I have never found a block there that I can remember.

So... what's going on?

I've hacked hotplug support into my ztex cgminer fork, but when I say 'hacked' I'm not joking, it's just a proof of concept.

There are a few things that I'd need to get this cleaned up:

 - A hotplug managing thread. I'm spawning the first ztex thread on startup as the hotplug manager which in turn will handle (re)connects, but this should be a proper top level thread.
 - Proper support for adding threads on the fly; I added a MAX_THREADS def and alloc memory for all of them on startup in thr_info[], because otherwise the other threads (long polling, watchdog, etc) would become interleaved with the mining threads and break all the "for i in len(mining_threads)" that expect 0 based and sequencial miner_threads. A simple solution to prevent the need to pre-alloc would be to move all non mining threads to the top of the array instead.
 - A little more dynamic variables handling the curses output, specifically being able to add lines to the device statuses.
 - When unplugging I'm setting deven to DEV_DISABLED, but there should really be a DEV_DISCONNECTED state too. I didn't need it because I search for devices being disabled and ztex, reusing those entries and threads as needed (because the only time ztex devices are disabled is when they are disconnected or malfunctioning) but if cgminer ever supports hotplugging for multiple device types we really need to know exactly which devices[] entries we can reuse.

There's more, but if you just look at my changes to cgminer.c you'll see what I mean.

What I've done works for me but I don't feel it is even close to clean to make a pull request out of it (without even going into the fact I changed a lot of tab indentations to double space ) but I would really love to work with the core developer(s) in order to come up with a plan that stands a chance of being accepted in the mainline.

Update code at the usual place: https://github.com/nelisky/cgminer/tree/ztex

(cross posting from the cgminer thread)

A small status update: the cgminer support for ztex boards now compiles and runs on linux, osx and windows. There are still features missing and the hash rate reporting is pretty broken but the boards hash at their expected speed. Check it out: https://github.com/nelisky/cgminer/tree/ztex

Let me know of any problems / suggestions.

A small status update: the cgminer support for ztex boards now compiles and runs on linux, osx and windows. There are still features missing and the hash rate reporting is pretty broken but the boards hash at their expected speed. Check it out: https://github.com/nelisky/cgminer/tree/ztex

Let me know of any problems / suggestions.

I've started to get ztex boards supported on cgminer. The current implementation uses libusb-1.0, compiles cleanly on linux (ubuntu, but all others should be fine) and osx (snow leopard here). I'll try to make it work for windows soon; https://github.com/nelisky/cgminer/tree/ztex

This is not feature complete, not all that tested so be careful. I have been mining with it for a while and the biggest caveat is that the hash rate measurement is completely broken. It seems cgminer doesn't like when I do a full nonce scan that can take 12~15 secs and only report the calc'd nonces at the end of that. Limiting the nonce space does make it report correctly and of course the actual speed is the ~200MHs expected from the board regardless of what cgminer reports

But what I'd really like to put in, and I'm not sure if this will be well supported in cgminer, is hotplug support. Will I be able to dynamically add / remove workers? Should I use a main worker thread and then spawn child threads, one per board? I would also like to use multiple boards per thread and just split the nonce space, as there is enough time between polls to handle that.

Opinions? Pointers? All well appreciated

I need a good excuse to look at the source code, so I might take a stab at that if I get a little off time.

I love that electrum can be used as a simple text only client (something I need) without needing to have a long running process there. The one thing I couldn't immediately do (though I'm sure it wouldn't be hard to fix if not yet supported) is being able to import public addresses to monitor, without having to also store their priv keys.

Did I just miss the way to do this?

JMS74: Tal como já foi dito, as exchanges funcionam bem se não tiveres muita pressa, com a vantagem de comprares a 'spot price'.

Se usares irc, podes tambem perguntar em #bitcoin-otc-eu no freenode, ele há gente de toda a europa por lá (e não só).

Eu pessoalmente costumava usar o mtgox, mas estou mais no intersango desde que o mtgox ficou sem SEPA e, francamente, recomendo muito o intersango. Mas o -otc é sem duvida o melhor sítio para combinar transações "em pessoa".

Watching closely...

Me wants...

Backup servers are fine, and they do solve the most common use case but my biggest pain is not pool downtime, rather network issues and no backup pool will help with those.

So just not sending new work to the board for 5 minutes will trigger low power sounds like a great feature, and if I want to force the FPGA to hold still I can issue a resetFpga() though that means I need to reconfigure it afterwards, correct?

You may want to read my code instead, as python is much more readable than java and you have everything I needed on mpbm in one single source.

https://github.com/nelisky/Modular-Python-Bitcoin-Miner/blob/ztex/worker/fpgamining/ztexdev.py

I will try to find you on irc once I get some work things out of the way.

Every time you poll ztex board you get 2 x nonce and 2 x goldennonce. The latter is when there's a diff=1 share found and the former is just the last calculated nonce (twice because ztex uses 2 hashers in parallel, I believe).

I don't know why as it's been a while since I had to tinker with the sha256 algo, but hash(nonce)[28:32] == H7+0x5be0cd19 if the hasher is doing its thing. Ztex can set me straight if I'm full of it right now

But regardless, in a nutshell you get nonces to verify at every read, but the board verifies and stores the golden nonces itself. I am assuming that going the interrupt transfer route you would only be interested in getting transfers in the event of a golden nonce, making the error rate resolution much smaller and potentially harmful to the board.

If, on the other hand, you would get interrupt transfers for every nonce calculated... well, nothing gained from current approach, right?

I might have gotten this all wrong, so feel free to call bs.

I had read it, but apparently misunderstood it. Sorry.

So basically 9x650 + 1x13000 == 10x650 if you have diff set at 650, got it.