R9-290X not recognizing _x16 as task

[prjindigo]

Catalyst 13.12, Sapphire R9 290X, "client-type beta" declared, WU 11293 constantly loading on slot reset: ppd reading 2k/frame about 29 minutes. Every 22 seconds the load will spike from zero to about 80% but the GPU clock never leaves 300mhz.

Same configuration was hammering out WU 8900 _x17 last night at 2:54 per frame. This is the secondary card in the system beside a Titan - no conflicts encountered between drivers in three months at redline production. Both on pcie-16 3.0 slots (Sabertooth X79)
(systems monitored using EVGA Precision 4.2.1, R9 idling at 41°C getting jacksquat done)

Is there some way to force _x17 module to load to check to see if it is just _x16 incompatibility? If not can you block _x16 modules from being set to me? _x16 isn't even keeping the card in safe operation temp range.
(titan is pounding out WU 7660 _x15 at 4:20 per frame just fine)

[bollix47]

Please see the answer here.

[prjindigo]

Re: Project 11923 (31,462,49)

Postby Joe_H » Sat Jan 04, 2014 10:07 am
There may not be much you can do about the 11293 WU failing. Core_16 works better with older Catalyst drivers, version 12.8 is the newest one known to be fairly stable. Some driver versions since then have worked, but inefficiently, and others have not worked at all. Core_17 however works better with newer drivers.

At the moment the WS for Project 8900 is listed as down. That might be related to the blog post that they are in the process of generating more Core_17 WU's to be ready possibly later today. In the meantime, the two Core_16 projects were announced to be close to completion a few months ago and their WS is set to a low assignment priority so they only get assigned when Core_17 work is unavailable for AMD cards.

So if that work unit fails to operate correctly on AMD drivers above 12.8 why is it still being assigned to cards that will not run on drivers below 13.0a and thus wasting fifteen to twenty hours in which the cards could finish off three x17 modules?

[bruce]

The FAH servers do not know which drivers you're running so it cannot be used in an assignment decision.

Server 171.67.108.44 which has projects for FahCore_16 is set at an extremely low priority so those WUs will only be assigned when no WUs for FahCore_17 are available. If you check the blog and other recent posts on the forum, you'll see that there has been a period when core_17 assignments were unavailable. it looks like there is a general policy of making Core_16 assignments only when core_17 assignments are unavailable. I think that makes sense since most GPUs with most drivers will run Core_16 assignments and at least for those folks, running them is probably preferable to having the server tell everyone that no assignments are available.

[prjindigo]

Process 8900(47, 0, 138) started exhibiting same behavior at around 94% completion: pulsing clock around 300mhz, no heat in sink.
On restart 8900(47,0,138) reverted to 58.06%. Client had to be forced offline.

Some sort of memory hole?
Manual restarts of client every 25% should solve the issue for _x17.

Can confirm, restart every hour. 8900(167,7,31) crashed at 54%.

[PantherX]

If it is a memory leak, it must be very unique since you are the first to report this kind of behavior.

For further troubleshooting, please post the log file which will contain your system configuration and F@H settings.

[Joe_H]

Is your GPU overclocked, factory or otherwise? What you have described sounds more like a driver crash and reset. The same symptoms of the client reporting progress and then reverting to a previous checkpoint have been mentioned by a number of other folders. You can check the Windows logs for driver resets that correspond to the GPU stopping processing and going to the low clock speed.

[prjindigo]

probable resolution: Force pcie-16X into 3.0 mode and lock it there.

For some reason the Sapphire 290X was bumping the slot in and out of 3.0, when it did that for whatever reason it would miss-time and pop the API in the nose. Roughly the same as the problem we had last year with youtube videos and AMD cards. I've had it running flat out at 1100MHz for more than 24 hours and not a single quirk has occurred on the same driver set I started out using.

The feature to lock pcie generation is in cmos.