Bitcoin Forum
December 03, 2016, 11:47:42 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 382 383 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4815079 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.
OgNasty
Donator
Legendary
*
Offline Offline

Activity: 2016


Powered by NastyFans


View Profile WWW
August 19, 2012, 01:01:30 AM
 #6641

I am occasionally running into a lot of stale shares that are causing high numbers of rejects on certain pools.  Mining with a BFL Single farm.  It would be great if the load-balance option automatically switched away from any pool that was getting stale shares until the next block.

BITSLER                 ▄███
               ▄████▀
             ▄████▀
           ▄████▀  ▄██▄
         ▄████▀    ▀████▄
       ▄████▀        ▀████▄
     ▄████▀            ▀████▄
   ▄████▀                ▀████▄
 ▄████▀ ▄████▄      ▄████▄ ▀████▄
█████   ██████      ██████   █████
 ▀████▄ ▀████▀      ▀████▀ ▄████▀
   ▀████▄                ▄████▀
     ▀████▄            ▄████▀
       ▀████▄        ▄████▀
         ▀████▄    ▄████▀
           ▀████▄▄████▀
             ▀██████▀
               ▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄            
▄▄▄▄▀▀▀▀    ▄▄█▄▄ ▀▀▄         
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄      
█  ▀▄▄  ▀█▀▀ ▄      ▀████   ▀▀▄   
█ █▄  ▀▄   ▀████       ▀▀ ▄██▄ ▀▀▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█  ▀▀       ▀▄▄ ▀████      ▄▄▄▀▀▀  █
█            ▄ ▀▄    ▄▄▄▀▀▀   ▄▄  █
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█ ▄▄   ███   ▀██  █           ▀▀  █ 
█ ███  ▀██       █        ▄▄      █ 
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀  
▀▄            █        ▀▀      █  
▀▀▄   ███▄  █   ▄▄          █   
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀    
▀▀▄   █   ▀▀▄▄▄▀▀▀         
▄▄▄▄▄▄▄▄▄▄▄█▄▄▀▀▀▀              
              ▄▄▄██████▄▄▄
          ▄▄████████████████▄▄
        ▄██████▀▀▀▀▀▀▀▀▀▀██████▄
▄     ▄█████▀             ▀█████▄
██▄▄ █████▀                ▀█████
 ████████            ▄██      █████
  ████████▄         ███▀       ████▄
  █████████▀▀     ▄███▀        █████
   █▀▀▀          █████         █████
     ▄▄▄         ████          █████
   █████          ▀▀           ████▀
    █████                     █████
     █████▄                 ▄█████
      ▀█████▄             ▄█████▀
        ▀██████▄▄▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████████▀▀
              ▀▀▀██████▀▀▀
            ▄▄▄███████▄▄▄
         ▄█▀▀▀ ▄▄▄▄▄▄▄ ▀▀▀█▄
       █▀▀ ▄█████████████▄ ▀▀█
     █▀▀ ███████████████████ ▀▀█
    █▀ ███████████████████████ ▀█
   █▀ ███████████████▀▀ ███████ ▀█
 ▄█▀ ██████████████▀      ▀█████ ▀█▄
███ ███████████▀▀            ▀▀██ ███
███ ███████▀▀                     ███
███ ▀▀▀▀                          ███
▀██▄                             ▄██▀
  ▀█▄                            ▀▀
    █▄       █▄▄▄▄▄▄▄▄▄█
     █▄      ▀█████████▀
      ▀█▄      ▀▀▀▀▀▀▀
        ▀▀█▄▄  ▄▄▄
            ▀▀█████
[]
1480765662
Hero Member
*
Offline Offline

Posts: 1480765662

View Profile Personal Message (Offline)

Ignore
1480765662
Reply with quote  #2

1480765662
Report to moderator
1480765662
Hero Member
*
Offline Offline

Posts: 1480765662

View Profile Personal Message (Offline)

Ignore
1480765662
Reply with quote  #2

1480765662
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480765662
Hero Member
*
Offline Offline

Posts: 1480765662

View Profile Personal Message (Offline)

Ignore
1480765662
Reply with quote  #2

1480765662
Report to moderator
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
August 19, 2012, 03:33:48 AM
 #6642

I am occasionally running into a lot of stale shares that are causing high numbers of rejects on certain pools.  Mining with a BFL Single farm.  It would be great if the load-balance option automatically switched away from any pool that was getting stale shares until the next block.
If a pool screws up somehow (and the proxy pools are the ones most likely to) and starts rejected *all* your shares, cgminer will disable it after 3 minutes and only re-enable it when it starts accepting shares again already.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
August 19, 2012, 03:35:16 AM
 #6643

Looks like ck.kolivas.org is unreachable :

Code:
$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org


Server being relocated.
Server is back online. All the files were unintentionally lost by the host provider, so I have had to upload from backups. Thus there will only be a limited number of downloads available, and only binaries from the latest release. I'd apologise for the inconvenience, but the inconvenience to me is far greater...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
August 19, 2012, 03:51:16 AM
 #6644

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

cablepair
Hero Member
*****
Offline Offline

Activity: 854


https://btc-republic.com/index.php?ref=cablepair


View Profile WWW
August 19, 2012, 04:01:28 AM
 #6645

Looks like ck.kolivas.org is unreachable :

Code:
$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org


Server being relocated.
Server is back online. All the files were unintentionally lost by the host provider, so I have had to upload from backups. Thus there will only be a limited number of downloads available, and only binaries from the latest release. I'd apologise for the inconvenience, but the inconvenience to me is far greater...

ckvoilvas

I highly recommend you move your hosting to BTCWebHost.com, we are the oldest and most trusted Bitcoin accepting hosting provider in the world. You will never have to worry about anything like this happening again and best of all you can pay in Bitcoin.

-Tom
BTCWebHost.com
Bitcoinwebhost.com
Bitcoinwebhosting.com
BitcoinVPS.com
MiningBuddy
Moderator
Legendary
*
Offline Offline

Activity: 1058


฿itcoin ฿itcoin ฿itcoin


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

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.

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


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

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...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
nima
Full Member
***
Offline Offline

Activity: 176


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

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
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


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

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Askit2
Hero Member
*****
Offline Offline

Activity: 524


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

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.

I appreciate donations at ( 1NwkQdmomQPLtdes5KuZhB1D22p7ZGRy4p )
If I am helping in the CGMiner thread give it to Con or Kano. They do the work there.
If you want to sign up for a coinbase account I would appreciate it if you use my referral link. US people now wire, 1% fee give or take a little for sending to your bank account. https://coinbase.com/?r=515bf6145682db9d11000028&utm_campaign=user-referral&src=
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


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

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!

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
The00Dustin
Hero Member
*****
Offline Offline

Activity: 806


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

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
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


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

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
farfie
Jr. Member
*
Offline Offline

Activity: 58



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

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
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


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

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
farfie
Jr. Member
*
Offline Offline

Activity: 58



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

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:

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 ) :

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: 1918


Think for yourself


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

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: 1918


Think for yourself


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

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
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


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

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).

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


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

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

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 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 382 383 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!