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

No

No, Win7 doesn't suspend tasks of inactive user.
It does make something weird with drivers when switching between users but again it isn't full termination or suspend.
Anyway 2.3.1 have enough luck to work well behind the scene and behave alive when I switch to the user where It runs.

I wonder if something was changed between 2.3.1-2 and 2.3.2 and caused such behavior?

Kinda hard to test GPU mining when I didn't have any working GPUs; I think I did the best reasonably expected given those circumstances. That's solved now (I have 1 working GPU, and another on the way).

I added work-restart support to the Icarus driver, and you started demanding I had to refactor the (admittedly broken-by-design) internal structure that it used. Just because I'm touching a piece of code doesn't mean I want to refactor the existing code it's using (and when/if I do, it certainly doesn't belong in the same commit). As I told you, I wanted to talk to Con before changing it, since I wasn't very familiar with it. As it turns out, this particular code goes back to Jeff Garzik and cpuminer, and Con seems fine with the refactor you suggested.

Sorry, I had no reason to expect that fixing the hashrate measurement in the Icarus driver would somehow break the actual share-finding. It was a subtle bug, one you admit would only be noticable after hours of mining with it.

I finished writing that JSON API refactoring I proposed to you, and was kindof hoping you could look it over and see why I think it's a good idea. Feel free to take your time; it'll just be sitting there waiting for your input when you get back, not merged until you give it a thumbs up.

OK, I take that back.
After spending some time arguing with luke-jr about bugs in his pull requests that he wouldn't listen to
I'll say there are issues with accepting his code.

In the past he hasn't tested (or even compiled) some of the changes he requested, I know he doesn't test run the code on windows by his own admission, and having to argue with him about why a code bug is a bug is a complete PITA.
(and then have him say that it's my bug because I have a similar code change (written better) that I know has the bug that I haven't sent the code to be added - because I know it's a bug and haven't worked out the fix yet in my unsent code - is even more annoying )

He likes to label a piece of text displayed by cgminer as a bug if it isn't what he wants (that one will probably be in the next release)
But a real code bug that he put in as a pull request - he thinks that's not possible.
(until later he sees exactly what I've told him is already on his own screen - he just didn't test it properly)

I like working on the API (and Icarus.c) coz noone else is messing with it or making stupid changes to it (and also the donations for the API are high compared to other donations so far - in real terms they are not a lot - but compared to other stuff around here, they are good) but there are a lot of changes that I see luke-jr now trying to push on those two and I don't trust his code ethic (or his code)

I'm sure this will not affect anyone, but I'll take a break from the code for a day?, week?, month? and see how this latest set of changes mess things up ... or wait for them to disappear.

I don't have any control at all over the cgminer code, that's all ckolivas' decisions, so it shouldn't matter to anyone anyway.

More specifically the DISPLAY DRIVERS are user mode drivers (in WinXP they were kernel mode drivers).  When user switches they are shutdown.  When new user logs in they are started up under the new user.  No drivers = no access to GPUs.  There is no work around that can be done by the developer or end user.  For stability reasons display drivers are now user mode (as of Windows Vista) and that will never change going forward.  There are advantages like having a driver crash and you just get "AMD Catalyst stopped respond, driver restarted" message instead of a BSOD.  Also crashing applications like games are more likely to crash back to the desktop then halt the entire system.

This is a Windows 7 issue, it has nothing to do with cgminer.  W7 doesn't operate the same as XP did, anything that the user has running is suspended when that user is logged out or another user is switched to.  In XP you could continue to have programs running with a logged out user, not in Win 7.

Thanks extremely Got it
(and yep it's in ckolivas' git now too)

I don't know about others but for me the display of cgminer is great.

Sounds to me like nit picking

The code is much more important than the display.

If you want pretty colors and some other crap in the display then feel free to code it yourself ...

Well you'll have to look elsewhere to see what permissions you extracted the zip file with or something like that, because cgminer has no clue about users or permissions like that.

did you set the intensity too high? I set mine to 4 on my faster cards and 2 on my slower cards
I never use d

I'm sorry but this is virtually impossible to do reliably (the GPU part). OpenCL doesn't tell us what the devices are. cgminer tries to guess with ADL and it's not entirely reliable.

I don't know O_o.
But when I return back to the user running cgminer I see that no more shares were submitted since I switched out.
It just staying still.

Using this example/option from another thread....



Is there currently a supported API call in 2.3.3 that will return GPU MODEL or GPU FAMILY ?

Thank you. 5BTC sent.

Re: The display.

Screw it, I don't really want to change the layout, or what's displayed, so I've spent the afternoon fighting with curses to try and get it working with any number of devices, provided your window is long enough. If it's not, you'll lose the log window output.

User switching?... What on earth has the cgminer version got to do with that?

Both 2.3.2 and 2.3.3 windows versions stop working on user switching.
2.3.1 works well.
Win7 x64, SDK 2.6.

2.3.1 did/does not exhibit this behavior with the same cgminer.conf file.

No, I'm not confusing it.  The thermostat between the chips is what it's reading I believe, so 85C is the correct temperature for that particular reading.  72F is for ambient temperature, not die/near die temp.

Sure you (or Sonny) aren't confusing C and F? He told me BFL Singles need 72 F / 22 C) ambient temp to run at full speed. My on-FPGA temp for BFSingle is 149 F / 65 C even with an ambient temp of about 80 F. There shouldn't be a 30 C cutoff...

The cutoff temp defaults to 95°C

Please check that you do not have an autoloaded cgminer.conf that contains 30°C or you somehow accidentally put that on your command line.

If this has never worked, then maybe the code Luke-jr uses only detects the 2nd version of the Temperature message that BFL devices can send (BFL doesn't like people knowing that information it would appear from a discussion I've had with someone else on the same subject earlier today)

So ... is this something new with 2.3.3 (where the temp handling code hasn't changed recently) or something that never worked before?
Or do you have a specific version that does work and the current version no longer works?
(this could be related to the issue I mentioned about BFL changing the status reply)

Though I'd guess Luke-jr should know about which versions of his bitforce.c code that support which messages.