I was just coming back to say that it actually ramped back up to where it was was 1.3.1.  I think it is fine as is now that I understand what to expect.

Latest git works (doesn't crash) but gets about 20% less MH/s than 1.3.1 (~200 MH/s vs ~250MH/s) on my HD 5870/OS X Lion.

Great, thanks.  I can't get ./autogen.sh to work (never have been able to get it to work on OS X) I think because OS X has the wrong version of autoconf (autoconf (GNU Autoconf) 2.61).

Hopefully ancow can test it, else I'll have to wait for the next source package that has ./configure already generated.

That didn't make a difference.  Same error as before, so apparently not phatk kernel related.  Let me know what other information I can provide.

P.S.  My error is the same as what ancow is seeing, and it looks like he was able to provide a stacktrace of the segfault.

I'll try that, later today.

Looks great.  Are there definitions of the SMPPS variations somewhere?  I am unfamiliar with several of them (equalized pps, prop/pps, capped pps).

It may be hardware specific then.  I have a Mac Pro with an HD 5870. 

In Snow Leopard the symptom was that DiabloMiner showed me getting something like 1000 GH/s (which is impossible) and never actually found shares.  D3Diablo I think posted that the problem was that the new kernel was crashing in OpenCL but that Apple wasn't reporting errors so it looked like it was just succeeding very fast.  He didn't indicate any desire to workaround or fix the issue it because it is "Apple's Problem".

In Lion, I initially got an error about work size being incorrect (see my post in the DiabloMiner thread), but that was worked around by forcing worksize of 64. I still get the B.S. hashrate though.

I happen to have saved off a very old version of DiabloMiner and it works in Lion (it's before he made the kernel optimizations that are broken with the HD 5870), but it gives a lot of messages about hardware errors.

Note, even in Snow Leopard, no miners that use a phatk-like kernel worked with my HD 5870 and they still don't work in Lion (which is why the most recent poclbm doesn't work).  So I don't think this is a Lion issue specifically.

As far as I can tell, the only Lion specific issue at this point is the DiabloMiner work size error and the fact that all of the "working" miners seem to generate corrupt shares from time to time (about 5%).  I don't know if that is a bug in the new OpenCL 1.1 or what, but given that my hashrate increased by close to 25% going from Snow Leopard to Lion, I am willing to tollerate 5% corrupt shares.

1.4.0 seg faults on OS X (Lion)

1.3.1 worked fine (with -v 1)

With 1.4.0, part of the screen draws before the segfault, so here is a screen grab in case the location that "Segmentation Fault 11" draws might be an indication of where the crash is happening (there are also some errors in the message log):

https://i.imgur.com/8EW8T.png

Note, if you are not aware, the phatk kernel in the latest poclbm and phoenix don't work with Apples Open CL implementation (and never have).  But your kernel did work until 1.4.0.  Not sure if your kernel changes in 1.4.0 triggered this problem or if it was changes in the C code that triggered the problem.  Let me know what you'd like me to do to help debug this, because cgminer is (was) one of the only miners working in OS X Lion.

FYI, phoenix now works with OS X in Lion.  It appears that Apple updated their twisted library sufficiently that phoenix is now happy to run.

These are the miners I found to work:

* old poclbm (pre-phatk, using -f 100 or higher)
* cgminer v1.3.1 (using -v 1 and either dynamic intensity or intensity <= 6)
* current phoenix (using poclbm kernel with no kernel params)

Miners that don't work:

* current poclbm
* current DiabloMiner
* cgminer v1.4.0

Appears to have been paid earlier today:

http://blockexplorer.com/tx/3c6f884b61e444331d0f263d2b13be30e40149bb023429d689cdb4b2dc57e067#o21

-w 64 works to get passed that error, thanks. 

On the current version it still doesn't work, but it again goes back to the symptoms that Snow Leopard (massive reported hashrates and no actual found shares--I think you said this was because the kernel was causing errors but Apple's implementation was not reporting them as errors).

I tried an old version of DiabloMiner that doesn't have the kernel improvements from the last month or so and it runs and finds shares.

Update:  I tried running the old (non-phatk) poclbm with -f 100 and it has been running for the last 30+ minutes without any rejected shares.  So, possibly the default poclbm in that version is just too agressive and that was causing some corruption?

On a side, note, my workstation's HD 5870 is now getting about 285 MH/s (with -f 100) under Lion vs about 192 MH/s (with -f 10) under Snow Leopard.  Still not quite what that card would get under Linux, but much improved.  Given that this workstation has a day job, I am trilled to get almost 50% more hashing out of it while it is idle (this workstation only mines when the screensaver is on).

Edit: and right after I posted this, I got 4 corrupt shares in a row.  Well, I'll keep an eye on it and see how frequent they are and possibly will try an even higher -f setting.

It's an ASP.NET MVC/C# app (ya ya, evil and stupid platform, etc).

I should be able to do it all of the logic client-side in javascript though (which would be a fun weekend project).  If I succeed, then it would be host-able on eligius.st.

All of my observations are from a Mac Pro with an ATI HD 5870.  Some people have reported that they have none of the problems I am seeing when using miners on iMacs with ATI mobile video cards, so your milage may vary

I have tried several miners and not had success with any:

• Current version of DiabloMiner won't start.  Note, the current version of DiabloMiner didn't work with Snow Leopard either, but had different symptoms.
• Current version of poclbm uses the phatk kernel which still seems to not work (status shows incredibly high hashrates for a single GPU which likely means it is erroring out instead of finding real hashes).  The current version of poclbm didn't work with SL either.
• I tried an old version of poclbm (before the switch to phatk) that had worked well on SL, but on Lion, it generates mostly invalid/stale shares (> 80%).  Unsure what is causing those.

So, has anyone had any success GPU mining on Lion, with its new version of OpenCL?  If so, what software and setup did you use?

I had created a similar tool for my own purposes and it my code correctly determines the order since it seems to match with the payout queue from the new raw .txt file.  It does draw lines every 50 BTC to give me a sense of how far out my payment is likely to be:

http://twistymaze.net/eligius/  http://eligius.st/~twmz/

But don't count on this estimate being accurate.  There are several fundamental flaws with my web page...

One problem is that it's looking at a snapshot of balances as of right now.  If you look at it now and a block is not found for 2 hours, the order will probably not be the same when the block is found because a) people are still mining and so the people in the first block will earn more BTC and push out the last few people from the first block into the second block and b) people who aren't above the threshold for payout may get over the threshold and suddenly qualify for payout and when they get added to the queue, they'll push everyone below them down the list furthur and possibly in a different block.

Another problem is that it is not accurately splitting large balances between blocks.  For example, if someone has an unpaid balance of 20 BTC and is near enough the top of the queue to get included at the end of the first block, they may only get paid say 15 BTC (because there isn't enough of the generated 50 BTC to pay them in full).  The web page will list their remaining 5 BTC at the top of the next block.  In reality, that's probably not what will happen because that remaining 5 BTC is probably not old enough to qualify to be at the top of the queue.  You can see this happening several times in the web page where the last address of a block is the same as the first address of the next block.  Those are all likely wrong (the address won't usually be the first address of the next block anymore once the first payment is made).

So, this is a pretty good estimate of who will get paid in the next block if it is found right after you look at it (but you can already see that at http://eligius.st/~luke-jr/raw/5/current_block.json).  On the other hand, my page is not a perfect estimate of exactly who will be paid 4 blocks from now--certainly not the amounts since by the time we find 4 blocks, everyone's balances will be higher.

Knowing those flaws, I still use it myself and find it useful to know if I going to be paid "soon" or "not soon".  If it shows I am not due to get paid for 5 blocks, I at least know that I am not getting paid in the next 1-2 blocks.  I find it valuable that it removes some of the unknown even though it isn't perfectly precise.  Your mileage may vary.

I know you're pretty anti-Apple-OpenCL, but I get this error when trying to use DiabloMiner on OS X Lion (which has an updated version of OpenCL):

[7/22/11 6:15:36 AM] Using Apple OpenCL 1.1 (Jun 14 2011 23:31:14)           
[7/22/11 6:15:37 AM] Added ATI Radeon HD 5870 (#1) (20 CU, local work size of 256)
[7/22/11 6:15:41 AM] ERROR: [CL_INVALID_WORK_GROUP_SIZE] : OpenCL Error : clEnqueueNDRangeKernel failed: local_size[0] (256) != required local_size[0] (1024)
[7/22/11 6:15:41 AM] ERROR: Failed to queue kernel, error -54               

...followed by it crashing back to the command prompt.

In the event that that local_size is related to work size, I tried forcing the work size to 1024 (not sure if the error is talking about that or not), but that doesn't work either because DiabloMiner doesn't permit a work size larger than the detected max for the device.

Payouts are done with "generate" transactions.  If you get paid in any given block, you should see it in your wallet almost immediately, but it won't be spendable or be counted in your balance until it gets 120 confirmations.

Ok, I have confirmed that poclbm will happily submit shares that don't meat the target requirements.  This explains the shares/hour being identical to past experience even though share difficulty is 3-4x higher with p2pool.

My next question is does p2pool correctly reject these shares?  I can tell that p2pool never tells the miner they are rejected (the "result" of the share submission is always "1" (true)), but there may be some place else in the p2pool code that notices the hash does not meet the target requirements.  I'm not that good at reading python code, so I can't tell by looking.

Is there a known problem with poclbm (latest git) not checking the actual target of a getwork?  I don't see error messages about submitted shares being rejected for not being below the target, but I am also finding shares about the same rate as I do normal pool serving up exclusivly difficulty 1 shares.  I can clearly see in my proxy logs that the difficulty coming back in getwork requests is not 1. And I can see that the shares being found are are getworks with higher than difficulty 1 targets. The average difficulty of of the getworks associated with found shares over the past couple hours has been 3.  But I have found the same number of shares as I do when mining exclusively at difficulty 1.  Something doesn't seem right.