luke-jr / bfgminer Goto Github PK

For some reason, some users will get an error unless they run BFGMiner with administrator privileges.

To help me fix this, please leave a comment with as much information as possible:

• Windows version
• GPU/OpenCL driver version(s)
• Are you able to run BFGMiner without administrator privileges, or does it crash?

...even when they're not

ModMiner/BFL users having trouble like to report the Icarus detect error too much. Make these DEBUG-level.

Be sure to document :)

Note: Windows only

Document, and consider pulling it to source tarball at make-release time

Status: Current draft in 9091f93

https://bitcointalk.org/index.php?topic=28402.msg1069959#msg1069959

With efficency-hashrate added, the top status line and OCL device lines (since they have intensity tacked on the end) overflow at about 10k shares.

Shouldn't force work restart until new work has been fetched

It's saved as -1 when there's no OpenCL, which is bad.

Build BFL on RPi, copied ~/.cgminer/cgminer.conf to ~/.bfgminer/bfgminer.conf.

When starting, bfgminer asks to enter at least 1 pool. cgminer.conf had several pools, and the conf file worker perfectly with cgminer 2.5.

Entered pool info on bfminer startup, wrote to config file. Opened config file to check for anything weird, all seemed normal. Restarted bfgminer, again it asked for a pool.

Probably it is flagging all shares based on work before a longpoll, which are not necessarily stale.

I suggest 2 different "levels" of "staleness":

1. the pool would rather we not work on this anymore
2. the pool will reject results from this as stale

Obviously level 2 is pool-dependent, so perhaps some new flag on longpoll responses is needed to determine "are shares on old works now invalid" ("submitold" can and is used to try to keep stale rate graphs accurate, but shouldn't inhibit level 2 stales)

After a long (how long?) time with commit 2d6375c (2012-08-01)

Very quickly on one startup of bfgminer-2.6.1 (2012-08-05):

Core was generated by `./bfgminer-43541e8a -c puppet.json -S icarus:/dev/ttyUSB1 -S icarus:/dev/ttyUSB'.
Program terminated with signal 11, Segmentation fault.
#0  0xf76e1714 in curl_easy_reset () from /usr/lib/libcurl.so.4
(gdb) bt
#0  0xf76e1714 in curl_easy_reset () from /usr/lib/libcurl.so.4
#1  0x0805deb7 in json_rpc_call (curl=0x0, url=0x80efce8 "http://api.bitcoin.cz:8332", 
    userpass=0x80fcc08 "luke-jr.FPGAs:x", 
    rpc_req=0x80d18e4 "{\"method\": \"getwork\", \"params\": [], \"id\":0}\r\n", probe=false, longpoll=false, 
    rolltime=0x81dc4a8, pool=0x80f0888, share=false) at util.c:449
#2  0x0804fbd0 in get_upstream_work (work=0x81dc360, curl=0x0) at miner.c:2111
#3  0x08050526 in get_work_thread (userdata=0xf0900740) at miner.c:2384
#4  0xf7719ed3 in start_thread () from /lib/libpthread.so.0
#5  0xf75823ee in clone () from /lib/libc.so.6

Core file: core.keepme_bfgminer-2.6.1_issue46

Building on Debian claims GPU monitoring support is enabled, but when BFGMiner starts, all GPU's show as OCL and no fan nor engine & memspeed readouts are shown.

[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
OCL 0: 299.7/317.8/246.7Mh/s | A:32 R:0 HW: 0 U: 3.45/m
OCL 1: 388.8/410.2/277.6Mh/s | A:36 R:0 HW: 0 U: 3.88/m

No error is shown when starting up using:

bfgminer --auto-fan --auto-gpu --temp-target 70 --gpu-engine 750-850,850-940 --gpu-memclock 300 --gpu-vddc 1.02,1.06 -I 9

Configuration Options Summary:

curses.TUI...........: FOUND: ncurses

OpenCL...............: Enabled
ADL................: SDK found, GPU monitoring support enabled
BitForce.FPGAs.......: Disabled
Icarus.FPGAs.........: Disabled
ModMiner.FPGAs.......: Disabled
Ztex.FPGAs...........: Enabled

CPU Mining...........: Disabled

Compilation............: make (or gmake)
CPPFLAGS.............:
CFLAGS...............: -O2 -Wall -march=native
LDFLAGS..............: -lpthread
LDADD................: -ldl -lcurl compat/jansson/libjansson.a -lpthread -lm -lusb-1.0

Installation...........: make install (as root if needed, with 'su' or 'sudo')
prefix...............: /usr/local

P4man thinks this would be useful for Puppet Master.

It should show 0 or a message instead.

On Windows, this manifests as a crash often in curl_maprintf.
On Linux, pthread_create fails and BFGMiner quits.

Original report from @jddebug:

bfgminer crashes after several hours on win xp with a mini rig. Only happens on the 19 card mini so far. Will add more as I learn more.

Possibly also affecting: eryngi and Bunnyh

Debug mode makes this obvious even iwth 1 bitforce

Last slash in program filename gets replaced with a space(?)

Not meeting the work target is not a hardware error, and must be treated differently.

Reproducible every time. When starting BFGMiner (or CGMiner) 1 random board out of cluster of 18 ztex 1.15x dies out within first 60 min of mining. Changing size of cluster doesn't seem to affect the problem ie. if started with 16 boards, 1 random board will die. Running on Raspberry Pi.

ZTX 13: 04A346****-1 | 204.00Mhz | DEAD / 36.0/ 27.5Mh/s | A: 28 R: 3 HW: 11 U: 0.38/m

WildeMagic has this problem, apparently only with a fake/alwaysdead pool as pool 0 (pool 1 is misdetected dead).

Bunnyh has this problem, on whatever pool he's using, whether it be 0 or 1.

Switching pool recovers temporarily.

Bisected to 411784a, fixed(?) by 9f811c5 which was later reverted in 53269a9

Assigned to kolivas

http://www.projectpluto.com/win32a.htm

AttachConsole can be used for --text-only or a new --stdio (if we can make it do either mode)

Consider pthread_setaffinity_np

Need more info from @wizkid057

Right now number parameters need to be specified as strings

Only getting under 800 MH/s in 2.5.0.

Should be able to upgrade from one release to the next without rebuilding configure and reconfiguring (unless the sources to those has a reason to change)

Some distros support installing multiple OpenCL implementations. It might be nice to load/use multiple.

Since ModMiner takes over a minute to program, it gets false-positive SICK label.

Eloipool uses this

At least with Console2

Once #5 is fixed and there are no more false-positives on stale shares, we can make this compromise.

Lots of weird/broken big endian stuff to address

This dependency was added by an updated libcurl-4.dll

It makes no sense to show this for GPU/FPGA-only miners. Perhaps remove it from the summary entirely since it's also the CPU devices' "kernel"?

Assigned to: kolivas