From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 72785] bfgminer --scrypt on 7xxx+ Date: Wed, 26 Nov 2014 17:07:34 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1806291009==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id D21C76E419 for ; Wed, 26 Nov 2014 09:07:34 -0800 (PST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1806291009== Content-Type: multipart/alternative; boundary="1417021654.AaA51DaF3.20866"; charset="UTF-8" --1417021654.AaA51DaF3.20866 Date: Wed, 26 Nov 2014 17:07:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=72785 --- Comment #40 from Tom Stellard --- (In reply to Linux User from comment #38) > > Do you have an X server running? > I am (on one of GPUs). And I can understand X could be slow, etc and > adjusting intensity on GPU sharing X server is well known thing to me. > > But I'm talking about GPU lockups. When GPU crashes due to ring stall and > driver have to restart it, its likely something else failing? Somehow, > attempts to run bfgminer --scrypt with high intensity often can provoke ring > stalls. > > > drm.rnodes=1 to your kernel command line. > Cool, but... > 1) It could be nice to view output on separate monitor and graphic terminal > looks better than just framebuffer console. At least in trial runs I would > prefer to deal with my favorite terminal, adjusting intensity of 1st GPU a > bit. > 2) I do not think apps should be cause fatal GPU deadlocks, effectively > screwing all graphics, system-wide. > > Though thanks for render nodes hint - sounds like it can be really valuable > thing to try on some headless machines, etc. > > P.S. also there is another silly issue. If I just install Ubuntu and run > bfgminer on multi-GPU setup within X session, it would only see 1st GPU > (where X server running). Remaining GPUs are not detected. Fix is to either > run bfgminer as root (extremely unsafe!!!) or create new user and make > "video" it's primary group. The user who installs Ubuntu is a member of > "video" group, but "video" is his secondary group, which is very common. > Somehow, kernel seems to disregard permissions in such case and would issue > -EPERM on certain syscall, making bfgminer unable to find GPUs except one > used by X. Generally it means that user can't use more than 1 GPU unless he > is either root (very dangerous!) or video is his primary group (inconvenient > and uncommon). I believe it is a bug and I should file it? Since I fail to > understand how average Joe would be able to use some OpenCL program in > multi-GPU setup and get it working "by default" on all available GPUs. I > guess I should file it as new bug? Is it kernel issue or MESA, etc? Enabling rendernodes should make both GPUs visible. -- You are receiving this mail because: You are the assignee for the bug. --1417021654.AaA51DaF3.20866 Date: Wed, 26 Nov 2014 17:07:34 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 40 on bug 72785 from 
(In reply to Linux User from comment #38)
> > Do you have an X server running?
> I am (on one of GPUs). And I can understand X could be slow, etc and
> adjusting intensity on GPU sharing X server is well known thing to me.
> 
> But I'm talking about GPU lockups. When GPU crashes due to ring stall and
> driver have to restart it, its likely something else failing? Somehow,
> attempts to run bfgminer --scrypt with high intensity often can provoke ring
> stalls.
> 
> > drm.rnodes=1 to your kernel command line.
> Cool, but...
> 1) It could be nice to view output on separate monitor and graphic terminal
> looks better than just framebuffer console. At least in trial runs I would
> prefer to deal with my favorite terminal, adjusting intensity of 1st GPU a
> bit.
> 2) I do not think apps should be cause fatal GPU deadlocks, effectively
> screwing all graphics, system-wide.
> 
> Though thanks for render nodes hint - sounds like it can be really valuable
> thing to try on some headless machines, etc.
> 
> P.S. also there is another silly issue. If I just install Ubuntu and run
> bfgminer on multi-GPU setup within X session, it would only see 1st GPU
> (where X server running). Remaining GPUs are not detected. Fix is to either
> run bfgminer as root (extremely unsafe!!!) or create new user and make
> "video" it's primary group. The user who installs Ubuntu is a member of
> "video" group, but "video" is his secondary group, which is very common.
> Somehow, kernel seems to disregard permissions in such case and would issue
> -EPERM on certain syscall, making bfgminer unable to find GPUs except one
> used by X. Generally it means that user can't use more than 1 GPU unless he
> is either root (very dangerous!) or video is his primary group (inconvenient
> and uncommon). I believe it is a bug and I should file it? Since I fail to
> understand how average Joe would be able to use some OpenCL program in
> multi-GPU setup and get it working "by default" on all available GPUs. I
> guess I should file it as new bug? Is it kernel issue or MESA, etc?


Enabling rendernodes should make both GPUs visible.

You are receiving this mail because:
  • You are the assignee for the bug.
--1417021654.AaA51DaF3.20866-- --===============1806291009== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK --===============1806291009==--