OLD: BFGMiner 3.10.0: modular ASIC+FPGA, GBT+Strtm, RPC, Mac/Lnx/W64, AntU1, DRB

[nwoolls]

• Oh, and the null termination byte in API replies was removed from bfgminer for some reason. Incompatibility ftw!

Hey, I try to keep it compatible! Why no bug report? When did this change, and what null byte should there be?

Hey Luke. I think this may be why I started getting the issues I communicated to you starting a month or two ago with invalid data coming across from the devs API call. cgminer terminates each API call with a NULL character so that API clients know once they'v received the full response. This was removed from bfgminer at some point.

I'm sketchy on the details beyond that - just saw it discussed on IRC.

[1715085032]

1715085032

[1715085032]

1715085032

[1715085032]

1715085032

[1715085032]

1715085032

[juhakall]

• Oh, and the null termination byte in API replies was removed from bfgminer for some reason. Incompatibility ftw!

Hey, I try to keep it compatible! Why no bug report? When did this change, and what null byte should there be?

Hey Luke. I think this may be why I started getting the issues I communicated to you starting a month or two ago with invalid data coming across from the devs API call. cgminer terminates each API call with a NULL character so that API clients know once they'v received the full response. This was removed from bfgminer at some point.

I'm sketchy on the details beyond that - just saw it discussed on IRC.

The problem I've seen is that some scripts expect the null character \0 to be there, and don't recognize any response without it. I didn't even realize myself that there was a null character on cgminer's responses, because all my own custom-made scripts try to decode any responses after the connection is closed by the other end, and I guess the libraries I've used automatically trim the null character. It's not really needed because cgminer & bfgminer always close the connection after a response. But I can understand the reasoning why some programmers prefer to rely on a termination character on network communications. That way they don't have to rely on the other end closing the connection. The null character is trivial to trim from responses, working around a missing one if your code expects it is a bit harder.

[superdork]

man i am LOST!!

Can somebody just post a link to the BFL jalapeno driver please.

BFL links to this thread when you click on the driver and I feel like I am looking at hieroglyphics.

[Luke-Jr]

man i am LOST!!

Can somebody just post a link to the BFL jalapeno driver please.

BFL links to this thread when you click on the driver and I feel like I am looking at hieroglyphics.

Mac/Windows driver: http://www.ftdichip.com/Drivers/VCP.htm
Then, download BFGMiner from the first post and go through the README file.

[mb300sd]

I'm running bfgminer on bitfury right now, couldn't get chainminer to work at all. It'll run for 5-10 minutes just fine, and then I get screens of this

[2013-11-12 01:14:15] BSB 3cc: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cd: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3ce: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cf: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cg: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3ch: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3ci: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cj: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3ck: bitfury_init_oldbuf: Giving up after 4 tries
[2013-11-12 01:14:15] BSB 3cl: bitfury_init_oldbuf: Giving up after 4 tries

What exactly does this mean? It works fine again immediately after restarting bfgminer.

[Luke-Jr]

NEW VERSION 3.6.0, NOVEMBER 12 2013

3.6 is only pulling in updates from cgminer 3.8.1, notably including the Klondike driver, which I hope to rewrite eventually. Please note that scrypt support is now officially unmaintained since Con has decided to remove it from cgminer. Any interested parties who want to see scrypt remain supported should step up to maintain it sooner rather than later, or I may just remove it at some point. Hashfast and TechnoB⃦it drivers are still planned, but not in this release yet (cgminer's Hashfast driver is not usable for BFGMiner).

Human readable changelog:

• klondike: New driver, just imported from cgminer mostly as-is for now.
• opencl: Support will remain, but it is not compiled by default. Use --enable-opencl to build it.

Full changelog:

• RPC: Bump to 2.2 for Works in POOLS
• Bugfix: klondike: Don't try to free off the stack
• configure: Update klondike checks for libusb
• klondike: Autodetect by VID/PID/Manufacturer, rather than too-short "K16" Product search
• Remove accidentally added ASIC-README
• klondike: Remove noop identify function
• klondike: Replace deprecated statline with temperature and ManageTUI stuff
• --shares should be scaled to diff1 not absolute number of shares
• More README updates.
• Minor README updates.
• sha2 allow external access to some macros and the K array
• klondike: Fixed a math issue when reporting fan speed on the status line.
• Add a get and queue helper work function.
• Reset the work_restart bool after the scanwork loop in case the driver flushes work synchronously.
• Get rid of the stage thread since all work can be asynchronously added now via hash_push anyway.
• Fix for opt_worktime on big endian machines.
• Do get_work in fill_queue without holding other locks.
• Make hash_pop signal the work scheduler each time it waits on the conditional that it should look for more work.
• Remove discarded work from quota used.
• Display works completed in summary and API data.
• Store how many work items are worked on per pool.
• Add the ability to add uint8 and uint16 entities to api data.
• klondike - initialise stat_lock
• klondike - better to unlock locks than to lock them twice
• Remove roundl check and define
• 'llround' is more suitable here than 'roundl'
• klondike - change options to clock and temptarget only
• klondike - fix another uninit dev warning
• klondike - downgrade 'late update' but add an idle detect - and correct error levels
• klondike - fix isc uninit warning
• klondike - drop the device for hotplug if it's unresponsive
• klondike - single 'shutdown' and ensure it happens
• klondike remove SCNu8 - unsupported on windows
• klondike - fix uninitialised dev bug
• Don't attempt to disable curses or print a summary during an app restart to prevent deadlocks.
• klondike - error condition handling
• Modify Makefile to only include opencl related code when configured in.
• Convert opencl to need to be explicitly enabled during build with --enable-opencl
• Implement a cglock_destroy function.
• Implement a rwlock_destroy function.
• Implement a mutex_destroy function.
• Simplify queued hashtable by storing unqueued work separately in a single pointer.
• Add cgminer compatibility macro for ms_tdiff
• klondike rewrite work control
• allow __work_complete() access
• miner.h allow devices to tv_stamp work
• klondike - can only calculate the nonce difference on or after the 2nd nonce
• klondike - correct/reverse min/max stats
• klondike: Remove unnecessary devlock
• klondike - use a link list queue rather than a circular buffer - and add timing stats
• Klondike - increase circular read buffer size
• Klondike - extra zero value and range checking in temp conversion
• klondike - display MHz also
• klondike correct cvtKlnToC() temperature calculation
• klondike - correct 1st reply debug based on define
• klondike - debug dump structured replies
• klondike - avoid division by zero if maxcount is unexpectedly zero
• klondike store and report errorcount and noise
• klondike - fix chipstats api stats buffer overrun with 16 chips
• klondike add new nonecount only once
• klondike - report mh/s based on nonces found + put old estimate into API stats
• klondike use a memcpy
• klondike fix bracket tabs indenting
• klondike: Update code to current git
• Klondike update code to current git
• Add Klondike to README
• Add Klondike to README.ASIC
• Klondike to main directory
• Klondike consistent code spacing
• Klondike update driver code to current git
• klondike: update firmware for 16 chips, add dist files
• klondike: beta final 0.3.0 release
• klondike: updated firmware, IOC method
• klondike: prevent nonces when not state W
• klondike: added driver config option support
• klondike: fixes for 300 MHz, fix K1 parts list
• klondike: update driver, docs
• klondike: update firmware & utils
• klondike: updated cgminer driver for 3.3.1
• klondike: update firmware and driver, create new cgminer fork
• update klondike driver
• klondike: add cgminer driver file as-is

Full changelog (3.5.2):

• README.scrypt: Update to reflect current status of code (unmaintained); remove Con's litecoin donation address (leaving his bitcoin one) since it is unknown if he still accepts donations with litecoin
• Bugfix: minerloop_async: Check the correct _mt_disable_called flag
• bitforce: Allow ZCX response to override Manufacturer string
• Bugfix: RPC: Restore null termination on responses
• Bugfix: configure: We need DLOPEN_FLAGS for lowlevel hid too
• Add additional debug information to help track work through BFGMiner
• README: Update hidapi dependency for HashBuster
• Bugfix: bigpic: Convert device serial and nonces to host endian
• Bugfix: modminer: Ensure devices that fail probe are closed properly
• Bugfix: bitforce: Ensure devices that fail probe are closed properly
• Bugfix: littlefury: Ensure devices that fail probe are closed properly
• Bugfix: bigpic: Ensure devices that fail probe are closed properly
• nanofury: Attempt to be more resilient to problems

[FrontLineFodder]

Luke,

does 3.6 contain the bugfixes from 3.5.2 ?

[HellDiverUK]

I'm lost with all the changes.  Is the getwork proxy available on RaspberryPi?

Due to OpenWRT not supporting the BlueFuzzies, I'm moving over to RPi - really don't want to be running a PC just to run a pair of Blues...

[Mudbankkeith]

Hi Luke-Jr

BFGMiner3.6.0 is now up and running with my erupters.

I have noticed the 5 Second average is now swinging through extremes like 10Gh to 35Gh

The "all time average" is still the same as before and the "pool corrected" figure is ok

Would it be an advantage for the future to change to maybe 10 second average, or is this 5 second figure needed?

[Shammasterb]

Hi Luke
I start 3.1.4 and it just hang there, check all port and software no problem there, what should I check next?

[HellDiverUK]

what should I check next?

How to upgrade to a recent version?

[Luke-Jr]

does 3.6 contain the bugfixes from 3.5.2 ?

Yes.

I'm lost with all the changes.  Is the getwork proxy available on RaspberryPi?

If you compile it...

Due to OpenWRT not supporting the BlueFuzzies, I'm moving over to RPi - really don't want to be running a PC just to run a pair of Blues...

The endian issues with the BigPictureMining driver should be fixed in 3.5.2+ - do you still have problems on OpenWrt?

[HellDiverUK]

Due to OpenWRT not supporting the BlueFuzzies, I'm moving over to RPi - really don't want to be running a PC just to run a pair of Blues...

The endian issues with the BigPictureMining driver should be fixed in 3.5.2+ - do you still have problems on OpenWrt?

I didn't try it with 3.6.0 - I'll try it later and see how it goes.

Edit: 3.5.2 is showing as the latest on OpenWRT...

[HellDiverUK]

Initial testing on 3.5.2 on OpenWRT is still showing 100% errors.

Set source manually to src/gz bfgminer http://luke.dashjr.org/programs/bitcoin/files/bfgminer/3.6.0/openwrt/12.09/ar71xx - it's still showing 3.5.2 as latest...

[Luke-Jr]

Edit: 3.5.2 is showing as the latest on OpenWRT...

I forgot to update the OpenWrt README... For 3.6, you'll need to change "testing" to "latest"

We now have 3 stages: stable, testing, and latest.

Stable (currently 3.0.x) is "no outstanding regressions from previous release, and probably any bugs found will also affect previous versions too".
Testing (currently 3.5.x) is "only applying bugfixes to make this the next stable"
Latest (currently 3.6.x) is "new code in the works; lolmaybeithascrashing"

That said, 3.5.2 should have had the bigpic fixes too... :/

Set source manually to src/gz bfgminer http://luke.dashjr.org/programs/bitcoin/files/bfgminer/3.6.0/openwrt/12.09/ar71xx - it's still showing 3.5.2 as latest...

Did you opkg update?

[HellDiverUK]

OK, got 3.6.0 on.  Had to do it manually, rather than via LuCI.  

Still showing 100% errors.  

Edit: Did you get around the hidapi thing then?

[Shammasterb]

what should I check next?

How to upgrade to a recent version?

Good one Helldiver
But I just when back to 3.1.4 because that was the only one that worked I have 3.5.1 installed  Now they all just hang when I start them.

[HellDiverUK]

what should I check next?

How to upgrade to a recent version?

Good one Helldiver
But I just when back to 3.1.4 because that was the only one that worked I have 3.5.1 installed  Now they all just hang when I start them.

Have you tried clearing out your .conf file?  Any time BFG craps out like that on me, it's something broken in the bfgminer.conf...

[deadweasel]

what should I check next?

How to upgrade to a recent version?

Good one Helldiver
But I just when back to 3.1.4 because that was the only one that worked I have 3.5.1 installed  Now they all just hang when I start them.

Have you tried clearing out your .conf file?  Any time BFG craps out like that on me, it's something broken in the bfgminer.conf...

me too...   back up and remove that .conf

[Shammasterb]

what should I check next?

How to upgrade to a recent version?

Good one Helldiver
But I just when back to 3.1.4 because that was the only one that worked I have 3.5.1 installed  Now they all just hang when I start them.

Have you tried clearing out your .conf file?  Any time BFG craps out like that on me, it's something broken in the bfgminer.conf...

me too...   back up and remove that .conf

I removed it yesterday, deleted everything on this computer and restalled everything about 2 hours ago and it still doing the same thing.  I did everything that I could think of also read through most of the thread bitcointalk.