From mboxrd@z Thu Jan 1 00:00:00 1970 From: bugzilla-daemon@freedesktop.org Subject: [Bug 72785] bfgminer --scrypt on 7xxx+ Date: Mon, 24 Nov 2014 19:33:08 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1126878671==" Return-path: Received: from culpepper.freedesktop.org (unknown [131.252.210.165]) by gabe.freedesktop.org (Postfix) with ESMTP id 75B0B6EE6A for ; Mon, 24 Nov 2014 11:33:08 -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 --===============1126878671== Content-Type: multipart/alternative; boundary="1416857588.c368e4a33.3312"; charset="UTF-8" --1416857588.c368e4a33.3312 Date: Mon, 24 Nov 2014 19:33:08 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" https://bugs.freedesktop.org/show_bug.cgi?id=72785 --- Comment #38 from Linux User --- > 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? -- You are receiving this mail because: You are the assignee for the bug. --1416857588.c368e4a33.3312 Date: Mon, 24 Nov 2014 19:33:08 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 38 on bug 72785 from 
> 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?

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