Displaying 20 results from an estimated 1000 matches similar to: "[Bug 68768] New: [nv50] error during boot"
2014 May 18
6
[Bug 78863] New: [nv50] errors when starts gnome-shell
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
2014 Aug 16
3
[Bug 82704] New: kernel bug
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
2014 Oct 10
2
[Bug 84870] New: [NV50] [PBUS] write fault on boot
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
2012 May 20
16
nouveau_subdev & misc patches
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 +++++++++++++++-----------
2014 Jun 02
3
[Bug 79532] New: [NV50] errors with DMA PUSHER and idle channel
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:
2013 Jun 25
8
[Bug 66176] New: nouveau.perflvl kernel parameter doesn't work
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
2014 Apr 03
9
[Bug 77003] New: Fan speed to high with Kernel versions 3.13.x - Nvidia GeForce GTS 240
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
2013 Oct 03
4
GeForce 8400 GS
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
2011 Dec 09
9
[Bug 43668] New: Secondary monitor always in standby on dual head NV94
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
2013 Sep 08
3
[PATCH 1/2] drm/nouveau/therm: ack any pending IRQ at init
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
2013 Dec 18
0
[Bug 58378] [NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
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
2008 May 13
2
b89 xVM Source tar bundle is corrupted on the on download site
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
2012 Aug 09
1
[PATCH] drm/nouveau/nv50: Reclock when memory was stolen
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?
2013 Dec 18
0
[Bug 58378] [NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
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
>
2014 Jul 10
14
[Bug 81136] New: [NV92] Regression in Linux 3.15: GPU lockup after suspend
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)
2009 Nov 19
2
[RFC] nouveau: Add basic i2c sensor chip support
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
2013 Feb 03
2
[PATCH 2/3] drm/nv40/therm: reset temperature sensor on init
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
2014 Mar 24
4
[PATCH 1/4] pm/fan: drop the fan lock in fan_update() before rescheduling
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:
2010 Jan 08
10
[Bug 25952] New: GeForce 9800 GTX - nouveau_init takes ~ 1 minute to complete
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
2013 Aug 31
2
[PATCH] drm/nouveau/therm: ack any pending IRQ at init v2
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>
---