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

[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

[techman05]

I was under the impression from them that a fix was in order so I hoped 4.3.3 was that. They said 4.2.3a did not have redirect and that would cause problems switching around (check their twitter page for my communication with them). I'm hoping redirect will work so I can use this new product without annoying myself or others if someone rents time on my machines.

[kano]

...
Miningrigrentals.com says 4.3.2a blocks redirect so I may have problems with them.
...

How they are redirecting is the cause of their problems.

It really makes no sense at all to even allow a redirect to a different pool.
The logic behind blocking it is quite sound.

If a 'pool' wishes to distribute hashes around the net, then they need to do one of 2 things:
1) run proxies and thus they will control the distribution as required
2) use the API access to handle pool management

Hacks to redirect to another pool on startup using a fake pool, or redirecting using the stratum network hack are just that: hacks.
They need to develop their pool properly, not by quick hacks that require removing security fixes in cgminer.

[Raptor2213]

...
Miningrigrentals.com says 4.3.2a blocks redirect so I may have problems with them.
...

How they are redirecting is the cause of their problems.

It really makes no sense at all to even allow a redirect to a different pool.
The logic behind blocking it is quite sound.

If a 'pool' wishes to distribute hashes around the net, then they need to do one of 2 things:
1) run proxies and thus they will control the distribution as required
2) use the API access to handle pool management

Hacks to redirect to another pool on startup using a fake pool, or redirecting using the stratum network hack are just that: hacks.
They need to develop their pool properly, not by quick hacks that require removing security fixes in cgminer.

They replied a couple posts up stating that there's just one redirect.
https://bitcointalk.org/index.php?topic=28402.msg6541935#msg6541935

[techman05]

They might have but I can see it happen more than once if I don't blink when I change pools on their page. At one point I saw a pool switched to pool y but the speed it's done I know it's done for each pool swap . That's probably why they warn you of 2 minutes to swap out to new pool before thinking somethings wrong.

[kano]

...
Miningrigrentals.com says 4.3.2a blocks redirect so I may have problems with them.
...

How they are redirecting is the cause of their problems.

It really makes no sense at all to even allow a redirect to a different pool.
The logic behind blocking it is quite sound.

If a 'pool' wishes to distribute hashes around the net, then they need to do one of 2 things:
1) run proxies and thus they will control the distribution as required
2) use the API access to handle pool management

Hacks to redirect to another pool on startup using a fake pool, or redirecting using the stratum network hack are just that: hacks.
They need to develop their pool properly, not by quick hacks that require removing security fixes in cgminer.

They replied a couple posts up stating that there's just one redirect.
https://bitcointalk.org/index.php?topic=28402.msg6541935#msg6541935

Note the bolded text.

[techman05]

Well I hope they take your words. I'm sure they're are more doing this but it's a cool feature I want. It's almost like keeping up without having to choose a coin if you get on the rentable list.

The coins I want have halved so far they are a b - word to get anything out of them.