similar to: [PATCH] drm/nouveau/clock: fix support for more than 2 monitors on nve0

http://bugs.freedesktop.org/show_bug.cgi?id=24092 Summary: X with nouveau hangs in nouveau_bo_map_range when doing anything Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Driver/nouveau

https://bugs.freedesktop.org/show_bug.cgi?id=58735 Priority: medium Bug ID: 58735 Assignee: nouveau at lists.freedesktop.org Summary: GeForce 680, HDMI output no good after passing through HDMI-to-DVI converter QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS:

Fixes a null pointer dereference when reclocking on my fermi. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h b/drivers/gpu/drm/nouveau/core/include/subdev/clock.h index 39e73b9..41b7a6a 100644 --- a/drivers/gpu/drm/nouveau/core/include/subdev/clock.h +++

Hello Ben Skeggs, The patch 88524bc06926: "drm/nouveau/devinit: move simple pll setting routines to devinit" from Mar 5, 2013, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv50.c:53 nv50_devinit_pll_set() info: return a literal instead of 'ret' drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv50.c 34 int 35

From: Tom Rix <trix at redhat.com> clang static analysis flags this problem hw.c:271:12: warning: The left operand of '>=' is a garbage value if (pv.M1 >= pll_lim.vco1.min_m ... ~~~~~ ^ This is mostly not a problem because an early check in nouveau_hw_fix_bad_vpll() if (nvbios_pll_parse(bios, pll, &pll_lim)) return; nouveau_hw_get_pllvals(dev, pll,

Dear Colleagues, I am trying to estimate several non-linear models simultaneously. I don't want to use non-linear mixed model, but non-linear model with same form, but it should be estimated separately according to variable group (I have lots of groups that have lots of observations....). I would like to have unique parameters for each group. e.g. something like this mod <- nls(y ~

Hello, I have created my own R package and written the documentation in Rd format for each of the functions plus the package itself. However now the functions appear in a random order in the generated PDF and the package documentation entry is placed in between the functions, when I would like it to be first, naturally. Is there an easy way to specify the order of the entries in the generated

Fixes regression introduced in commit 861d2107 "drm/nouveau/fb: merge fb/vram and port to subdev interfaces" nv50_fb_vram_{new,del} functions were changed to use nouveau_subdev->mutex instead of the old nouveau_mm->mutex. nvc0_fb_vram_new still uses the nouveau_mm->mutex, but nvc0 doesn't have its own fb_vram_del function, using nv50_fb_vram_del instead. Because of this, on

Package: src:xen Version: 4.17.3+10-g091466ba55-1~deb12u1 Severity: wishlist I wasn't sure if this script comes from Debian or Xen or somewhere else, so I thought it safest to report it here. /etc/xen/scripts/vif-bridge handles MTU settings in the vif, but the otherwise similar /etc/xen/scripts/vif-openvswitch does not. I added it in, here's the diff-c and the full fixed file is also

Package: xenstore-utils Version: 3.2.0-3 Severity: minor Description: Xenstore utilities for Xen This package contains the Xenstore utilities. I would hope that there would be a more descriptive description for this package, so I could know if I really need it. (Yes, I'm a newbie to the world of XENU ... I suppose I would already know if I wasn't new to this.) -- System Information:

On Fri, Jan 29, 2010 at 12:00:49PM +0300, Dan Carpenter wrote: > These bugs are when code dereferences a variable and then checks that it is not null. > The new thing is that I wrote a shell script to try remove the false positives caused > by macros. There are still some false positives because smatch is bad at handling > loops and knowing when a container got redefined. > >

Hi, Here is my patch queue I accumulated over quite a long time. Patches 1-6 are bugfixes, and rest is mostly RFC. Comments are welcome. Best regards, Maxim Levitsky

We want to be able to guarantee the location of the allocated buffer object if we're going to be able to reliably allocate the existing framebuffer at startup. Add an argument to do so and pass that through to the ttm core. Signed-off-by: Matthew Garrett <mjg at redhat.com> --- drivers/bcma/main.c | 1 - drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++++++-

Package: xen-utils-common Version: 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 Severity: important Tags: patch security -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),

flight 17325 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17325/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 guest-start fail REGR. vs. 12557 test-amd64-i386-xl-credit2 15 guest-stop fail REGR. vs. 12557 test-amd64-i386-xl 15 guest-stop

flight 17454 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17454/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 12557 Regressions which are regarded as allowable (not blocking): test-amd64-i386-qemut-rhel6hvm-amd 7 redhat-install fail

flight 17612 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17612/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 12557 Regressions which are regarded as allowable (not blocking): test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail

flight 17901 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17901/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-qemuu-rhel6hvm-intel 4 xen-install fail REGR. vs. 12557 test-amd64-i386-pv 4 xen-install fail REGR. vs. 12557 test-amd64-amd64-pv 4

flight 17916 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/17916/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-pv 4 xen-install fail REGR. vs. 12557 test-amd64-amd64-xl 4 xen-install fail REGR. vs. 12557 test-amd64-amd64-xl-win7-amd64 4

flight 18150 linux-linus real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/18150/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rhel6hvm-amd 7 redhat-install fail REGR. vs. 12557 test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 12557 Regressions which are regarded as