Bitcoin Forum
May 06, 2024, 01:34:28 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Arrrghhh ... reboot issue due to software  (Read 1608 times)
Legion (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
June 19, 2011, 04:51:02 AM
 #1

So, I'm trying to run Phoenix Phatk on my dual 6870s (not crossfired), and some kind of software problem with phoenix makes the system reboot within two or three minutes once both cards are mining. This had me chasing my own tail forever until I realized it was a software problem and not an issue with my hardware. Extensive stress testing confirms this with certainty.

GPU clock is 975MHZ, RAM clock is 1100 MHZ.

No artifacts. Ever. No rejected shares, ever.

Either card can mine alone -- forever.

Both cards can run their own copy of furmark -- forever. No errors.

One card can run Shogun 2 maxed (90+% GPU usage at all times, identical thermals to Bitcoin mining) while the other mines coins. No issues.

Both cards can mine fine together IF AND ONLY IF one has no arguments set with Phoenix. I lose TONS of hashing power on that card (280-->230.)

The arguments I use follow: k phatk VECTORS BFI_INT AGGRESSION=8 worksize=128

So uhhh .... any ideas? Try poclbm on one card? I'm running Catalyst 11.5 with the 2.4 Stream SDK. Phoenix 1.48 with the included phatk version.
1714959268
Hero Member
*
Offline Offline

Posts: 1714959268

View Profile Personal Message (Offline)

Ignore
1714959268
Reply with quote  #2

1714959268
Report to moderator
1714959268
Hero Member
*
Offline Offline

Posts: 1714959268

View Profile Personal Message (Offline)

Ignore
1714959268
Reply with quote  #2

1714959268
Report to moderator
1714959268
Hero Member
*
Offline Offline

Posts: 1714959268

View Profile Personal Message (Offline)

Ignore
1714959268
Reply with quote  #2

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

Posts: 1714959268

View Profile Personal Message (Offline)

Ignore
1714959268
Reply with quote  #2

1714959268
Report to moderator
1714959268
Hero Member
*
Offline Offline

Posts: 1714959268

View Profile Personal Message (Offline)

Ignore
1714959268
Reply with quote  #2

1714959268
Report to moderator
EpicBacon
Member
**
Offline Offline

Activity: 94
Merit: 10


View Profile
June 19, 2011, 03:05:21 PM
 #2

This probably will not help, but try worksize=256 ?
jgraham
Full Member
***
Offline Offline

Activity: 140
Merit: 100


<Pretentious and poorly thought out latin phrase>


View Profile
June 19, 2011, 03:24:26 PM
 #3

The arguments I use follow: k phatk VECTORS BFI_INT AGGRESSION=8 worksize=128

So uhhh .... any ideas? Try poclbm on one card? I'm running Catalyst 11.5 with the 2.4 Stream SDK. Phoenix 1.48 with the included phatk version.

Have you tried systematically removing kernel arguments until the system is stable?

I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
Legion (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
June 19, 2011, 03:30:11 PM
 #4

Thought I found it when I removed aggression from one card. It lasted a good 15 minutes. Vectors maybe? This is just slightly annoying because if my system ever shuts down unexpectedly, my RAID driver automatically starts verifying the array, which makes the system take forever to start back up.
jgraham
Full Member
***
Offline Offline

Activity: 140
Merit: 100


<Pretentious and poorly thought out latin phrase>


View Profile
June 19, 2011, 05:06:37 PM
 #5

Thought I found it when I removed aggression from one card. It lasted a good 15 minutes. Vectors maybe? This is just slightly annoying because if my system ever shuts down unexpectedly, my RAID driver automatically starts verifying the array, which makes the system take forever to start back up.

I used to be there, I have ten 1.5TB drives in my array.   When I upgraded I saw that the build time was almost a whole day.  So I switched to ZFS.

I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
Legion (OP)
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
June 19, 2011, 09:02:28 PM
 #6

Solved .. I think. It was apparently my OC of just 950 core. I dropped to 900 and have had both mining contently for more than an hour. Weird that Furmark, Shogun 2, and Haven don't reveal this. MW2 had driver crashes at 960-ish, so I've just dropped down to 900 again. My hash rates have dropped by ~30-40 on each card though :\. I'll try to get away with 930 tomorrow. I need to mine to make up for all the lost time.
jgraham
Full Member
***
Offline Offline

Activity: 140
Merit: 100


<Pretentious and poorly thought out latin phrase>


View Profile
June 20, 2011, 01:54:23 AM
 #7

Solved .. I think. It was apparently my OC of just 950 core. I dropped to 900 and have had both mining contently for more than an hour. Weird that Furmark, Shogun 2, and Haven don't reveal this. MW2 had driver crashes at 960-ish, so I've just dropped down to 900 again. My hash rates have dropped by ~30-40 on each card though :\. I'll try to get away with 930 tomorrow. I need to mine to make up for all the lost time.

Believe it or not I was still convinced this was hardware.  ;-) Applications, even ones designed to stress the GPU do not load your system identically.  Even with same core temp and the same % load.  For example a complex instruction like a BFI_INT might break under higher clocks/thermals because it's only just barely meeting the timing requirements under normal clocks/thermals.  A benchmark is not guaranteed to execute every low-level instruction a card can perform (and is likely not going to execute ones that are hardware specific).

J.

I'm rather good with Linux.  If you're having problems with your mining rig I'll help you out remotely for 0.05.  You can also propose a flat-rate for some particular task.  PM me for details.
dishwara
Legendary
*
Offline Offline

Activity: 1855
Merit: 1016



View Profile
June 20, 2011, 07:05:59 AM
 #8

Reduce memory clock to ~300+. I have many times happened crashing of not only phoenix, but other miners also.
If i OC without reducing mem clock first then system freezes.
So, i always under clock memory manually with Afterburner, as mem clk CANNOT be reduce automatically, up to 300 then i apply OC.
Even though in Afterburner i saved the OC as 993/331, it will OC only core clock but can't under clock memory.
Just under clock memory & everything work fine.
Pages: [1]
  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!