Bitcoin Forum
March 19, 2024, 11:54:13 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 [331] 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 ... 843 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5805147 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (3 posts by 1+ user deleted.)
MiningBuddy
Hero Member
*****
Offline Offline

Activity: 927
Merit: 1000


฿itcoin ฿itcoin ฿itcoin


View Profile
August 19, 2012, 04:08:35 AM
 #6601

Still getting intensity pegging down to -10 on dynamic threads on win 7 x64.  At the same time, when it drops to -10, cgminer starts eating up a whole core of CPU power.   Undecided

This change happened sometime after 2.6.1.  Probably related to to the change in how cgminer handles dynamic intensity that was in 2.6.5, not 100% sure though since my update path was 2.6.1, 2.6.5, 2.7.0.  First saw it in 2.6.5.  Does not happen in 2.6.1.

Any GPU set to dynamic intensity will eventually peg to -10.  Sometimes very shortly after starting, sometimes after running for a while.  I have not yet been able to figure out what the trigger is.

Tested with a clean copy of 2.7.0 with no prefs file after a cold system reboot.
I can confirm the same bug with intensity pegging down to -10 on dynamic but in my instance without the high CPU usage.
I upgraded from 2.6.4 which didn't have the problem.

1710849253
Hero Member
*
Offline Offline

Posts: 1710849253

View Profile Personal Message (Offline)

Ignore
1710849253
Reply with quote  #2

1710849253
Report to moderator
1710849253
Hero Member
*
Offline Offline

Posts: 1710849253

View Profile Personal Message (Offline)

Ignore
1710849253
Reply with quote  #2

1710849253
Report to moderator
1710849253
Hero Member
*
Offline Offline

Posts: 1710849253

View Profile Personal Message (Offline)

Ignore
1710849253
Reply with quote  #2

1710849253
Report to moderator
BitcoinCleanup.com: Learn why Bitcoin isn't bad for the environment
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710849253
Hero Member
*
Offline Offline

Posts: 1710849253

View Profile Personal Message (Offline)

Ignore
1710849253
Reply with quote  #2

1710849253
Report to moderator
1710849253
Hero Member
*
Offline Offline

Posts: 1710849253

View Profile Personal Message (Offline)

Ignore
1710849253
Reply with quote  #2

1710849253
Report to moderator
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
August 19, 2012, 04:11:13 AM
 #6602

Still getting intensity pegging down to -10 on dynamic threads on win 7 x64.  At the same time, when it drops to -10, cgminer starts eating up a whole core of CPU power.   Undecided

This change happened sometime after 2.6.1.  Probably related to to the change in how cgminer handles dynamic intensity that was in 2.6.5, not 100% sure though since my update path was 2.6.1, 2.6.5, 2.7.0.  First saw it in 2.6.5.  Does not happen in 2.6.1.

Any GPU set to dynamic intensity will eventually peg to -10.  Sometimes very shortly after starting, sometimes after running for a while.  I have not yet been able to figure out what the trigger is.

Tested with a clean copy of 2.7.0 with no prefs file after a cold system reboot.
I can confirm the same bug with intensity pegging down to -10 on dynamic but in my instance without the high CPU usage.
I upgraded from 2.6.4 which didn't have the problem.
Yes it's definitely a bug introduced in 2.6.5 when I tried to work around windows' timers. Why, I dunno cause I can only try it on a laptop with windows that does 9.5Mhash so it's not a very useful piece of hardware to test it on...

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
nima
Full Member
***
Offline Offline

Activity: 176
Merit: 100


View Profile WWW
August 19, 2012, 08:35:26 AM
 #6603

Hi ckolivas,
I have an issue with one of the rigs (2 x 5850), no matter which version of cgminer I use. GPU1 dies in matter of a couple of hours, rig does not respond, sometimes a hard reset is inevitable.
The system runs:
CentOS 6.3
kernel 2.6.32-279.5.1.el6.x86_64
glibc-2.12-1.80.el6_3.4.x86_64
glib2-2.22.5-7.el6.x86_64
gcc-4.4.6-4.el6.x86_64
AMD-APP-SDK-v2.5-lnx64
ati-driver-installer-11-12-x86.x86_64

I tried the latest cgminer-2.7.0, not using any optimizations at all except intensity set to 2. The following is grabbed from /var/log/messages.
--------------------------------------------------------------------------------------------------------------------------------------
Aug 19 06:08:21 hostname kernel: [fglrx] ASIC hang happened
Aug 19 06:08:21 hostname kernel: Pid: 3430, comm: cgminer Tainted: P           ---------------    2.6.32-279.5.1.el6.x86_64 #1
Aug 19 06:08:21 hostname kernel: Call Trace:
Aug 19 06:08:21 hostname kernel: [<ffffffffa0210c1e>] ? KCL_DEBUG_OsDump+0xe/0x10 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa021e24c>] ? firegl_hardwareHangRecovery+0x1c/0x50 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa02b3ad9>] ? _ZN4Asic9WaitUntil15ResetASICIfHungEv+0x9/0x10 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa02b3a7c>] ? _ZN4Asic9WaitUntil15WaitForCompleteEv+0x9c/0xf0 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa02ae3bf>] ? _ZN4Asic19PM4ElapsedTimeStampEj14_LARGE_INTEGER12_QS_CP_RING_+0xaf/0x170 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa023ae62>] ? firegl_trace+0x72/0x1e0 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa023ae62>] ? firegl_trace+0x72/0x1e0 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa02a77a3>] ? _ZN15QS_PRIVATE_CORE27multiVpuPM4ElapsedTimeStampEj14_LARGE_INTEGER12_QS_CP_RIN G_+0x33/0x50 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa02a0044>] ? _Z19uQSTimeStampRetiredmjj14_LARGE_INTEGER+0x74/0x80 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa029becd>] ? _Z8uCWDDEQCmjjPvjS_+0x54d/0x10c0 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffff81097ede>] ? down+0x2e/0x50
Aug 19 06:08:21 hostname kernel: [<ffffffffa023d432>] ? firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa023bd60>] ? firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa023bcf0>] ? firegl_cmmqs_CWDDE32+0x0/0x100 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffffa0219ded>] ? firegl_ioctl+0x1ed/0x250 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffff8104452c>] ? __do_page_fault+0x1ec/0x480
Aug 19 06:08:21 hostname kernel: [<ffffffffa020f93e>] ? ip_firegl_unlocked_ioctl+0xe/0x20 [fglrx]
Aug 19 06:08:21 hostname kernel: [<ffffffff8118dff2>] ? vfs_ioctl+0x22/0xa0
Aug 19 06:08:21 hostname kernel: [<ffffffff8118e194>] ? do_vfs_ioctl+0x84/0x580
Aug 19 06:08:21 hostname kernel: [<ffffffff8118e711>] ? sys_ioctl+0x81/0xa0
Aug 19 06:08:21 hostname kernel: [<ffffffff8100b0f2>] ? system_call_fastpath+0x16/0x1b
Aug 19 06:08:21 hostname kernel: pubdev:0xffffffffa049ed20, num of device:2 , name:fglrx, major 8, minor 92.
Aug 19 06:08:21 hostname kernel: device 0 : 0xffff88007a1b0000 .
Aug 19 06:08:21 hostname kernel: Asic ID:0x6899, revision:0x2, MMIOReg:0xffffc90000340000.
Aug 19 06:08:21 hostname kernel: FB phys addr: 0xd0000000, MC :0xf00000000, Total FB size :0x40000000.
Aug 19 06:08:21 hostname kernel: gart table MC:0xf0fb27000, Physical:0xdfb27000, size:0x1d8000.
Aug 19 06:08:21 hostname kernel: mc_node :FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf00000000, Physical:0xd0000000, size:0xfd00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0xfb27000, reference count:21, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x1000000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xfb27000, size:0x1d9000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :INV_FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf0fd00000, Physical:0xdfd00000, size:0x30300000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x302f4000, size:0xc000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_USWC, total 2 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x260c0000, Physical:0x0, size:0x24c00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x2000000, reference count:21, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_CACHEABLE, total 3 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x10400000, Physical:0x0, size:0x15cc0000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1500000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1400000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1300000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1200000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1100000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1000000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xf00000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xe00000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xd00000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xb00000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x800000, size:0x300000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x500000, size:0x300000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x200000, size:0x300000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x200000, reference count:6, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xef000, size:0x11000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: GRBM : 0xb0633828, SRBM : 0x20000ec0 .
Aug 19 06:08:21 hostname kernel: CP_RB_BASE : 0x260c00, CP_RB_RPTR : 0x1920 , CP_RB_WPTR :0x1920.
Aug 19 06:08:21 hostname kernel: CP_IB1_BUFSZ:0x0, CP_IB1_BASE_HI:0x0, CP_IB1_BASE_LO:0x2686f000.
Aug 19 06:08:21 hostname kernel: last submit IB buffer -- MC :0x2686f000,phys:0x7b4f5000.
Aug 19 06:08:21 hostname kernel: device 1 : 0xffff88003759c000 .
Aug 19 06:08:21 hostname kernel: Asic ID:0x6899, revision:0x2, MMIOReg:0xffffc90004980000.
Aug 19 06:08:21 hostname kernel: FB phys addr: 0xe0000000, MC :0xf00000000, Total FB size :0x40000000.
Aug 19 06:08:21 hostname kernel: gart table MC:0xf0fb27000, Physical:0xefb27000, size:0x1d8000.
Aug 19 06:08:21 hostname kernel: mc_node :FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf00000000, Physical:0xe0000000, size:0xfd00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0xfb27000, reference count:20, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x1000000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xfb27000, size:0x1d9000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :INV_FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf0fd00000, Physical:0xefd00000, size:0x30300000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x302f4000, size:0xc000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_USWC, total 2 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x260c0000, Physical:0x0, size:0x24c00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x2000000, reference count:21, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_CACHEABLE, total 3 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x10400000, Physical:0x0, size:0x15cc0000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2c00000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2b00000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2a00000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2900000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2800000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2600000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1d00000, size:0x900000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1400000, size:0x900000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xb00000, size:0x900000, reference count:3, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x200000, size:0x900000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x200000, reference count:5, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xef000, size:0x11000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: GRBM : 0xb0633828, SRBM : 0x200006c0 .
Aug 19 06:08:21 hostname kernel: CP_RB_BASE : 0x260c00, CP_RB_RPTR : 0x6970 , CP_RB_WPTR :0x6990.
Aug 19 06:08:21 hostname kernel: CP_IB1_BUFSZ:0x0, CP_IB1_BASE_HI:0x0, CP_IB1_BASE_LO:0x262e7000.
Aug 19 06:08:21 hostname kernel: last submit IB buffer -- MC :0x262e7000,phys:0x693c3000.
Aug 19 06:08:21 hostname kernel: Dump the trace queue.
Aug 19 06:08:21 hostname kernel: End of dump
-----------------------------------------------------------------------------------------------------------------------------------

Can you see anything that causes the problem?
Thx in advance.
 
 

Coin Reaper @ http://coinreaper.com - Your expressway to FREE Bitcoins!
Bunny Run @ http://bunnyrun.us and win every time. No Bets required
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
August 19, 2012, 08:45:43 AM
 #6604

Your crash is entirely within the AMD driver, so either you are having a hardware problem (dodgy card, too much overclocking, overheated vrms etc) or a driver problem. Can't see anything in the backtrace related to cgminer.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Askit2
Hero Member
*****
Offline Offline

Activity: 981
Merit: 500


DIV - Your "Virtual Life" Secured and Decentralize


View Profile
August 19, 2012, 09:42:52 AM
 #6605

I have some of your old windows binaries. Not sure if it would be any help for you.
I have 2.4.4, 2.5.0, 2.6.2, 2.6.3, 2.6.4, 2.6.5 and the current 2.7.0 I didn't grab 2.6.0 or 2.6.1 because of BFL issues and since I only have a single to mine with it didn't seem helpful.

Thank You for making WU field. My backup pool uses difficulty 8 shares so I used to have to use just the average because U would be lower due to occasional work from backup pool. My Rejects are maybe 10% of what 2.6.5 had me at. I have had 0 hardware issues today all issues where throttling related and today was cooler, my average is so far 11 Mhash faster and my U is maybe lower but WU is at 12. Very short test so far only hours not days to fully break in the averages but still.

So far it works great for me, no pool slow to provide work, averge higher, shares bleeding to the backup so I get paid rather then a delay on working.

          ▄▄
        ▄█▀▀█▄
      ▄█▀ ▄▄ ▀█▄
      ▀ ▄████▄ ▀
   ▄▀ ▄ ▀████▀ ▄ ▀▄
 ▄▀ ▄███▄ ▀▀ ▄███▄ ▀▄
█  ███████  ███████  █
 ▀▄ ▀███▀ ▄▄ ▀███▀ ▄▀

   ▀▄ ▀ ▄████▄ ▀ ▄▀
      ▄ ▀████▀ ▄
      ▀█▄ ▀▀ ▄█▀
        ▀█▄▄█▀
          ▀▀
███████████████████████████████████████████████████████████████████
██████▀▀▀▀▀▀▀▀▀▀▀██████████▀▀▀▀▀████▀▀▀▀▀█████▀▀▀▀█████▀▀▀▀▀███████
██████            ▀████████     ████     █████    █████     ███████
██████     ▄▄▄▄▄    ▀██████     █████    ████      ████    ████████
██████     ██████▄    █████     █████    ▀██▀  ▄▄  ▀██▀    ████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████    ██   ██   ██    █████████
██████     ███████    █████     ██████     █   ██   █     █████████
██████     █████▀    ██████     ███████       ████       ██████████
██████     ▀▀▀▀▀    ▄██████     ████████     ██████     ███████████
██████            ▄████████     ████████     ██████     ███████████
██████▄▄▄▄▄▄▄▄▄▄▄██████████▄▄▄▄▄█████████▄▄▄▄██████▄▄▄▄████████████
███████████████████████████████████████████████████████████████████
.DIWtoken.com.
▄██████████████████▄
███       ▀███████
███       █████████
███       █████████
███       █████████
███              ██
███   ▄▄▄▄▄▄▄▄   ███
███   ▄▄▄▄▄▄▄▄   ███
███              ███
███▄▄▄▄▄▄▄▄▄▄▄▄▄▄███
██████████████████▀

▄██████████████████▄
███████████▀ ███████
█████████▀   ███████
███████▀     ██▀ ███
███ ▀▀       █▄▄████
███          █▀▀▀▀██
███ ▄▄       ███████
██████▄     █▄ ▀███
█████████▄   ███▄███
███████████▄ ███████
▀██████████████████▀

▄██████████████████▄
████████████████████
███████████████▀▀ ██
█████████▀▀     ███
████▀▀     ▄█▀   ███
███▄    ▄██      ███
█████████▀      ▄██
█████████▄     ████
█████████████▄ ▄████
████████████████████
▀██████████████████▀
......SECURITY DECENTRALIZED...
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
August 19, 2012, 09:45:05 AM
 #6606

I have some of your old windows binaries. Not sure if it would be any help for you.
I have 2.5.0, 2.6.2, 2.6.3, 2.6.4, 2.6.5 and the current 2.7.0 I didn't grab 2.6.0 or 2.6.1 because of BFL issues and since I only have a single to mine with it didn't seem helpful.

Thank You for making WU field. My backup pool uses difficulty 8 shares so I used to have to use just the average because U would be lower due to occasional work from backup pool. My Rejects are maybe 10% of what 2.6.5 had me at. I have had 0 hardware issues today all issues where throttling related and today was cooler, my average is so far 11 Mhash faster and my U is maybe lower but WU is at 12. Very short test so far only hours not days to fully break in the averages but still.

So far it works great for me, no pool slow to provide work, averge higher, shares bleeding to the backup so I get paid rather then a delay on working.
Great feedback, thanks. Please email me the old binaries kernel@kolivas.org (one at a time or email will reject them), thanks!

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
The00Dustin
Hero Member
*****
Offline Offline

Activity: 807
Merit: 500


View Profile
August 19, 2012, 10:44:32 AM
 #6607

Con, I hope quoting this so you can see it doesn't come off wrong:
I looked into the "Switch User" hang reported originally in CGMiner.

It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.

Thanks,

Luke
The issue doesn't affect me, and presumably Kano has already seen it and could even be dealing with it, but I figure better safe than sorry, and this particular post seems both civil and useful enough to be worthy of your time.
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
August 19, 2012, 12:31:47 PM
 #6608

Con, I hope quoting this so you can see it doesn't come off wrong:
I looked into the "Switch User" hang reported originally in CGMiner.

It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.

Thanks,

Luke
The issue doesn't affect me, and presumably Kano has already seen it and could even be dealing with it, but I figure better safe than sorry, and this particular post seems both civil and useful enough to be worthy of your time.
Thanks, much appreciate the useful filtering, and thanks luke-jr for your debugging.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
farfie
Newbie
*
Offline Offline

Activity: 63
Merit: 0



View Profile
August 19, 2012, 01:27:11 PM
 #6609

I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo.

I am so confused, haha. Huh
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
August 19, 2012, 01:29:42 PM
 #6610

I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo.

I am so confused, haha. Huh
It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
farfie
Newbie
*
Offline Offline

Activity: 63
Merit: 0



View Profile
August 19, 2012, 02:33:55 PM
 #6611

It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.
I see...

But, and I hate to pester, that raises so many questions in my head. Wouldn't doing that mean my machines are definitely not working anywhere near what they're supposed to be? And then, if bitcoind is really THAT slow, I don't see how solo mining was ever worth it.. here's a picture of solo mining with one bfl single for ~30 minutes. This was the only device solo mining on the network at the time:
https://i.imgur.com/tRgwI.png
More than half of the work is going toward pool 2 (pool 1 is down, probably a coincidence). I mean, is it only not complaining that pool 0 is too slow because it can grab work from pool 2? Or is it designed to not put those kinds of errors when soloing? Pretty sure I've seen them before when solo, on an NB or something..

Here we have soloing now with --failover-only, ~45 minutes, everything else the same (even pool 1 is still down  Grin ) :
https://i.imgur.com/kYkXO.png
Sorry about the disparity in uptime, but the last prompt makes me believe that bitcoind is only fast enough to provide half of what the single can handle. Temps are also the same, so it's safe to assume the single is being worked pretty closely to the last prompt as well. Everything is the same.. not sure if that matters but it seems to matter.

But if I'm misunderstanding all of this, which is fine; what is the "limit" of bitcoind in GH/s? Will solo'ing on one of those new ASIC mini-rigs basically be a no-go? I appreciate learning about this as it interests me greatly.
os2sam
Legendary
*
Offline Offline

Activity: 3577
Merit: 1090


Think for yourself


View Profile
August 19, 2012, 03:11:44 PM
 #6612

I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo.

I am so confused, haha. Huh
It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.

I just tried enabling solo mining on my machine and initially it leaked some shares to the backup pools and then again when there was a new block, but then it settles down and mines solo till the next block and repeats the cycle.

This seems like normal behavior to me.  This machine uses two GPU's at about 510Mhs.
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
os2sam
Legendary
*
Offline Offline

Activity: 3577
Merit: 1090


Think for yourself


View Profile
August 19, 2012, 03:15:19 PM
 #6613

Please email me the old binaries kernel@kolivas.org (one at a time or email will reject them), thanks!

I have almost all the Windoze binaries from 2.0 to current.  Do you want all of them?  Let me know I would be happy to email them to you.
Thanks,
Sam

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
August 19, 2012, 03:21:05 PM
 #6614

I must be misunderstanding something, or perhaps the default is different and I don't know it? But when I'm solo mining, tons of shares are going to other pools. But it doesn't happen when I'm not solo.. is there some kind of flag I need to use? It's acting like --balance when it's not enabled, only when I'm solo mining though. I would take from this that --balance is the new default, but it's not like it does that if I simply change to work for a pool instead of going solo.

I am so confused, haha. Huh
It's not the default, it's just that a local bitcoind is actually really quite slow compared to a pool. You probably want to enable --failover-only to cope.

I just tried enabling solo mining on my machine and initially it leaked some shares to the backup pools and then again when there was a new block, but then it settles down and mines solo till the next block and repeats the cycle.

This seems like normal behavior to me.  This machine uses two GPU's at about 510Mhs.
Sam
Very much depends on local hardware capabilities and network conditions it seems. Clearly in farfie's case it's just barely keeping up and cgminer is detecting it. Note that farfie's actual WU is the same mining in failover-only, so it's actually enough to keep the singles busy, but cgminer notes the buffer dropping very low often and ends up sending it elsewhere... either that or farfie has a different mode set up and doesn't know it (like in a configuration file that cgminer is loading without him knowing).

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
August 19, 2012, 03:53:27 PM
 #6615

On second thought, there may be a bug here... will investigate tomorrow.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
farfie
Newbie
*
Offline Offline

Activity: 63
Merit: 0



View Profile
August 19, 2012, 04:03:46 PM
 #6616

On second thought, there may be a bug here... will investigate tomorrow.

I suppose I'll start integrity checking some of my equipment. The route from this single to my bitcoind is windows client -> router -> switch -> windows host. I am thinking the switch is perhaps seeing the end of its days if it does not result as a bug. But I never really noticed any performance problems with anything... I could perhaps try downloading something that would max my bandwidth on the bitcoind machine, or comparing speedtest results between it and my machine that's not behind the switch.

Sorry, not related to cgminer, but my fingers are moving on their own...
crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
August 19, 2012, 04:56:49 PM
 #6617

My E: went from ~175% to 1200% after about 10k shares. Is that what you were expecting?

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
August 19, 2012, 05:14:05 PM
 #6618

My E: went from ~175% to 1200% after about 10k shares. Is that what you were expecting?

My efficiency is through the roof with this new version.

miner with one GPU after 13k shares: 5316%
miner with three GPUs after 40k shares: 50336%
miner with four GPUs after 56k shares: 4516%

the 2nd one looks funny to me, but it's what cgminer is reporting.

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
Nite69
Sr. Member
****
Offline Offline

Activity: 477
Merit: 500


View Profile
August 19, 2012, 07:26:30 PM
 #6619

Hi!

Testing version 2.6.4 on Ubuntu 12.04, found a (minor) bug, but I think it could be an older one. Yesterday I configured my system to use the onboard GPU (3300) for display and the PCIe card (5770) for mining only. Unfortunately, ADL and CL GPU mapping does not seem to work.


---
Nite69
WalletId: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp

Much appreciated, thanks!

Hi!

Unfortunately, this problem reappears on 2.7.0. I think the problem is on line (see the patch)
Code:
gpus[gpu].virtual_gpu = vadapters[gpu].virtual_gpu;
Same index should not be used on both tables. In my case gpus[0] refers to 5770 (mining GPU) and vadapters[0] refers to 3300 (cannot mine). This line connects 5770 ADL device to be 3300, regardless of the --gpu-map configuration. gpus[0] *should* be conected to vadapters[1] as mapped with --gpu-map.

Git log tells me there was some problem with the patch I submitted. Can you (or someone) clarify where the problem was?
---
Nite69
WalletId: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp

Sync: ShiSKnx4W6zrp69YEFQyWk5TkpnfKLA8wx
Bitcoin: 17gNvfoD2FDqTfESUxNEmTukGbGVAiJhXp
Litecoin: LhbDew4s9wbV8xeNkrdFcLK5u78APSGLrR
AuroraCoin: AXVoGgYtSVkPv96JLL7CiwcyVvPxXHXRK9
-ck (OP)
Legendary
*
Offline Offline

Activity: 4046
Merit: 1622


Ruu \o/


View Profile WWW
August 19, 2012, 09:57:09 PM
 #6620


Git log tells me there was some problem with the patch I submitted. Can you (or someone) clarify where the problem was?
It crashes other rigs completely. Presumably the -lack- of a gpumap breaks it completely and tries to tie everything to device 0. I'll look into re-importing your patch and making it work.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 ... 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 [331] 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 ... 843 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!