Topic: OLD: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 - page 24. (Read 308349 times)

blkmk_append_coinbase_safe2, https://gitorious.org/bitcoin/libblkmaker/commit/9f5e949f7e1e0bb49bfe8eab1d99107b3114b4c7

What do I need to copy besides bfgminer from a linux build system to a target system so I don't get undefined reference to the above?

I've tried building with/without system libblkmaker, backed down to bfgminer-3.5.x for now.

8 )

Thanks for the help there.

Hi Nwoolls.  I applied the bfgminer v4.4.0 from your branch.  Thanks for the assist on that.
But, (there's always a but) I still I have no change.  Also, I don't get the error message,
[2014-07-14 19:47:35] DMU 0: Expected nonce after 658.337158 secs (5108 secs elapsed)
 [2014-07-14 19:47:35] DMU 0: Attempting to restart, you indicated.

I have Gridseed G-blades that randomly won't start hashing when I reboot unless I do it about 20 times.
I watched my RPi rig with the 6 G-blades all day today.  I noticed my hashing was down to 17MH/s via remote SSH for about 3 hrs.  I rebooted & the hashing went up to 27Mh/s because one of the g-blades was only working at 50% (only one board active).  If I reboot as I mentioned before, on the next reboot a different G-blade will have a 1 of the 2 boards hashing & the other at a zero hashing state as I showed in the pics above on my previous posts.  I don't know what it is.


UPDATED 7/17/2014
I've tried a whole new & different RPi.
I've tried short USB cables, I've tried 3ft & 6ft USB cables.
I've also tried 10ft USB cables.  I don't mean cheap ones either.
I've change the cables to different ports on the USB hub.
I've tried plugging in 1 gridseed at a time, watching & waiting to see at what point the BFGminer starts the none-hashing on half of a Gridseed G-blade.
It's random.  Sometimes it'll just not hash on half aboard by the time I plug int the third Gridseed G-blade or the 5th or the 6th. RANDOMNESS sucks!!!  

No change.

The last thing I can think of is changing out the 28 port USB 2.0/3.0 USB hub.
Does anyone know of a good & proven USB HUB with at least 14 ports on it?

Hi, I've got 2 Rock Miner R-Boxes running on BFG miner 4.4.0. I tried over clocking them but it doesn't seem to work. They've been running for well over an hour one is staying at a consistent 32 ghs, while the other one hasn't hit 30 yet (29.32.. could be the hub I'm using for it?). Anyway I was hoping someone might have a fix for the over clock issue?


Edit:
Well, I've managed to find my own work around I don't know if this will prove useful to anyone else. So far I am able to achieve 34GHs by unplugging and replugging the power to the r-boxes

I'm with you on the not wanting to run it from a power hungry windows system.  I right now run most of miners from my GPU rig using MM.  I do have a 2nd windows system that I use as a test and reviewing system.  The third system is netbook to run some miners.  Low power and heat and runs MM great.
That being said I run my other miners from 5 different Pi setups a mixture of MinePeon, Minera, ZenController, Testing newer Zeus Controller Images and now a StarMiner setup.  Soon to migrate more miners to a MinePeon setup and some others to a Minera setup.
I am getting there.  I have to sell off a bunch of my mining gear though.

I've got them working in separate instance for the time being. Example of my current config file, I don't do anything in the command line other than load the config setup for each mining group.

"api-port" : "4028",
"expiry" : "120",
"expiry-lp" : "3600",
"failover-only" : true,
"failover-switch-delay" : "300",
"log" : "20",
"no-pool-disable" : true,
"no-client-reconnect" : true,
"no-show-processors" : true,
"no-show-procs" : true,
"queue" : "1",
"quiet-work-updates" : true,
"quiet-work-update" : true,
"scan-time" : "60",
"scrypt" : true,
"skip-security-checks" : "0",
"submit-stale" : true,
"temp-hysteresis" : "3",
"shares" : 0,
"kernel-path" : "/usr/local/share/bfgminer",
"scan" : "gridseed:all",
"set-device" : "gridseed:clock=850",
"api-allow" : "127.0.0.1,192.168.1/24"
}

Also

#gridseed
ATTRS{idVendor}=="0483", ATTRS{idProduct}=="5740", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="plugdev"
#zeusminer
ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SUBSYSTEMS=="usb", ACTION=="add", MODE="0666", GROUP="plugdev"

I run them in the same instance without issues on a few machines. I'm at a loss for how BFGMiner would confuse one for the other. What is your command line?

Just let them run in different instances? There is no drawback and everything is more stable and if one of em hangs you  don't have to restart everything just the one...

Anyone having any luck getting Gridseeds and ZeusMiner/GAWminer running on the same rig/instance of BFGminer 4.4. So far I can get them both to Detect but BFGminer see the Fury as another Gridseed.

H Nwoolls. 
Sorry about las night. I was passing out at my desk after a 13hr shift then attempting to mess with this. Not a good idea.
I'll get to this today. Thanks for your patience with this noob boob. 

git clone -b feature\/reinit-hung-gridseed https://github.com/nwoolls/bfgminer.git

Hi Nwoolls.
Sorry I can't get it.  I'm a total ID10T when it comes to this stuff.  I tried though.

This is what I did this is what resulted:

Here's the proper syntax - I keep this link handy for myself  

http://stackoverflow.com/a/4568323/33112

Note - you'll need to escape backslashes, e.g. the branch is feature\/reinit-hung-gridseed

Hi ManeBjorn.  I used to use Multiminer.  I love, except that I no longer leave my power hungry Windows PC up anymore than I have to.  That's the plus with the Raspberry Pi 4.5 watts & the Beaglebone Black about 2.5 watts.  They use very little wattage to run compared to my 500 watt PC.

Hi Nwoolls.  I'm a dunce when it comes to Linux commands.

This is what I typed:
git clone https://github.com/nwoolls/bfgminer/tree/feature/reinit-hung-gridseed

(it's probably wrong): but this is what resulted.  See the pic.

I think Bitmain is feeling a little Butt Hurt right now as the S3 begins to ship and didn't perform as expected in final assembly testing.

As you guys know I always encourage them to do so. I even poke them in my articles.
 

^ this is too true and has been proven over and over.

Please encourage Bitmain to send a sample unit and docs.
It's far more effective (for obvious reasons) for customers to ask for BFGMiner support than for devs.

Give this branch a shot and let me know if it helps:

https://github.com/nwoolls/bfgminer/tree/feature/reinit-hung-gridseed

You should see something like this when it kicks in:

 [2014-07-14 19:47:35] DMU 0: Expected nonce after 658.337158 secs (5108 secs elapsed)
 [2014-07-14 19:47:35] DMU 0: Attempting to restart

I would love to see BFG in the S3 and other hardware from the start instead of old forked cgminer versions that rot on the vine.