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

hi,
how can i update the cgminer version from a antminer s1? Normally the software is deployed with a new firmware.

thanks

Ckolivias, when you get a chance could you check your windows cross compile text file to see if there is something not listed I need to do. When I run it through as written I get a cannot find version of curl needed and when I point it to where curl is in the win deps folder it then says compiler doesn't work.

Also maybe if your using mxe cross compiler add some details to how to use that. There's a tutorial for it but I'm not sure where the intended program to compiles goes and if the win deps folder can be used or have to copy all of that into a specific folder.

Thanks ahead of time.

Unofficial Mac binaries have been updated for v4.1.0, and are available here.

These are precompiled universal binaries that support Mac OS X 10.5.8 through 10.9+.

Awesome, thanks! I'll give it a try with 4.1.0.

Like I said, I'm a newb at compilation.  I was going by the instructions in the two linked guides.  I noted that in the README file, you have:

CFLAGS="-O2 -Wall -march=native" ./configure ...

But I honestly don't know what the various CFLAGS values do.  Hence I figured it's safer to go with what others have confirmed works on a Pi, at least until I learn more about the flags.

autogen is only rarely required with a significant git update so you can skip that and do CFLAGS="-g -W -Wall -O2" ./configure --enable-icarus --enable-klondike
I note you're not adding any optimisation flags like O2 but you probably should unless you're debugging a real issue.

Quick question about compiling cgminer, please.  I tweak a few of the constants in the Klondike driver for use with my devices, and I recompile every couple of days, trying different things.  Since I'm using an RPi, compiling takes about 30-45 minutes total. Right now, I use a small shell script with the following lines, based on a combination of advice from Kano's blog post and a troubleshooting guide I use for Klondikes:


Obviously, this takes a while to run. How much of this has to be rerun every time I tweak the code, and how much of it only needs to be run once?

Thanks.

New version: 4.1.0, 8th March 2014

A stable and bugfix release with new drivers. I recommend all 4.x users update.

Human readable changelog:

- Zero stats will now show the correct average hashrate per device.
- Fixed the high CPU usage which led to eventually slowing down of hashrates over time.
- Respect the -Q value by slightly changing its meaning to be the highest value it can reach, defaulting to 9999. Regular users need not do anything with this value.
- Fixed the hex32 api values (currently only hashfast serial number) returning invalid JSON over the API.
- New driver - BXM for an upcoming two bitfury chip USB stick courtesy of Goodney, along with an overclocking option with --bxm-bits
- New driver - merged the bitmain S1 driver
- Try harder to shut cgminer down fully on quit/restart/--shares end.
- Fix cgminer shutting down and hanging when a grossly invalid stratum message is received.
- Fix cointerra hashrate display to show a share based hashrate so that the displayed hashrate should match the pool hashrate.
- Hashfast improvements:
. Dramatic decrease in CPU usage for all existing firmwares since they don't internally nroll time.
. Latest version now works with older 0.2 firmwares
. Only decrease the clockspeed if a device fails in less than an hour at its current clockspeed
. New feature allows per-device settings:
- Other low level bugfixes and improvements and anticipatory changes.


Full changelog:

- Correct fix for dev start time being adjusted for stat zeroing.
- Make per device stats work for average after a stat zeroing.
- Add an hfa-options command line that allows the clockspeed to be chosen per
device by name comma separated, with a function that can be expanded with more
options in the future.
- Off by one drv_rolllimit check against jobs
- Free the work that may be lost, leaking memory, in a failed hfa_send_frame
- Roll the ntime for work within the hfa driver for firmware we know doesn't do
it internally as an optimisation.
- Export the roll_work function to be usable by driver code and make it
compatible with rolling stratum work.
- Make opt_queue be respected as a maximum value for staged items.
- Disable mistakenly enabled lock tracking.
- api version update for HEX32
- api.c - HEX32 type needs quotes
- Disable the MAX_CLOCK_DIFF check for newer hashfast firmwares since it's not
required.
- Store the hardware and firmware revision in the info struct for easy use in
the hfa driver.
- Only decrease the hfa clock rate if the device has been running for less than
an hour before dying.
- Change lack of op name response message in hfa driver
- Check for lost devices at every write/read in hfa_detect_common
- Make bxm bits configurable.
- Move avalon2 options to ~alphabetic position in help.
- Do a shutdown routine on bxm close.
- Provide support for 2 chips in libbitfury sendhashdata and enable the 2nd chip
on BXM devices.
- Remove unnecessary opayload and newbuf members of bitfury info struct.
- Add an spi add fasync command.
- Cope with older hfa firmware not even responding to op_name.
- Forcibly kill everything silently with an exit code of 1 should we fail to
cleanly shut down and use a completion timeout for the __kill_work in
app_restart.
- Make __kill_work itself also be a completion timeout.
- Generalise more of libbitfury for more reuse in both nf1 and bxm drivers.
- Remove redundant init components of bxm driver.
- Set default osc6 bits on bxm to 50
- Enable the transaction translator emulator for bxm devices and use a dummy spi
tx the size of a normal payload.
- Store usb11 and tt flags as booleans in cgusbdev allowing them to be
discretely enabled as well as detected by the device data.
- Add bxm scan function and check spi txrx returns only as much as sent.
- Add init sequence to bxm detect one.
- Add a bxm specific txrx function for spi transfers.
- Add bxm close to bitfury shutdown switch.
- Add reset/purge/cshigh/low sequence to bxm init
- Add bitmode init to bxm open sequence.
- Add initial bxm opening sequence for detect one.
- Add identifiers for bxm bitfury devices.
- Clean up parse_method
- More gracefully break out of parse_notify on a corrupted hex string error,
checking the return value of all hex2bin conversions and being consistent with
using stack memory. Fix an unlocking error in cases of failure.
- AntS1 - add detection information to usbutils
- Enable Bitmain Ant S1 code and make it conform to cgminer requirements
- Make the cointerra displayed hashrate based on valid share generation.
- Convert and update values shown in the cointerra api output.
- Export the api_add_int16 function.
- Use a custom mystrstr function in cointerra driver.
- Add api_add_int16 to API functions.
- Add support for Bitmain Multi Chain and Single Chain and optimize the
efficiency
- Add support for bitmain devices
- Perfect function of BitMain Multi Chain
- Add support for Bitmain Multi Chain and Single Chain and optimize the
efficiency
- Add support for bitmain devices

That fixed it, thanks.  After disabling LOCK_TRACKING 4.0.1 is now running at a very steady 11% on my system, which is actually a nice improvement over 3.9.   

Looks like it's most likely a problem with the SD card
Get a new one and ensure you are using latest cgminer.

You're trying to mine with a toy on a shit pool.  There's your two errors.

That is a linux kernel, aka operating system, crash message unrelated to the cgminer code but mixed in with the cgminer output. Only an operating system upgrade/downgrade/kernel package fix can make it better.

Anyone knows what causes this error, running raspberry pi with newest version of cgminer, and mining with bi*fury's


cgminer version 4.0.1 - Started: [2014-03-07 13:45:35]
(5s):10.43G (avg):10.29Gh/s I A:35532 R:84 HW:1 WU:145.7/m ST: 59 SS: 0 MB: 27 LW: 113898 GF: 0 RF: 0
Connected to uk1.ghash.io diff 12 with stratum as user
Block: 44170d05... Diff:3.81G Started: [17:40:01] Best share: 26.4X
[USB device management [P]ool management [Settings [D]isplay options [Q]uit

0: BXF 0: 41.5C I 5.299G/5.245Gh/s I A:18084 R:36 HW:0 WU:74.0/m
1: BXF 1: 38.4C I 5.130[14433.599787] Unable to handle kernel paging request at uirtual address 20626f6a
[14433.608374] pgd = d9e58000
[14433.611216] [20626f6a] *pgd=000000007 Diff 15/12 BXF 1
[14433.615990] Internal error: Dops: 5 [111] PREEMPT ARM 1
[2014-03-07 17:41:22] Accepted 08cd5d8a Diff 29/12 BXF 1
Entering kdb (current=0xd9e68000, pid 233) Oops: (null) 0
due to pops @ Oxc00eabd4ccepted Obf0c68e Diff 21/12 BXF 1
[2014-03-07 17:41:32] Accepted 12c87979 Diff 14/12 BXF 0
2dCPU: 0 PID: 233 Comm: wicd-monitor Not tainted 3.10.32-1-ARCH #1
Eldtask: d9e68000 ti: d9dce000 task.ti: d9dce0004/12 BXF 1
PC is at kmalloc_track_caller+Ox6c/OxlcOiff 14/12 BXF 1
LR is at kmalloctrack_ca11er+Ox50/0x1c0iff 20/12 BXF 1
pc : [] lr : [1 psr: 20000013 1
sp : d9dcfc80 ip : 00069c9b fp : 00053b7cff 29/12 BXF 1
r10: d9dce000 r9 : cO4de2c8 r8 : d9dce000ff 12/12 BXF 1
r7 : 00000140 r6 : 000106d0 r5 : 20626f6a r4 : da801c00
r3 : 00000000 r2 : 00000001 rl : 000106d0 1.0 : 00000000
Flags: nzCu IRQs on Figs on Mode SVC_32 ISA ARM Segment user
Control: 00c5387d Table: 19e58008 DAC: 00000015/12 BXF 1
dCPU: 0 ND: 233 Comm: wicd-monitor Not tainted 3.10.32-1-ARCH #1
[] (unwind_backtrace+Ox0/0xec) from [] (show_stack+0x10/0x14) [] (kdb_dumpregs+0x28/0x50) [] (kdb_dumpregs+0x28/0x50) from [] (kdb_main_loop+Ox370/0x6bc) [] (kdb_main_loop+Ox370/0x6bc) from [] (kdb_stub+0x164/0x380) more> =03-07 17:42:49] Accepted 113371b7 Diff 15/12 BXF 1
[2014-03-07 17:42:50] Accepted Oed5e5c0 Diff 17/12 BXF 1
[2014-03-07 17:42:57] Accepted Ocl2f819 Diff 21/12 BXF 0

Picture for better text. http://i.imgur.com/8muciXP.jpg

For sure that will reduce overall cpu usage with 20-30% that is what i observe on my tplinks

Crap, good pickup. I must have enabled it by mistake during debugging and it ended up in one of my commits.

Probably CPU increase is due to define LOCK_TRACKING 1
Or at least disabling it is reducing CPU usage for me
In 3.8-3.9 it was disabled if i remember correctly


@@ -690,7 +711,7 @@
  * So, e.g. use it to track down a deadlock - after a reproducable deadlock occurs
  * ... Of course if the API code itself deadlocks, it wont help
  */
-#define LOCK_TRACKING 1
+#define LOCK_TRACKING 0

Yes that's almost certainly the queue increasing in size automatically, which I will likely remove next version.

I wanted to post the same observation.  I've been upgrading every few releases and had been on 3.8-3.9 for a long time with a few BFL units.  In 3.9 the CPU usually averages around 15%-16%.  Going to 4.0.1 the CPU usage slowly increases and levels off at ~35%.

Ubuntu 12.04.4 x64, 3.11 kernel, gcc 4.6.3
CFLAGS="-O2 -Wall -march=native" ./configure --enable-bflsc

RPi, powered USB hub, ASIC USB thumb ... under $100 ?
Though it is a waste of time and money ... it costs more BTC than it will ever mine

cgminer 4.1.0 crashed....  (and i hoped not) after 7 hours... something with bxf1 usb-lib device is already in use.

I installed the debugger  and the debugger version (4.0.0 i hope that does not matter) and wait for the next crash...

Have a nice night

Im trying to get a mining rig for under $1000 is that possible?