OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 426.

mining4fun11

member

Activity: 110

Merit: 10

Quote from: -ck on December 12, 2012, 11:46:29 PM

Quote from: mining4fun11 on December 12, 2012, 11:43:30 PM

I have a bunch of modminers running on ubuntu and on the new version 2.10.0 the display is showing each fpga individually and I can't see all of them. Also the accept share display isn't showing due to the fact that there is to many devices. Is there anyway to fix this. Thanks.

compact mode, or use more remote monitoring with something like miner.php

How do you run compact mode? I never had to use this option before.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: mining4fun11 on December 12, 2012, 11:43:30 PM

I have a bunch of modminers running on ubuntu and on the new version 2.10.0 the display is showing each fpga individually and I can't see all of them. Also the accept share display isn't showing due to the fact that there is to many devices. Is there anyway to fix this. Thanks.

compact mode, or use more remote monitoring with something like miner.php

mining4fun11

member

Activity: 110

Merit: 10

I have a bunch of modminers running on ubuntu and on the new version 2.10.0 the display is showing each fpga individually and I can't see all of them. Also the accept share display isn't showing due to the fact that there is to many devices. Is there anyway to fix this. Thanks.

Morblias

hero member

Activity: 576

Merit: 500

Quote from: -ck on December 12, 2012, 05:55:26 PM

I've uploaded some fresh debug builds for windows here for those who want to try and help me get debug information:

http://ck.kolivas.org/apps/cgminer/debug/

These builds have optimisations disabled to hopefully try and get meaningful debug information out of them. It's annoying how hard windows builds are to debug...

Oh and the libcurl dll included in the 2.10.0 archive is already one with the fix from 2.9.7 (even though it's a different size) so there's no point trying a different dll if you are getting crashes.

Nice! I should have been doing this the whole time. I am running it like this now and will let you know if it crashes again. So far it's been going 6 hours and no problems yet.

Quote from: Inaba on December 12, 2012, 08:37:01 PM

Yeah, 2.9.7 crashed on me as well this morning. I don't know why, just got a nice Windows error and close program. Trying 2.10.0 now.

Was that 2.9.7 or 2.9.7-1?

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: irritant on December 12, 2012, 09:25:36 PM

could it be a stratum issue?

Well it is 12/12/12. Maybe the end of the world is at hand

irritant

sr. member

Activity: 473

Merit: 250

Sodium hypochlorite, acetone, ethanol

could it be a stratum issue?

iCEBREAKER

legendary

Activity: 2156

Merit: 1072

Crypto is the separation of Power and State.

Quote from: scifimike12 on December 12, 2012, 03:57:25 PM

I'm saw the same thing today, simultaneous crash on all rigs upon Stratum detection of a new block.

Thought it was Windo'hs Update at first, but that's disabled on rigs that still crashed.

Putting half the farm on 2.9.6 and half on 2.9.7-1 until it's sorted.

Inaba

legendary

Activity: 1260

Merit: 1000

Yeah, 2.9.7 crashed on me as well this morning. I don't know why, just got a nice Windows error and close program. Trying 2.10.0 now.

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

I got my very first crash on 2.9.7 this morning. Win7 32 bit.

I just updated to 2.10. My crashes have been few and far between. So I'm not even sure it's a CGMiner problem or not. I'll keep an eye on it and see if I have any reproducible problems.

Thanks for your effort,
Sam

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

I've uploaded some fresh debug builds for windows here for those who want to try and help me get debug information:

http://ck.kolivas.org/apps/cgminer/debug/

These builds have optimisations disabled to hopefully try and get meaningful debug information out of them. It's annoying how hard windows builds are to debug...

Oh and the libcurl dll included in the 2.10.0 archive is already one with the fix from 2.9.7 (even though it's a different size) so there's no point trying a different dll if you are getting crashes.

mokahless

sr. member

Activity: 471

Merit: 256

Bug report:

Not sure if there is a place I should report bugs or if this bug has been reported but I can't be bothered to find out so I figured reporting it here is better than nothing.

Bug:
MH/s between GPU0 and GPU1 is flipped. Everything else is correctly matching the right GPU but apparently my 6950 is giving me 25MH/s and my 6450 is giving me 369MH/s. I upgraded from version 2.7.5 where this issue didn't exist.
I have not tested just running one of my cards or with more than 2 cards.
6950 appears in the top line and 6450 appears in the bottom line. while the MH/s are reversed.

Setup:
CGminer 2.9.7
Windows 8
GPU0 6950 unlocked xfx xxx
GPU1 6450 gigabyte passive
MSI motherboard with 2x pci-e 16x 8x 6950 in top slot

irritant

sr. member

Activity: 473

Merit: 250

Sodium hypochlorite, acetone, ethanol

Quote from: Morblias on December 12, 2012, 04:04:25 PM

Quote from: scifimike12 on December 12, 2012, 03:57:25 PM

I'm also having a similar issue where CGMiner freezes after a certain amount of time. Sometimes it can go fine for a few days but lately its been crashing more frequently.

I tried a new .conf file, reverting to stock clocks, different video cards, etc. And this has been happening on all of my rigs, not just one.

I just had this happen to me on cgminer 2.9.7-1 with 4 BFL singles on it running windows 7 64-bit. It was going strong for 2 days before it crashed.

i had it happen before, but i thought it was because i overclocked my GPU too much, so i put the overclock to a little less and didnt have issues anymore, until just 10 minutes ago, i thought maybe my GPU is too hot or whatever, until i read your post, where you say you only have BFL's and no GPU's... so i don't think it is because i overclocked it too much (it is also on lower settings now) .., the few times it happened I was sitting behind it and doing stuff, so maybe it doesnt like that, gets conflicted or whatever.... but who knows... ,, 2.10.0 here

Morblias

hero member

Activity: 576

Merit: 500

Quote from: scifimike12 on December 12, 2012, 03:57:25 PM

I'm also having a similar issue where CGMiner freezes after a certain amount of time. Sometimes it can go fine for a few days but lately its been crashing more frequently.

I tried a new .conf file, reverting to stock clocks, different video cards, etc. And this has been happening on all of my rigs, not just one.

I just had this happen to me on cgminer 2.9.7-1 with 4 BFL singles on it running windows 7 64-bit. It was going strong for 2 days before it crashed.

Not sure if any of this helps:

Log Name: Application
Source: Application Error
Date: 12/12/2012 1:58:22 PM
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer:
Description:
Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x50c1381c
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x746e6563
Faulting process id: 0x114c
Faulting application start time: 0x01cdd7f97143ad35
Faulting application path: C:\Users\~\Desktop\cgminer-2.9.7-1-win32\cgminer.exe
Faulting module path: unknown
Report Id: 479d2843-4496-11e2-b593-bc5ff4351e2e

cypherdoc

legendary

Activity: 1764

Merit: 1002

i'm at 2.9.7-1 on win 7 with 6970's gpu's and my machines are shutting down completely as well.

scifimike12

sr. member

Activity: 303

Merit: 250

I'm also having a similar issue where CGMiner freezes after a certain amount of time. Sometimes it can go fine for a few days but lately its been crashing more frequently.

I tried a new .conf file, reverting to stock clocks, different video cards, etc. And this has been happening on all of my rigs, not just one.

crazyates

legendary

Activity: 952

Merit: 1000

Quote from: crazyates on December 11, 2012, 12:46:35 PM

Quote from: juhakall on December 11, 2012, 12:32:08 PM

Quote from: crazyates on December 11, 2012, 12:26:57 PM

I upgraded to Win8 this past weekend, but haven't been mining since. I DL 2.9.7 last night, and tried it with my Single. It froze about 30 min after I started it. I restarted it this morning before I left for work, and now that worker is already offline, so I'm assuming it did it again.

I'm running a .bat file with a loop to restart if it freezes, but it's weird cuz nothing happens when it freezes. It just stops, it doesn't exit, give any warning messages, error codes, etc.

I'm assuming this has something to do with Win8 rather than cgminer, but any ideas?

Did you download 2.9.7 or 2.9.7-1? The latter has a Windows crashing bug fixed.

I believe it was 2.9.7-1, as that's the one right at the top of conman's dl site, but I could be mistaken. I can double check when I get home.

Yep, I am in fact running 2.9.7-1. I've run the normal one (and just disabled my GPU) and the fpgaonly, and neither one works. It's frozen about 4 times in the past 5-6 hours.

I've tried removing anything having to do with a GPU from my config file, and I realized that while I was using ozcoin's servers, one of my backkup pools was a direct IP for the ozcoin server. They had dns issues a while back, so I set this. Could having a backup pool be the same pool as your main pool cause any issues, if one is set to a typical name, and the other is a direct IP?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: SiegeBreaker on December 11, 2012, 11:16:22 PM

Quote from: -ck on December 10, 2012, 08:18:27 PM

...
cgminer times how long it takes for the gpu code to "return" after it's been given work. Unfortunately with windows, the timer resolution is so shithouse at 15ms that I have to sample many many iterations of the GPU code and then average them to see how long it took.
...

cklovias, there are several ways to overcome this drawback of the simple windows time functions. Probably the two easiest ways are using the code from this explanation http://msdn.microsoft.com/en-us/magazine/cc163996.aspx, or by using the .Net stopwatch class (for your code, you would have to call into a c++/cli dll wrapper around the class, then you have to deal with people needing the .Net framework installed too...maybe make it optional?)

I like using dynamic on my main windows computer, but I have been sticking with 2.7.5 because it has better dynamic behaviour for me. I have just been thinking, 'oh well, make it until the ASICs come out and that's good enough!'

Thanks for that but for such a convoluted process for the sake of one clock call when GPUs will be redundant in a couple of months seems a waste now - i.e. I'm not interested in developing in any significant fashion for GPUs any more. On the other hand, as you see from Kano's message, there are certainly other clock functions he implemented that suffer under windows that will be relevant to him.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: SiegeBreaker on December 11, 2012, 11:16:22 PM

Quote from: -ck on December 10, 2012, 08:18:27 PM

...
cgminer times how long it takes for the gpu code to "return" after it's been given work. Unfortunately with windows, the timer resolution is so shithouse at 15ms that I have to sample many many iterations of the GPU code and then average them to see how long it took.
...

cklovias, there are several ways to overcome this drawback of the simple windows time functions. Probably the two easiest ways are using the code from this explanation http://msdn.microsoft.com/en-us/magazine/cc163996.aspx, or by using the .Net stopwatch class (for your code, you would have to call into a c++/cli dll wrapper around the class, then you have to deal with people needing the .Net framework installed too...maybe make it optional?)

I like using dynamic on my main windows computer, but I have been sticking with 2.7.5 because it has better dynamic behaviour for me. I have just been thinking, 'oh well, make it until the ASICs come out and that's good enough!'

I've already found issues with USB and the fact that the clock is so unreliable on windows (XP).
This is where I've found more useful info (than msdn) to solve the problem - since MS themselves really don't seem to care, it seems pointless looking at msdn Tongue

http://www.geisswerks.com/ryan/FAQS/timing.html

DiCE1904

legendary

Activity: 1118

Merit: 1002

upgraded to 2.10.0 on my BAMT
in my config was I suppose to switch

Code:

"kernel" : "scrypt,scrypt,scrypt,scrypt",

to something else now? Im guessing this might have changed since 2.6.1 Huh

SiegeBreaker

newbie

Activity: 26

Merit: 0

Quote from: -ck on December 10, 2012, 08:18:27 PM

...
cgminer times how long it takes for the gpu code to "return" after it's been given work. Unfortunately with windows, the timer resolution is so shithouse at 15ms that I have to sample many many iterations of the GPU code and then average them to see how long it took.
...

cklovias, there are several ways to overcome this drawback of the simple windows time functions. Probably the two easiest ways are using the code from this explanation http://msdn.microsoft.com/en-us/magazine/cc163996.aspx, or by using the .Net stopwatch class (for your code, you would have to call into a c++/cli dll wrapper around the class, then you have to deal with people needing the .Net framework installed too...maybe make it optional?)

I like using dynamic on my main windows computer, but I have been sticking with 2.7.5 because it has better dynamic behaviour for me. I have just been thinking, 'oh well, make it until the ASICs come out and that's good enough!'

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