Quote from: earthsound on May 18, 2012, 10:30:58 PM

Quote from: DiabloD3 on May 14, 2012, 11:04:17 PM

Quote from: typhoon on May 14, 2012, 10:57:25 PM

Quote from: DiabloD3 on May 14, 2012, 10:33:58 PM

Quote from: typhoon on May 14, 2012, 10:14:23 PM

Quote from: DiabloD3 on May 14, 2012, 11:48:58 AM

Quote from: typhoon on May 14, 2012, 11:09:09 AM

Just reporting in that after I upgraded to the latest DiabloMiner, on both my Windows and Linux machines the miner starts as usual.. adding the devices and then hashing away.. However, shares are never submitted. I walked away for a while and saw that in fact no shares had been submitted to eligius. For proof check out: http://eligius.st/~artefact2/7/1AXiiwR4aYktPKMBMsZaP1untDgN9T8FfX

Edit: Found an older DiabloMiner and reverted (it does not include the 2 latest commits), back to mining.

I cannot reproduce that bug. BTW, I've dropped OpenCL 1.0 support, so if you're on SDK 2.1... don't do that. DM is supposed to detect if you're on 1.0 and refuse to use those devices, too. Well, assuming I coded that test right.

I am on Catalyst 12.4 and the SDK that is included with the drivers. Radeon 5870s/5850s in both boxes (CentOS/Windows 7). If there is anything I can do to help you possibly pinpoint the problem I am all ears. Basically diablominer adds the OpenCL devices then starts hashing away at only god knows what.. and never submits shares, all whilst hashing at full speed and making my GPUs waste energy.

The hash meter has a number above zero, right? I'm wondering if Windows has a driver bug that Linux doesn't, because I'm on Linux /w Catalyst 12.4 using the runtime that comes with the drivers, and I can't reproduce it.

Yes the hashrate is at full speed, causing 100% gpu usage on all gpus. This happens on 2 separate systems, both with catalyst 12.4 and the included sdk. One system is windows and one is linux (CentOS).

Thats extra weird. I'm going to have to think about this one for a bit. It doesn't make sense you have the bug and I don't... I wonder if its hardware related, because I'm on a 7970, not a 58xx.

This may be unrelated to typhoon's problem, but the latest version of diablominer fails to submit to and/or connect to the mining pool I've been using.

I'm running on 2011 iMacs, running OS X 10.7.4, with AMD Radeon HD 6750M (512 MB of RAM) and Apple OpenCL 1.1 (Apr 9 2012 19:41:45).

The command line arguments I'm using include:

./DiabloMiner-OSX.sh -w 64 -v 2 -na

The May 2012 version outputs the following:

Code:

[5/18/12 10:19:36 AM] Started
[5/18/12 10:19:36 AM] Connecting to: http://mining.eligius.st:8337/
[5/18/12 10:19:36 AM] Using Apple OpenCL 1.1 (Apr 9 2012 19:41:45)
[5/18/12 10:19:37 AM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 10:29:40 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:31:59 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
[5/18/12 10:38:21 AM] ERROR: Cannot connect to mining.eligius.st: Read timed out
mhash: 61.0/57.2 | accept: 0 | reject: 0 | hw error: 0

The March 2012 version outputs the following:

Code:

[5/18/12 2:09:31 PM] Started
[5/18/12 2:09:31 PM] Connecting to: http://mining.eligius.st:8337/
[5/18/12 2:09:31 PM] Using Apple OpenCL 1.1 (Apr 9 2012 19:41:45)
[5/18/12 2:09:32 PM] Added ATI Radeon HD 6750M (#1) (6 CU, local work size of 64)
[5/18/12 2:09:53 PM] mining.eligius.st accepted block 1 from ATI Radeon HD 6750M (#1)
[5/18/12 2:13:39 PM] mining.eligius.st accepted block 2 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:23 PM] mining.eligius.st accepted block 3 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:36 PM] mining.eligius.st accepted block 4 from ATI Radeon HD 6750M (#1)
[5/18/12 2:15:54 PM] mining.eligius.st accepted block 5 from ATI Radeon HD 6750M (#1)
mhash: 58.9/59.3 | accept: 5 | reject: 0 | hw error: 0

Are there any options I can use to give more verbose messages?

On an unrelated note, I've recently noticed this model iMac go down to ~50-60 mhash/s from a previously consistent ~70 mhash/s. Could this be related to May's change(s) or the latest Lion update from Apple?

Try a different pool. I have not changed anything that involves pools at all as far as I know. This has been largely the removal of code, not the changing of it.

As for OSX, its probably a Lion update. Quite a few Mac users have bitched that every time OSX puts a new update out, OpenCL apps get slower.