switching from X11 to scrypt-N

[kenshirothefist]

A reproducible issue: when switching from X11 to scrypt-N, one of my GPUs goes idle ... displayed hashrate is stalled, showing latest X11 hashrate, but GPU is obviously idle. If I restart this particular GPU with [G] - [R] - 4 (the number of my GPU), it is successfully restarted and resumes in expected scrypt-N mining hashrate.

Idea: Would it be wise to add a forced restart of GPUs always when switching algorithms, just to make sure things gets cleaned-up?

[mrbrdo]

Maybe. If you use pool-gpu-threads then the threads are fully restarted. So if the issue is present with that setting then forced restart will not help since it is already done.

[cgladue]

i am having this same issue as well... i can mine on Scrypt-N fine then switch to X11 and everything is fine there as well, once i switch back to Scrypt-N then things start going bad. i have 4 x 270X gpus and 2 of the 4 will make the switch OK. the other 2's hashrates stall at the X11 rate and eventually sgminer realizes this and declares them SICK, which time the Display driver stops responding and the system usually freezes and requires a reboot. sometimes not tho. i did try using the "Restart" option within GPU menu and it did not help. There are status messages about the GPU thread being hard hung. attached is the debug log from when i recreated this happening. i can reproduce every time.

Debug Log:
https://drive.google.com/file/d/0B363GmAu7NFzTVAtLUtJVDRDUU0/edit?usp=sharing

[platinum4]

This issue is duplicitous and mentioned with regards to nfactor of 11 here #246

Anyway we can close this issue and wrap it into #246 ?

[cgladue]

no it isnt, i never receive the -4 error , 2 of the 4 cards hash fine but 2
die and go sick then the whole machine locks up.

Chad P. Gladue
Website Design & Consulting

On Tue, Jul 1, 2014 at 3:33 AM, platinum4 notifications@github.com wrote:

This issue is duplicitous and mentioned with regards to nfactor of 11 here
#246 #246

Anyway we can close this issue and wrap it into #246
#246 ?

—
Reply to this email directly or view it on GitHub
#264 (comment).

[platinum4]

Cards going SICK->DEAD can be the aggressiveness of your overclocks with relation to heat. Is this is repeatable issue you can replicate on-demand or does it happen randomly? What cards do you experience this on? Anyway we can try and track this down and isolate it? I get SICK->DEAD cards on nscrypt pretty regular even using previous exeminer/vertminer, I'm on 290Xs. Lately, the only way I've been able to get SICK->DEAD reliably has been when running algorithms that had 'hamsi' as a part of it, such as x13 & x15. Only very occasionally can I get a SICK card on x11 at stock clocks.

[cgladue]

i attached a debug output link to my issue with all the logs of when it
happened ... the overclocks were by no means aggressive and the temps are
below 70 on an Reference R9 270X

Chad P. Gladue
Website Design & Consulting

On Tue, Jul 1, 2014 at 10:23 AM, platinum4 notifications@github.com wrote:

Cards going SICK->DEAD can be the aggressiveness of your overclocks with
relation to heat. Is this is repeatable issue you can replicate on-demand
or does it happen randomly? What cards do you experience this on? Anyway we
can try and track this down and isolate it? I get SICK->DEAD cards on
nscrypt pretty regular even using previous exeminer/vertminer, I'm on
290Xs. Lately, the only way I've been able to get SICK->DEAD reliably has
been when running algorithms that had 'hamsi' as a part of it, such as x13
& x15. Only very occasionally can I get a SICK card on x11 at stock clocks.

—
Reply to this email directly or view it on GitHub
#264 (comment).

[platinum4]

@cgladue Sweet, that should help somebody be able to take a look at this. Was just bringing up factors I've experienced personally, so if this is repeatable and affects you it no doubt affects others. Thanks for keeping up with the issue, and delineating that's it's different from #246

[mrbrdo]

The zero hashrate should be solved now, otherwise see here: #305

The -4 error in clEnqueueNDRangeKernel is a separate issue here: #246