Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 778. (Read 5805728 times)

Got a weird thing going on here, I have a Sapphire 5970 OC Edition and an XFX 5970 Black / Limited Edition in the same system. The first core of the Sapphire underwent some sort of thermal damage and is now unstable in the >300 MHz ranges, I have also discovered that the other GPU's aren't fully loaded when running in the same instance as this damaged GPU, so I keep it running in a separate instance of cgminer with dynamic intensity. Now, the first and second GPU of the Sapphire show up as core 0 and 3, the XFX GPU's show as 1 and 2 in cgminer.

If I provide comma-separated engine values, it seems to take the same (lower) settings for both cores on the Sapphire 5970, or maybe it's interpreting the values I provide in reverse. The XFX card doesn't respond to my settings, it reports default overclock values for the card. All of these are clocked with AMDOverdriveCtrl (I have no choice, as the rig will crash if core 1 on the Sapphire goes over 300 Mhz). So far, I am blessed though with the auto fan control, which bypasses the Sapphire's shitty stock fan control. Go cgminer! On the XFX though, fan control is also acting weird, here the default algorithm seems to do better, and if I shut down cgminer with auto-fan enabled for the XFX, then the fan on the XFX will also quit until rebooted. No more toying around for me.

I'm sorry to report this, but auto-fan option is broken for me in 2.0.2 (windows 7 64 11.8 ). Fan speed is just going down to zero I had to manually specify --gpu-fan 65 to make it work.

Is this with the new v2.0.2? Some changes I made to it should help set things even though it thinks it has failed now.
No, it still can't do what msi afterburner does, nor can it outdo the 125 difference limit on 6970s.

Oddly enough, after some restarts and system updates, it seems to now be overclocking it over the ViDock. I can't say why, but I'm happy.

In version 2.0.1 or later, specify a max fanspeed up to 100 with --gpu-fan 100 or --gpu-fan 0-100

Welcome back to BTC talk.  

New version:2.0.2 (most important change is fix for a rare crash)

- Exit cleanly if we abort before various threads are set up or if they no
longer exist.
- Fix a rare crash in HASH_DEL due to using different mutexes to protect the
data.
- Flag devices that have never started and don't allow enabling of devices
without restarting them.
- Only force the adapter speed to high if we've flagged this device as being
managed.
- Flag any devices with autofan or autogpu as being managed.
- Use a re-entrant value to store what fanspeed we're trying to set in case the
card doesn't support small changes.     Force it to a multiple of 10% if it
fails on trying to speed up the fan.
- Do not bother resetting values to old ones if changes to GPU parameters report
failure, instead returning a failure code only if the return value from get()
differs.
- Remove redundant check.
- Only display supported values from fanspeed on change settings.
- Missing bracket from output.
- Display fan percentage on devices that only support reporting percent and not
RPM.
- Properly substitute DLOPEN flags to build with ADL support when -ldl is needed
and not when opencl is not found.

This is amazing, no monitoring scripts or separate windows needed.  Having trouble with the auto-gpu though, can anyone tell me how to properly set it so the fan will jump to 100% before the engine clock is lowered?

Just tried 2.0.1 and get the error "Failed to init GPU thread 0, disabling device 0"

after pressing enter it shows both GPU''s disabled and trying to enable them causes a crash.

WinXP SP3
Cat 11.6
Sam

K thanks for the reply, I must have stuffed something up while setting up Xbuntu for mining... looks like I might go back to windows

In that case, no, there is no reason.

yes I set -I 9

Did you set intensity?

Just recently changed to linux for mining, is there any reason why the activity on all my gpu's are only sitting between 85% - 90% which is producing lower hash rates? I am using the same cgminer settings as I did on windows and on windows all Gpu's where 99% activity and ofcause a higher hash rate

new version is sweet!

I like the cleaner output. the gpu and mem clock ranges rock. and the emergency temp cutout.  and performance is better than any other miner Ive run before by an easy 6+ percent. and I could go on..

I see Im gonna have to redo my sig with updated figures heh

Hmm I doubt it. The final Makefile ends up:
cgminer_LINK = $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(cgminer_LDFLAGS) $(LDFLAGS) -o $@

and Makefile.am is:
cgminer_LDFLAGS   = $(PTHREAD_FLAGS) $(DLOPEN_FLAGS)

and configure ends up with
echo "  LDFLAGS..............: $LDFLAGS $PTHREAD_FLAGS $DLOPEN_FLAGS"
which is:
LDFLAGS..............:  -lpthread -ldl

So... somebody is lying 

Your error is different than mine, but on the off chance that it is caused by differing versions of something, see my post:
https://bitcointalksearch.org/topic/m.512233
Don't forget that when you manually specifiy CFLAGS or LDFLAGS (or whatever else) on the command line, your specification overrides anything the script would do.  As such, the -ldl must be added manually because the autmatic stuff isn't applying.  This may not be true when you export, and may not be true as a general rule of thumb, but has been true in my experience on Fedora 15.

Okay, bummer, so I just tested using cgminer to overclock my Gigabyte Super Overclock 5870 card when running it through my x1 ViDock, and it won't take the overclocking commands.

In comparison, I've had no problem overclocking a reference 5870 when running it over my x1 ViDock, and I've had no problem overclocking the non-reference Gigabyte 5870 itself with cgminer when it is plugged into a regular x16 PCIe slot on a rig.  So, might anyone know why it won't allow me to overclock it when plugged into the ViDock?

The one thing I haven't tried is to see if the card will still overclock when plugged directly into an x1 PCIe slot on a rig.  The reason I mention this is because the only thing I can think of is that it might need the higher pins on the x16 slot for the overclocking commands to actually be sent to it, but then I'm not knowledgeable enough to know if that is even plausible.

Keep in mind that GPU-Z detects the card properly when running it through the ViDock, and cgminer can detect the card just fine for mining, so it's not like the card isn't being detected at all.

ck, did you know that you are like crazy cool, man? I am running 2.0.1 and well, I don't know how did it manage to achieve it, but it down-clocked my memory to 300 Mhz, which was not possible using pplib commands on my old FirePro V5700 (sic!). This saves me like 8C or so. It doesn't seem to be able to read RPMs though, Fan Speed: 65% (-1 RPM). But well, it's already something!

Also, I am sick of the curses bug, so here is how to compile cgminer statically against latest curses:


Might be worth adding to the readme.

Well that's correct, there is no fan control on the 2nd GPUs of 6990s. What will look odd though is the order of the cards. That's just how they happen to be enumerated by the driver and I have no control over it. It looks like GPU 0 and 2 are one dual core card and 1 and 3 are the other card.