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

Yeah sorry - got side tracked last night testing new hardware
But there were no problems with the T1 with the latest code.
So it must be A1 specific or a hardware setup problem.
(run time >15 hrs)

Many thanks Kano - appreciate it.

My eclectic little miner collection (a Hex Fury, a couple of Jalapenos, a bunch of U1s and the problematic A1) will thank you!

 - r

I've got a T 1 (and an E 8 ) but not an A 1
Though that's my fault since they had some miners for me but I never went and got them (they don't live far from me)
I'm still running 4.2.2a on the T 1 coz that's on my RPi.
Building 4.3.3a now to see if there's any issues ... I'll update here once it's running (takes a while to build on an RPi)

Probably not but you should check on http://drillbitsystem.com/forum/index.php  . Ckolivias can only do so much for individual products and you'll get a better response there.

Having problems getting my Drillbit Avalon Thumb Gen2 to hash.

Using 4.3.3, compiled with --enable-drillbit, cgminer picks up the device but hashing stays at 0


Do I have bad hardware?

I guess you need to check with support from slush then cos I wasn't aware it would use redirect in any way within the proxy code, unless it's because you're using an IP address directly?

Well I must have done something wrong here then because having patched the S1's, my slush proxy is showing now as a dead pool on all of the Ants.

I'm sorry, didn't want to put your findings into question, just shared my experiences in addition. No offense intended.

You can build at least from the same source - this is an interesting read. Indeed there may be some (minor) changes, so not 100% sure if both kernels are actually the same. Major differences between distributions are e.g. different libraries. Like the old problems with different libusb versions. Can not remember exactly which kind of issues, but one distribution worked fine the other caused issues just because of different library versions. As libusb comes now with cgminer and cgminer is not using the system library, these (old) issues are gone.

No, but if the slush proxy supports mining redirection then you are still open to the attack of being redirected and are not being protected by cgminer.

Will upgrading the S1s to this latest version affect the use of the Slush proxy between the miners and the pool?

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.

Note the bolded text.

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.

They replied a couple posts up stating that there's just one redirect.
https://bitcointalksearch.org/topic/m.6541935

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.

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.

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

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

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 

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.....

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.