Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doesn't do anything on GTX 670 #94

Open
markasoftware opened this issue Mar 9, 2017 · 7 comments
Open

Doesn't do anything on GTX 670 #94

markasoftware opened this issue Mar 9, 2017 · 7 comments

Comments

@markasoftware
Copy link

markasoftware commented Mar 9, 2017

I have a 2gb ASUS GTX 670. When running just ./silentarmy to the donation address on Arch Linux, it gives this output, then nothing:

Connecting to us1-zcash.flypool.org:3333
Solver 0.0: unexpected banner "/home/markasoftware/Downloads/silentarmy/sa-solver: /opt/cuda/lib64/libOpenCL.so.1: no version information available (required by /home/markasoftware/Downloads/silentarmy/sa-solver)"
Solver 0.1: unexpected banner "/home/markasoftware/Downloads/silentarmy/sa-solver: /opt/cuda/lib64/libOpenCL.so.1: no version information available (required by /home/markasoftware/Downloads/silentarmy/sa-solver)"
Stratum server sent us the first job
Mining on 1 device

No sol/s or any other progress indication. Are kepler GPUs supported? Only 42% of my GPU memory is in use according to nvidia control panel.

EDIT: The GPU does show up in ./silentarmy --list

@mbevand
Copy link
Owner

mbevand commented Mar 21, 2017

I don't know what is the cause of the pb. Sorry SA is at the moment not supported.

@markasoftware
Copy link
Author

markasoftware commented Mar 21, 2017 via email

@slashafk
Copy link

Hello, same problem with my GTX780, I start Silentarmy, and then nothing after :

Stratum server sent us the first job
Mining on 1 device

I did try to rerun it with -vvv to see more information, I got those line :
To solvers: 0000000000000000000000000000000000000000000000000000000000004000 123853#651 040000005735736eedeeaa7676280ed0fb0e26485d97f7de4465471211d9c3460000000064d7b546eeca3f9ea53e13fceb03a313d9f9e641b85250f67570f2af7f67c444000000000000000000000000000000000000000000000000000000000000000030152f59e7d5471c 00000000

And nothing after after, like the process did hang or something :s

If I then use :

sa-solver --mining

And paste the mining stuff :
0000000000000000000000000000000000000000000000000000000000004000 123853#651 040000005735736eedeeaa7676280ed0fb0e26485d97f7de4465471211d9c3460000000064d7b546eeca3f9ea53e13fceb03a313d9f9e641b85250f67570f2af7f67c444000000000000000000000000000000000000000000000000000000000000000030152f59e7d5471c 00000000

It does the mining and find solutions ...

SILENTARMY mining mode ready 0000000000000000000000000000000000000000000000000000000000004000 123852#808 04000000ed99d8f67b531acf11a0adcfb60a9f50864979a8b03bd220d5c4361b00000000a408c98e77be4fffc8f9373f5894f811f0ea3d397f711a02ed65adaa07115b9d0000000000000000000000000000000000000000000000000000000000000000c6142f59ed92471c 00000000 status: 1 0 status: 16 0 status: 23 0 status: 41 0 status: 51 0 status: 60 0

So I think that the problem is not the solver itself, but the python daemon somehow lose the process that he is suppose to watch.

Does it works with python3.6/linux ? asyncio problem ? Encoding problem ? (Not using utf8 by default)

Seems to work pretty well until :
for devid in self.solver_procs:
self.solver_procs[devid].stdin.write(job.encode('ascii'))

@slashafk
Copy link

Well I did investigate a bit more, it appears that the opencl version embedded by Cuda doesn't return a "required information"
sa-solver: /opt/cuda/lib64/libOpenCL.so.1: no version information available (required by sa-solver)

That fail the following test :

        #if banner != "SILENTARMY mining mode ready":
            #print('Solver %s: unexpected banner "%s"' % (devid, banner))
            #proc.kill()
            #self.cleanup_solvers(devid)
            #return

So the sa-solver gets killed.

I did comment it out, and it works perfectly :).

I guess :
stderr=asyncio.subprocess.STDOUT
return the error at the place of the banner, resulting in a crash :s.

You should may be manage stderr in another subprocess or ignore this one.

@C0rn3j
Copy link

C0rn3j commented Jun 21, 2017

Same issue on Arch with GTX 660. Using GTX 970 there is no issue.

@Smodel
Copy link

Smodel commented Jun 22, 2017

Hi all i am having the same issue with 1080 Ti on Ubuntu. Any solution ?

@C0rn3j
Copy link

C0rn3j commented Jun 22, 2017

Unrelated to this project, but I ended up using ccminer-git from AUR. While I still can't use it with my 660, it's way faster than silentarmy on my GPU.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants