search for: reclocks

> Samuel Pitoiset <samuel.pitoiset at gmail.com> hat am 13. Januar 2016 um 13:43 > geschrieben: > > Hi! > > Did you check on different Fermi chipsets or only with one variant? currently I only checked that on my nvc1, but I thought I could just send the patches and it is easier for others to try it out this way. > > Are you sure that engine reclocking works as

On 11/06/2014 13:59, Roy Spliet wrote: > Dear Mr. Dew, > > I hereby wish to propose the X.org EVoC project "REclock - > Reverse-engineer and implement NVA3/5/8 Voltage- and Frequency Scaling > in Nouveau" for which I am willing to participate, and apply for the > associated funding. Full details below or on > http://nouveau.spliet.org/evoc.html . For any further

On 01/13/2016 01:49 PM, Karol Herbst wrote: >> Samuel Pitoiset <samuel.pitoiset at gmail.com> hat am 13. Januar 2016 um 13:43 >> geschrieben: >> >> Hi! >> >> Did you check on different Fermi chipsets or only with one variant? > > currently I only checked that on my nvc1, but I thought I could just send the > patches and it is easier for others to

...MHz voltage 1030mV [ 2.719992] nouveau [ DRM] c: core 405MHz shader 810MHz memory 405MHz voltage 850mV echo 3 > /sys/class/drm/card0/device/performance_level run opengl app (I run xonotic-glx) at first you can move mouse a bit but it just hangs a bit later, after a while X crashes (It reclocks works fine when reclocking between 0 and 1) -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20121217/27e59e8c/attachment.html>

Hi! Did you check on different Fermi chipsets or only with one variant? Are you sure that engine reclocking works as expected on Fermi? Because enabling it without a strong inspection sounds like a prediction and it might not work. On 01/13/2016 01:25 PM, Karol Herbst wrote: > some chipset have working engine reclocking, but broken memory reclocking like > Fermi. We should for now, add

https://bugs.freedesktop.org/show_bug.cgi?id=89273 Bug ID: 89273 Summary: [NVA8] nouveau screen corruption and X lockup when reclocking Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: >> >> Adds a NvReclock boolean option to allow the user to enable (or disable) >> reclocking. All chipsets default to off, except NVAA/NVAC, which are >> reportedly complete. > Hey Ilia, > > I

On Fri, May 16, 2014 at 11:54 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On 17 May 2014 13:39, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: >> >> On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> > On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: >> >> >>

some chipset have working engine reclocking, but broken memory reclocking like Fermi. We should for now, add the functionality to allow partly reclocking for those. Allthough this doesn't give as much performance as one might wish, it is till noticeable and may improve performance enough to be noted. Karol Herbst (2): clk: seperate engine and memory reclock toggles clk: allow engine

On 17 May 2014 13:39, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: > > On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > > On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: > >> > >> Adds a NvReclock boolean option to allow the user to enable (or disable) > >> reclocking.

https://bugs.freedesktop.org/show_bug.cgi?id=104784 Bug ID: 104784 Summary: Unable to do reclocking manually Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

https://bugs.freedesktop.org/show_bug.cgi?id=99505 Bug ID: 99505 Summary: Attempting to reclock GeForce GT740M (GK208) cause GPU and system to hang Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component:

Although memory reclocking seems to be completely broken on my GF119, we can at least allow users to enable reclocking for the core clock. Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com> --- drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c b/drm/nouveau/nvkm/subdev/fb/ramgf100.c

------------------原始邮件------------------ 发件人：朱尚忠10137461 收件人：samba@lists.samba.org <samba@lists.samba.org> 日 期 ：2018年02月26日 17:10 主 题 ：[ctdb] Unable to take recovery lock - contention When the ctdb is starting, the "Unable to take recovery lock - contention" log will be output all the time. Which cases will the "unable to take lock" errror be output? Thanks! The

Hello, first of all, I'm new to this list, so please beer with me. On the other hand, I'm a graduate computer systems engineer with experience in Linux kernel code, so I can hopefully provide useful input/assistance on this topic. I'm replying because I tried your patches on my setup in the hope they'd fix my lockups. Unfortunately they didn't, so I'm offering debug

First patch fixes a potential vbios parsing bug on Fermi GPUs, but it may also affect Kepler ones. Second patch wakes the GPU up whenever the user tries to reclock to prevent the write to the pstate file from freezing. Karol Herbst (2): bios/vpstate: There are some fermi vbios with no boost or tdp entry debugfs: Wake up GPU before doing any reclocking drm/nouveau/nouveau_debugfs.c

Hi, I have a GTX 770 (NVE4) back on 3.16.X kernel i was able to reclock my gpu using /sys/class/drm/card0/device/pstate but now on 3.18 (rc4) all proper reclocking support is gone from pstate. how should i be able to reclock again my GPU? cheers Lucas.

https://bugs.freedesktop.org/show_bug.cgi?id=88890 Bug ID: 88890 Summary: Reclocking of core speed fails on non-reference ASUS GeForce GTX650 Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

When the ctdb is starting, the "Unable to take recovery lock - contention" log will be output all the time. Which cases will the "unable to take lock" errror be output? Thanks! The following the ctdb logs: 2018/02/12 19:38:51.147959 ctdbd[5615]: CTDB starting on node 2018/02/12 19:38:51.528921 ctdbd[6602]: Starting CTDBD (Version 4.6.10) as PID: 6602 2018/02/12 19:38:51.529060

Am Montag, 26. Februar 2018, 17:26:06 CET schrieb zhu.shangzhong--- via samba: Decoded base64 encoded body with some chinese characters: ------------------原始邮件------------------ 发件人：朱尚忠10137461 收件人：samba at lists.samba.org <samba at lists.samba.org> 日 期 ：2018年02月26日 17:10 主 题 ：[ctdb] Unable to take recovery lock - contention When the ctdb is starting, the "Unable to take recovery lock