similar to: [Bug 68768] New: [nv50] error during boot

https://bugs.freedesktop.org/show_bug.cgi?id=78863 Priority: medium Bug ID: 78863 Assignee: nouveau at lists.freedesktop.org Summary: [nv50] errors when starts gnome-shell QA Contact: xorg-team at lists.x.org Severity: minor Classification: Unclassified OS: All Reporter: mattia.b89 at gmail.com

https://bugs.freedesktop.org/show_bug.cgi?id=82704 Priority: medium Bug ID: 82704 Assignee: nouveau at lists.freedesktop.org Summary: kernel bug Severity: normal Classification: Unclassified OS: All Reporter: mattia.b89 at gmail.com Hardware: Other Status: NEW Version: 10.2

https://bugs.freedesktop.org/show_bug.cgi?id=84870 Bug ID: 84870 Summary: [NV50] [PBUS] write fault on boot Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at

Hello all, this series includes a wide range of fixes - from a few month's old one-liners from Andreas Heider regarding vga_switcheroo, via a null pointer dereference and double memory allocation, to a buffer overflow. Please review and comment --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 ++- drivers/gpu/drm/nouveau/nouveau_device.c | 26 +++++++++++++++-----------

https://bugs.freedesktop.org/show_bug.cgi?id=79532 Priority: medium Bug ID: 79532 Assignee: nouveau at lists.freedesktop.org Summary: [NV50] errors with DMA PUSHER and idle channel Severity: normal Classification: Unclassified OS: All Reporter: mattia.b89 at gmail.com Hardware: Other Status:

https://bugs.freedesktop.org/show_bug.cgi?id=66176 Priority: medium Bug ID: 66176 Assignee: nouveau at lists.freedesktop.org Summary: nouveau.perflvl kernel parameter doesn't work QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: mr.dash.four at

https://bugs.freedesktop.org/show_bug.cgi?id=77003 Priority: medium Bug ID: 77003 Assignee: nouveau at lists.freedesktop.org Summary: Fan speed to high with Kernel versions 3.13.x - Nvidia GeForce GTS 240 QA Contact: xorg-team at lists.x.org Severity: major Classification: Unclassified OS: Linux

Hi everyone. I read on a 2011 article - http://www.phoronix.com/scan.php?page=article&item=nouveau_comp_2011&num=19 - that my particular card, GeForce 8400 GS, overheats with nouveau. (So, I never tried using if for long, before, as soon as possible, installing the proprietary drivers...) But, because it's a 2-year-old article, I was wondering if that problem could have been, in the

https://bugs.freedesktop.org/show_bug.cgi?id=43668 Bug #: 43668 Summary: Secondary monitor always in standby on dual head NV94 Classification: Unclassified Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ v3: - move the ack to fini() - disable IRQs on fini() - silently ignore un-requested IRQs

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #49 from Andreas Loew <awl1 at gmx.net> --- OK, tired with RHEL 6.5 kernel 2.6.32.431 and the two options: Command line: ro root=UUID=034d34cd-a464-4ee3-8db9-d6061a318a16 rd_NO_LUKS LANG=en_US.UTF-8 KEYBOARDTYPE=pc KEYTABLE=de-latin1-nodeadkeys rd_NO_MD SYSFONT=latarcyrheb-sun16 rd_NO_LVM rd_NO_DM nouveau.perflvl_wr=7777

Apparently the b89 xvm-src.tar.bz2 tar bz2 archive is corrupted / truncated on the b89 source download page: http://dlc.sun.com/osol/on/downloads/b89/ http://dlc.sun.com/osol/on/downloads/b89/xvm-src.tar.bz2 In the past, the xvm-src.tar.bz2 file had a size of ~ 100 mbytes; with b89 the size of the downloadable archive is only 72 mbytes. And bzip2 complains: % bzip2 -tv

Here's a quick-but-I-guess-tidy-fix for faulty behaviour someone reported in NVAF. I'm just not sure if the check for nvaa/nvac should still be in nv50_pm_clocks_pre... I believe this is wrong as they can reclock perfectly well (except the non-existing memory). Anyone has a definite answer to that?

https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #47 from Andreas Loew <awl1 at gmx.net> --- Hi - it's me again ;-) > Well, given that it doesn't work on the blob makes it sound like you have some > sort of funkiness in your hardware. One unsubstantiated theory is that the > vdec clock is *disabled*, and pcrypt is hooked up to that clock. Or perhaps >

https://bugs.freedesktop.org/show_bug.cgi?id=81136 Priority: medium Bug ID: 81136 Assignee: nouveau at lists.freedesktop.org Summary: [NV92] Regression in Linux 3.15: GPU lockup after suspend QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All)

This adds basic support for driving sensor chips off the nvidia i2c buses, along with basic support for reading the internal GPU sensor on supported chipsets. It's heavily cribbed off nvclock. Having scanned a large number of bioses, I'm pretty convinced that the appropriate i2c bus is always number 2 in the list on <g80 - I'm not sure about later cards yet. There's still a lot

Current uninitialized sensor detection does not work for me on nv4b and sensor returns crazy values (>190?C). It stabilises later, but it's too late - therm code shutdowns the machine... Let's just reset it on init. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c | 12 +++++++++++- 1 file changed, 11

http://bugs.freedesktop.org/show_bug.cgi?id=25952 Summary: GeForce 9800 GTX - nouveau_init takes ~ 1 minute to complete Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: major Priority: high Component: Driver/nouveau AssignedTo: nouveau at

From: Martin Peres <martin.peres at labri.fr> This should fix a deadlock that has been reported to us where fan_update() would hold the fan lock and try to grab the alarm_program_lock to reschedule an update. On an other CPU, the alarm_program_lock would have been taken before calling fan_update(), leading to a deadlock. We should Cc: <stable at vger.kernel.org> # 3.9+ Reported-by:

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ Signed-off-by: Martin Peres <martin.peres at labri.fr> ---