OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[RusellPower]

Moved to Raspbian, applied the patch, waiting to see if it works... 

[1713890944]

1713890944

[yelloyello]

Nice this thread but......

I have 3 KNC Jupiters (april 2014) and I want to update cgminer.
I am familiar with putty.

But, how to upgrade the cgminer?  apt-get install does not work.

anyone ??

[Buchi-88]

New release - version 4.3.2, 2nd May 2014


Human readable changelog:

- There's a workaround in this version to minimise the risk of the man-in-the-middle attack of redirecting you to a different pool you don't want to be hashing on. Stratum reconnect will only honour the request if the reconnect is to a server with the same domain name.
- Fix for some overflow errors on stats with massive hashrates/shares.
- Fix a major memory leak which mostly affected hashfast users.
- Fix for a failed connection after a redirection that would then never return.
- Devices with unique serial numbers of 4 or more characters will now be displayed by their serial number in the status bar.
- Support for new firmware for OneStringMiners that will identify themselves as OSM devices.
- Support for OSM debugging and LED modes.
- A1 driver updates.


Full changelog:

- Make reconnection messages more explanatory
- Fix accounting bug with nrolltime drivers
- upgrade some int to int64_t to avoid overflows in reporting
- Stratum client.reconnect require matching URL
- Fix memory leak in submit_noffset_nonce
- Clean up any work that may not have been used in the work scheduler
- Avoid unnecessary deref now that it's done within discard_work
- Clean work pointers after one way usage functions
- Avoid unnecessary total_work_inc in generating local work
- Cosmetic fixes
- Fix idle bug, when redirected client can't auth
- Rename spond temp rate to asics total rate
- Build fixes
- Set the unique id only for usb devices with serial strings longer than 4 chars
long
- Use usb serial strings as unique id if devices have them
- Discretely identify the onestring miners as OSM
- Add bxf debugging option and osm led modes
- A1: modularize board selector / add initial CCR support
- A1: cleanup tca9535 logging
- A1: fix and extend PLL parameters
- A1: clean up compile warnings
- A1: use real level in hexdump
- Add identification for onestring miner variants
- Avalon2: Parser the power good signal
- driver-avalon2: this functions used on detect, which don't have thr setup yet

Hello, after the update i have follow problem:

USB management [P]ool management Settings [D]isplay options [Q]uit
 0: ANU 0       :                         | 23.36M / 1.488Gh/s WU:20.9/m
 1: ANU 1       :                         | 402.6M / 1.521Gh/s WU:20.2/m
--------------------------------------------------------------------------------
 [2014-05-03 20:21:46] ANU0: Comms error (werr=0 amt=0)
 [2014-05-03 20:22:05] ANU1: Comms error (werr=0 amt=0)
 [2014-05-03 20:22:21] ANU0: Comms error (werr=0 amt=0)
 [2014-05-03 20:22:33] Shutdown signal received.

Is this a Bug or I have a problem with my HUB?

greets

[kano]

...
Hello, after the update i have follow problem:

USB management [P]ool management Settings [D]isplay options [Q]uit
 0: ANU 0       :                         | 23.36M / 1.488Gh/s WU:20.9/m
 1: ANU 1       :                         | 402.6M / 1.521Gh/s WU:20.2/m
--------------------------------------------------------------------------------
 [2014-05-03 20:21:46] ANU0: Comms error (werr=0 amt=0)
 [2014-05-03 20:22:05] ANU1: Comms error (werr=0 amt=0)
 [2014-05-03 20:22:21] ANU0: Comms error (werr=0 amt=0)
 [2014-05-03 20:22:33] Shutdown signal received.

Is this a Bug or I have a problem with my HUB?

greets

... smaller quotes thanks ...

Anyway, there are no changes to the Icarus driver.

Probable causes are:
1) Overheating - although it's getting colder here, it's getting hotter in the northern hemisphere - these things have no temperature sensors - they are stupid
2) Power, as usual, if your hub isn't providing enough or it's plug pack is now over heating. 2000mA seems to be needed for 2xANU
3) General hardware problems as you suggested

[kano]

Updated AntS1 cgminer binary to 4.3.2a
The binary and README are in my cgminer-binaries git here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1  <-- Follow this link to get the new binary

Read the README on the screen there for how to replace the /usr/bin/cgminer binary in your AntS1 with the new one.

Thus it includes a client.reconnect patch:
"minimise the risk of the man-in-the-middle attack of redirecting you to a different pool"

This, as usual, includes the cgminer patch for the luci web display.

There's info in the README to update the luci code if LSTime is showing incorrectly after the update
(most newer AntS1's)

I've also documented steps to update the cgminer-monitor to restart cgminer if Elapsed Time is greater than 4 weeks.
This usually means the clock has messed up on the AntS1.
If you do mine for 4 weeks non-stop, it's simply a cgminer restart so no problem.

My source for this version is here:
https://github.com/kanoi/cgminer/tree/ants1-4.3.2a-85fcf0c

This binary includes all cgminer changes up to 4.3.2 and forward after that up to:
https://github.com/ckolivas/cgminer/commit/686d648f15d6c70f252c411242ecd7edc7294f90

[Raptor2213]

Updated AntS1 cgminer binary to 4.3.2a
The binary and README are in my cgminer-binaries git here:
https://github.com/kanoi/cgminer-binaries/tree/master/AntS1  <-- Follow this link to get the new binary

Read the README on the screen there for how to replace the /usr/bin/cgminer binary in your AntS1 with the new one.

Thus it includes a client.reconnect patch:
"minimise the risk of the man-in-the-middle attack of redirecting you to a different pool"

This, as usual, includes the cgminer patch for the luci web display.

There's info in the README to update the luci code if LSTime is showing incorrectly after the update
(most newer AntS1's)

I've also documented steps to update the cgminer-monitor to restart cgminer if Elapsed Time is greater than 4 weeks.
This usually means the clock has messed up on the AntS1.
If you do mine for 4 weeks non-stop, it's simply a cgminer restart so no problem.

My source for this version is here:
https://github.com/kanoi/cgminer/tree/ants1-4.3.2a-85fcf0c

This binary includes all cgminer changes up to 4.3.2 and forward after that up to:
https://github.com/ckolivas/cgminer/commit/686d648f15d6c70f252c411242ecd7edc7294f90

Good to know, now I need to downgrade to 4.2.2a.  I use a service that uses the client.redirect 'feature' to redirect to other pools.  I don't suppose there's a command-line option to disable this?

[kano]

...
Good to know, now I need to downgrade to 4.2.2a.  I use a service that uses the client.redirect 'feature' to redirect to other pools.  I don't suppose there's a command-line option to disable this?

You do realise that only the pool you are mining to can send a client.reconnect right?
(unless it's a network hack that allows them to steal your hashes)
So in the case of that 'service' they can only use reconnect once anyway.

[Raptor2213]

...
Good to know, now I need to downgrade to 4.2.2a.  I use a service that uses the client.redirect 'feature' to redirect to other pools.  I don't suppose there's a command-line option to disable this?

You do realise that only the pool you are mining to can send a client.reconnect right?
(unless it's a network hack that allows them to steal your hashes)
So in the case of that 'service' they can only use reconnect once anyway.

This site is designed to function in place of normal failover (for CUDAminers) as well as to allow you to sell your hashes to other users.  It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several.

[kano]

...
Good to know, now I need to downgrade to 4.2.2a.  I use a service that uses the client.redirect 'feature' to redirect to other pools.  I don't suppose there's a command-line option to disable this?

You do realise that only the pool you are mining to can send a client.reconnect right?
(unless it's a network hack that allows them to steal your hashes)
So in the case of that 'service' they can only use reconnect once anyway.

This site is designed to function in place of normal failover (for CUDAminers) as well as to allow you to sell your hashes to other users.  It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several.

You can't reconnect a connection with client.reconnect unless you are the pool you are mining to, in any stratum implementation.

(Edit: or any version of cgminer)

[kano]

...
Good to know, now I need to downgrade to 4.2.2a.  I use a service that uses the client.redirect 'feature' to redirect to other pools.  I don't suppose there's a command-line option to disable this?

You do realise that only the pool you are mining to can send a client.reconnect right?
(unless it's a network hack that allows them to steal your hashes)
So in the case of that 'service' they can only use reconnect once anyway.

This site is designed to function in place of normal failover (for CUDAminers) as well as to allow you to sell your hashes to other users.  It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several.

Let me rephrase that

What is sending several client.reconnects?

You see, as I said above, it's not possible with stratum.
Only the pool (or a network hack) can send a client.reconnect

The cgminer change simply stops a hack intercept from redirecting mining away from the pool's domain - which will not affect any pool since no pool would want to send mining to a domain different to their own unless they had multiple domains, but they can resolve that by simply creating a DNS record with the same domain and use that in the client.reconnect request.

Now the reason why I've posted again, is that this makes http://www.miningrigrentals.com/ VERY suspect in this recent issue.
I'd actually suggest people to avoid them until someone clears up your statement with proof that they are NOT using a network hack to redirect your miner ... since:

It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several.

isn't normally possible with stratum.

[Buchi-88]

...
Hello, after the update i have follow problem:

USB management [P]ool management Settings [D]isplay options [Q]uit
 0: ANU 0       :                         | 23.36M / 1.488Gh/s WU:20.9/m
 1: ANU 1       :                         | 402.6M / 1.521Gh/s WU:20.2/m
--------------------------------------------------------------------------------
 [2014-05-03 20:21:46] ANU0: Comms error (werr=0 amt=0)
 [2014-05-03 20:22:05] ANU1: Comms error (werr=0 amt=0)
 [2014-05-03 20:22:21] ANU0: Comms error (werr=0 amt=0)
 [2014-05-03 20:22:33] Shutdown signal received.

Is this a Bug or I have a problem with my HUB?

greets

... smaller quotes thanks ...

Anyway, there are no changes to the Icarus driver.

Probable causes are:
1) Overheating - although it's getting colder here, it's getting hotter in the northern hemisphere - these things have no temperature sensors - they are stupid
2) Power, as usual, if your hub isn't providing enough or it's plug pack is now over heating. 2000mA seems to be needed for 2xANU
3) General hardware problems as you suggested

THX for your answer, but after a RPI Update it looks good...

Code:

 cgminer version 4.3.2 - Started: [2014-05-04 08:58:13]
--------------------------------------------------------------------------------
 (5s):11.12G (1m):10.68G (5m):6.666G (15m):2.967G (avg):10.62Gh/s
 A:580  R:0  HW:17  WU:137.3/m
 Connected to mint.bitminter.com diff 4 with stratum as user xxx
 Block: 70af9ebb...  Diff:8G  Started: [08:58:13]  Best share: 1.1K
--------------------------------------------------------------------------------
 USB management Pool management Settings Display options Quit
 0: ANU 0       :                         | 1.792G / 1.777Gh/s WU:20.6/m
 1: ANU 1       :                         | 1.799G / 1.783Gh/s WU:21.8/m
 2: ANU 2       :                         | 1.869G / 1.775Gh/s WU:25.2/m
 3: ANU 3       :                         | 1.798G / 1.785Gh/s WU:25.8/m
 4: ANU 4       :                         | 1.785G / 1.791Gh/s WU:22.6/m
 5: ANU 5       :                         | 1.800G / 1.764Gh/s WU:22.2/m
--------------------------------------------------------------------------------

greets

[-ck]

New release: Version 4.3.3, 4th May 2014


Human readable changelog:

- Fox for a huge long-standing memory leak with the BXF driver which affected bi*fury, hex*fury and OneString miners.
- Formatting fixes for miner.php


Full changelog:

- Fix typo
- Work should be freed when aged, fixing a massive memory leak for bxf devices
- miner.php fix single rig summary/config field formatting
- miner.php fix single rig total formatting

[simpic]

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

Code:

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 : [<c00eabd4>] lr : [<c00eabb8>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 
[<c0013428>] (unwind_backtrace+Ox0/0xec) from [<c00112d0>] (show_stack+0x10/0x14) [<c00112d0] (show_stack+Ox10/0x14) from [<c007fbfc>] (kdb_dumpregs+0x28/0x50) [<c007fbfc>] (kdb_dumpregs+0x28/0x50) from [<c0082cfc>] (kdb_main_loop+Ox370/0x6bc) [<c0082cfc>] (kdb_main_loop+Ox370/0x6bc) from [<c00854c8>] (kdb_stub+0x164/0x380) more> =03-07 17:42:49] Accepted 113371b7 Diff 15/12 BXF 1

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.

I had the same problem and i tried to change:
- SD card
- Raspbian version
- cgminer version
- power supply
but nothing changed.

I finally solved adding

Code:

slub_debug=FPUZ

to /boot/cmdline.txt


More info here: https://github.com/raspberrypi/linux/issues/372

[Raptor2213]

...
Good to know, now I need to downgrade to 4.2.2a.  I use a service that uses the client.redirect 'feature' to redirect to other pools.  I don't suppose there's a command-line option to disable this?

You do realise that only the pool you are mining to can send a client.reconnect right?
(unless it's a network hack that allows them to steal your hashes)
So in the case of that 'service' they can only use reconnect once anyway.

This site is designed to function in place of normal failover (for CUDAminers) as well as to allow you to sell your hashes to other users.  It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several.

Let me rephrase that

What is sending several client.reconnects?

You see, as I said above, it's not possible with stratum.
Only the pool (or a network hack) can send a client.reconnect

The cgminer change simply stops a hack intercept from redirecting mining away from the pool's domain - which will not affect any pool since no pool would want to send mining to a domain different to their own unless they had multiple domains, but they can resolve that by simply creating a DNS record with the same domain and use that in the client.reconnect request.

Now the reason why I've posted again, is that this makes http://www.miningrigrentals.com/ VERY suspect in this recent issue.
I'd actually suggest people to avoid them until someone clears up your statement with proof that they are NOT using a network hack to redirect your miner ... since:

It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several.

isn't normally possible with stratum.

To quote their support team:

Some of the newest miners have a "Do not allow reconnect" "fix." It's not really a fix it's just built without reconnect enabled. That will not work on our system since we have to send reconnect requests to get your rig to bounce to the chosen pool.

How it works is that you set up a worker in their service.  This worker redirects to up to 5 backup pools (for failover).  The service then redirects your hashing to either those pools, or, if your miner is rented, to your renter (who also can have 5 pools specified).  I've been testing them for a few weeks now with no issues.

[merc82]

...
Good to know, now I need to downgrade to 4.2.2a.  I use a service that uses the client.redirect 'feature' to redirect to other pools.  I don't suppose there's a command-line option to disable this?

You do realise that only the pool you are mining to can send a client.reconnect right?
(unless it's a network hack that allows them to steal your hashes)
So in the case of that 'service' they can only use reconnect once anyway.

This site is designed to function in place of normal failover (for CUDAminers) as well as to allow you to sell your hashes to other users.  It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several.

Let me rephrase that

What is sending several client.reconnects?

You see, as I said above, it's not possible with stratum.
Only the pool (or a network hack) can send a client.reconnect

The cgminer change simply stops a hack intercept from redirecting mining away from the pool's domain - which will not affect any pool since no pool would want to send mining to a domain different to their own unless they had multiple domains, but they can resolve that by simply creating a DNS record with the same domain and use that in the client.reconnect request.

Now the reason why I've posted again, is that this makes http://www.miningrigrentals.com/ VERY suspect in this recent issue.
I'd actually suggest people to avoid them until someone clears up your statement with proof that they are NOT using a network hack to redirect your miner ... since:

It uses client.reconnect requests as part of the pool-swapping feature, and it could, potentially, send several.

isn't normally possible with stratum.

To quote their support team:

Some of the newest miners have a "Do not allow reconnect" "fix." It's not really a fix it's just built without reconnect enabled. That will not work on our system since we have to send reconnect requests to get your rig to bounce to the chosen pool.

How it works is that you set up a worker in their service.  This worker redirects to up to 5 backup pools (for failover).  The service then redirects your hashing to either those pools, or, if your miner is rented, to your renter (who also can have 5 pools specified).  I've been testing them for a few weeks now with no issues.

To clarify how our system at miningrigrentals.com works -- when you connect to our system initially, you are issued a client.reconnect that redirects you to your own dedicated port. This is what is required to allow our service to control what pool your miner is pointing at. After the initial connection, no further reconnects are sent.

Thanks

[-ck]

To clarify how our system at miningrigrentals.com works -- when you connect to our system initially, you are issued a client.reconnect that redirects you to your own dedicated port. This is what is required to allow our service to control what pool your miner is pointing at. After the initial connection, no further reconnects are sent.

In that case then, if you are redirected to a different port on the same domain it should work fine even with the security redirect limiter in place.

[Askit2]

I am mining using a Raspberry Pi with cgminer and it hangs after a little while or few hours.

I did read on some pages over the internet that this is due to a "memory paging issue". I don't know what this is and if or it's the correct reason.

Can someone help me with this issue?

PS: I am running Arch Linux on my RPi

Here you go: http://projectklondike.org/how-to-run#rpi-freeze

Make sure you're adding this option as described to the existing line, it should look like this:



Good luck!

I am not absolutely sure that is a fix for ARCH Linux. The fix you posted is to fix a long standing Raspbian problem. Now I can't say it won't fix it. I can say that mine doesn't exhibit this behavior with ARCH.

Best of luck to the person with the problem and I hope they find a solution.

EDIT: If you are running out of memory try the newest version maybe a memory leak is causing you grief with the limited RAM.

Not 100% sure but Raspbian and Arch using the same Raspberry Firmware/Kernel as far as I understood. I've seen the same behavior on Arch (at least with 3.6.11 up to 3.10.?) and the hint above solved all issues with my 'freezing' Raspberry (in fact it's alive, but USB including the network port is gone). Most likely you'll never see the behavior as long as the number of connected USB devices is fairly low. With let's say 10 or 15+ you will notice issues sooner or later. At least from my experience.

Anyway, it's worth a try and of course the latest cgminer is always the best.

I think I was only running 16 on mine. That having been said, I didn't say not to try it. I did say that I wasn't sure it was a fix for ARCH. I had Raspbian for a long time. I got a ton of crashing from it. All related to the usb/Ethernet/mmc being on one controller I think it was. I added the code in question. I spent weeks trying to fix it as I loved being able to use the GUI directly. I had 0 luck keeping Raspian. I would say that when I "upgraded" to ARCH it stopped being a problem. Right now I only have 8 devices per rPi. The peak was 24 devices but some I don't believe ever ran on the pi.

I was under the impression that how the OS handled the everything being USB was better on ARCH. I was unaware that apparently the change with how the system handles devices was kernel independent. I suppose one of us was told something incorrectly. That or there are more differences between the two then just one shipping with a GUI and one being more svelte. One uses apt-get and one uses pacman.

P.S. Mine says this but I'm not positive it didn't mean Raspbian.....

Code:

Linux cgminerPi1 3.10.29-2-ARCH #1 PREEMPT Mon Feb 10 04:04:41 MST 2014 armv6l GNU/Linux

Huh well Raspbian and ARCH list 3.10 firmware. I wonder why there would be no kernel change between distributions. I don't know myself so I wonder. I can't seem to find anything specific. If you know something I am missing (I don't use Linux as much as I likely should) I would love to know. Maybe everyone builds from the same source. I don't think so but maybe. If so I suppose it was magic that my 30 minute to 2 hour delay between lockups went away with arch rather then up to date Raspbian.

EDIT:
I should have looked back. My kernel panic was driver related for Ethernet I believe it was. It would make no difference what system except ARCH was more stable at the time. No idea about now. I also apparently ran 17 Asic devices at a time on raspberry pi.

Thank You for letting me know the kernel code is likely nearly identical between them. I hadn't realized. I wonder then why I haven't had more problems.

[freebit13]

Updated AntS1 cgminer binary to 4.3.2a
The binary and README are in my cgminer-binaries git here:
[snip, snip]

Thanks so much for the S1 update Kano, I have it installed and working. Now you just need to get Bitmain to send you a S2, so that you can patch that one too 

A shortcut to avoid waiting up to 3 mins for cgminer to restart after clicking "Save&Apply" in the GUI, is to click "Save&Apply" a second time, that'll start it up right away.

A tip for those on Windoze like me: to avoid typing those long commands; you can just copy the line from your browser and right click in the putty window to paste it in and press enter 

[techman05]

is there a 4.3.3 update for the s1 yet. I haven't seen an official post yet here so I'm on the fence waiting. Miningrigrentals.com says 4.3.2a blocks redirect so I may have problems with them. Only other grief I have with them is pools don't rotate off bad pool (pool not giving share that are possibly dead)[I think]. I accidentally overwhelmed a pool [I think] and it didn't bump me somewhere else.

Anyone that wants to play here is my referral address http://www.miningrigrentals.com/register?ref=563

[-ck]

is there a 4.3.3 update for the s1 yet.

4.3.3 only has driver changes for unrelated hardware so there is no reason to update S1s from 4.3.2 to 4.3.3