Topic: DiabloMiner GPU Miner - page 42. (Read 866596 times)

Hey, I keep getting this error when I run the miner.

Could you make your DiabloMiner directory available somewhere? I also mine for fun:

Agreed. What I do is, I patch the current master head version so that it uses the kernel and support code from before the change. Works nicely, but admittedly not a solution for the masses.

Regarding performance loss on OSX, well, I mine for fun not for profit, and I'd rather have something that works at reduced efficiency than nothing at all.

Yeah, but you also lose a ton of important fixes.

Honestly? Don't mine on OSX. Even when it works, it sucks up 40% of your performance.

This running-wild behaviour is a well known problem with the somewhat broken OSX OpenCL implementation and the phatk-style miner kernels. No proper solution yet. However, you can use an earlier version of Diablo miner with a different kernel. If you check out the sources, do a "git log" and look for the time the switch to the phatk occurred (iirc Jun 24), and use that one. You can also find an older version packaged in a Mac-friendly app by someone else here on the forums: https://bitcointalksearch.org/topic/mac-miner-front-ends-to-diablo-and-rpc-8994

This really should be an FAQ entry somewhere...

It is the original Mac Mini without any hardware changes. (1 video card)

How can I help to get rid of the OSX insanity? Or should I get rid of OSX?

The ghash meter just measures raw ghash produced. If it stops moving, then yes, you have a problem. FPS doesn't sound right unless you're a large -f value in the same ballpark, and the second mhash number doesn't make sense unless you own 2 or more video cards.

I assume its just more OSX insanity. I am not surprised.

I'm running DiabloMiner on a MacMini 10.7 with a ATI Radeon 6630M with the following start parameter:
./DiabloMiner-OSX.sh -u name.macmini -p password -o mining.bitcoin.cz -r 8332 -w 64 -dd

After about 15 minutes the system crashes.

Are the mhash and ghash values realistic?
Last line, before the system crashes:

How can I help to debug the issue? (DiabloMiner works perfectly fine an my old MacMini 10.6.8 that I still have.)

Here is the complete output of the DiaboMiner debug log: (Please notice the increasing numbers for mhash and ghash)
http://codepaste.net/qhr2es

Known 10.7 bug. Until they fix it, use -w 64.

The bug has been submitted already:
https://sourceforge.net/tracker/?func=detail&aid=3385595&group_id=95944&atid=613100#

I have +1 myself.

Hi DiabloD3,
I will let them know about the bug. Let's see how they react.

I tried something else: I used the compilation from my MacBookPro and copied it to the Mac mini and let it run with following result: (name and password replaced)

localhost:DiabloMinerComp thomas$ ./DiabloMiner-OSX.sh -u placeholder.placeholder -p placeholder -o mining.bitcoin.cz -r 8332
[8/12/11 8:07:43 AM] Started                                                 
[8/12/11 8:07:43 AM] Connecting to: http://mining.bitcoin.cz:8332/           
[8/12/11 8:07:43 AM] Using Apple OpenCL 1.1 (Jun 25 2011 01:23:15)           
[8/12/11 8:07:44 AM] Added ATI Radeon HD 6630M (#1) (5 CU, local work size of 256)
[8/12/11 8:07:44 AM] ERROR: [CL_INVALID_WORK_GROUP_SIZE] : OpenCL Error : clEnqueueNDRangeKernel failed: local_size[0] (256) != required local_size[0] (1024)
[8/12/11 8:07:44 AM] ERROR: Failed to queue kernel, error -54 

I am having errors compiling DiabloMiner on Lion (Mac Mini 2011 i5 CPU) AMD 6630M.

I am getting the following errer when running maven:
mvn clean install in the DiabloMiner directory. (It works on my MacBook Pro 10.6.8 )

Full debug-log:
http://codepaste.net/ziimsi

[INFO] launch4j: Launch of "windres" failed: the PowerPC architecture is no longer supported.
[ERROR]
net.sf.launch4j.BuilderException: net.sf.launch4j.ExecException: Exec failed(2): [Ljava.lang.String;@3a7f1228
        at net.sf.launch4j.Builder.build(Builder.java:145)
        at com.akathist.maven.plugins.launch4j.Launch4jMojo.execute(Launch4jMojo.java:326)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: net.sf.launch4j.ExecException: Exec failed(2): [Ljava.lang.String;@3a7f1228
        at net.sf.launch4j.Util.exec(Util.java:142)
        at net.sf.launch4j.Cmd.exec(Builder.java:206)
        at net.sf.launch4j.Builder.build(Builder.java:98)
        ... 22 more

Update: Improved error handling more, remove usage of System.exit() and blanket Exception catching, DiabloMiner now passes FindBugs

Yeah, it doesn't keep track of things like that. It'll normally do a 15 second timeout, fail, and rotate to the next.

It is just by virtue of it not rotating off a good pool that it will gravitate towards the more functional pools.

DiabloD3,

Ok, but if this stable pool becomes unreacheable (for example) does your miner move back to one of the previous less-stable pools or stops there waiting for it to become alive again?

Sorry to bother, just to understand its logic.

TIA

spiccioli

No.

Although I've been considering having it change pools after a semi-random timeout, but you risk being sent back to the unstable pool.

It really doesn't matter what pool you mine on as long as you're mining, honestly. You'll eventually get the payouts, it just takes a little longer.

Ok, I see the logic, but

is there a way to force it to try again (after some time) a pool which gives an error (apart from restarting the program)?

spiccioli

Its by design. Anytime a pool fails to connect during a getwork, that execution thread rotates to the next pool. Which pools execution threads are set to on startup is randomly selected.

The client will generally gravitate towards the most stable pool.