Displaying 20 results from an estimated 4000 matches similar to: "[Bug 76475] New: Nouveau fails to load due to unknown opcode 0x80"
2014 Mar 26
3
[PATCH] acpi: allow non-optimus setups to load vbios from acpi
There appear to be a crop of new hardware where the vbios is not
available from PROM/PRAMIN, but there is a valid _ROM method in ACPI.
The data read from PCIROM almost invariably contains invalid
instructions (still has the x86 opcodes), which makes this a low-risk
way to try to obtain a valid vbios image.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475
Signed-off-by: Ilia Mirkin
2014 Apr 05
2
[PATCH] acpi: allow non-optimus setups to load vbios from acpi
Hi, same for me. The screen does not freeze anymore and the boot
succeeds. But now I have this kernel message during boot (for the second
card):
[ 24.382045] pci_pm_runtime_suspend():
nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22
Do you want to have the complete dmesg log? I think this is a new bug.
Your patch works for the previous one, so you can close it.
Yours,
Claas
On
2016 Oct 13
15
[Bug 98240] New: Kernel module fails to load on HP Pavilion V3A33AV laptop.
https://bugs.freedesktop.org/show_bug.cgi?id=98240
Bug ID: 98240
Summary: Kernel module fails to load on HP Pavilion V3A33AV
laptop.
Product: xorg
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component:
2016 May 25
3
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote:
> Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port
> can be runtime-suspended which disables power resources via ACPI. This
> is incompatible with DSM, resulting in a GPU device which is still in D3
> and locks up the kernel on resume.
>
> Mirror the behavior of Windows 8 and newer[1] (as
2016 May 30
2
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
+Rafael
On Fri, May 27, 2016 at 01:10:37PM +0200, Peter Wu wrote:
> On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote:
> > On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote:
> > > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port
> > > can be runtime-suspended which disables power resources via ACPI. This
> >
2016 May 24
7
[PATCH 0/4] nouveau fixes for RPM/Optimus-related hangs
Hi,
Here are two patches to fix an issue reported on kernel bugzilla (infinite loop
due to unchecked function) and a more important fix to fix hanging Optimus
machines when runtime PM is enabled (with pm/pci patches).
An older (obsolete) patch for the first issue was tested by the reporter:
https://bugzilla.kernel.org/show_bug.cgi?id=104791#c11
(it is replaced by "check for function 0x1B
2016 Jul 07
6
[PATCH v2 0/4] nouveau RPM fixes for Optimus
Hi,
Here are two patches to fix an issue reported on kernel bugzilla (infinite loop
due to unchecked function) and a more important fix to fix hanging Optimus
machines when runtime PM is enabled (with pm/pci patches).
See the first version[1] for a background on the fixed problems. This is the
second revision of incorporating feedback from Emil Velikov (patch 1), Mika
Westerberg (patch 4).
2016 May 27
3
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
Hi Peter,
On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote:
> Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port
> can be runtime-suspended which disables power resources via ACPI. This
> is incompatible with DSM, resulting in a GPU device which is still in D3
> and locks up the kernel on resume.
>
> Mirror the behavior of
2016 Jul 15
8
[PATCH v3 0/4] nouveau RPM fixes for Optimus (final)
Hi,
Here are two patches to fix an issue reported on kernel bugzilla (infinite loop
due to unchecked function) and a more important fix to fix hanging Optimus
machines when runtime PM is enabled (with pm/pci patches).
These are the final patches targeting v4.8. Changes compared to v2[1]:
collected R-b from Hans and Mika and fixed a minor comment style issue.
I recommend it to be merged before
2015 May 25
15
[PATCH 1/8] acpi: Rename v1 DSM to mux to avoid ambiguity
This is especially true when variables or functions are just called dsm without
precising the v1.
Signed-off-by: Pierre Moreau <pierre.morrow at free.fr>
---
drm/nouveau/nouveau_acpi.c | 64 +++++++++++++++++++++++-----------------------
drm/nouveau/nouveau_acpi.h | 4 +--
drm/nouveau/nouveau_drm.c | 4 +--
drm/nouveau/nouveau_vga.c | 10 ++++----
4 files changed, 41 insertions(+), 41
2015 May 28
12
[PATCH v2 1/9] acpi: Rename v1 DSM to mux to avoid ambiguity
This is especially true when variables or functions are just called dsm without
specifying the v1.
Changes since v1:
* Fix typo in commit explanation
* Change has_dsm to has_mux in nouveau_dsm_detect
Signed-off-by: Pierre Moreau <pierre.morrow at free.fr>
---
drm/nouveau/nouveau_acpi.c | 72 +++++++++++++++++++++++-----------------------
drm/nouveau/nouveau_acpi.h | 4 +--
2016 May 30
2
[PATCH 4/4] drm/nouveau/acpi: fix lockup with PCIe runtime PM
On 27 May 2016 at 22:31, Peter Wu <peter at lekensteyn.nl> wrote:
> On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote:
>> Hi Peter,
>>
>> On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote:
>> > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port
>> > can be runtime-suspended which disables
2012 Jun 22
1
Problem with GT520 and optimus on Fedora 17
Hello,
I have an Asus laptop, U36SD, with Optimus technology.
The discrete gpu is an NVIDIA GeForce GT 520M with 1GB DDR3 VRAM
Using Fedora 17; up to kernel 3.3.7-1 I was able to use bumblebee and
bbswitch and then running optirun command (as I could do in F16).
No more with kernel 3.4. Tried 3.4.0-1.fc17.x86_64,
3.4.2-4.fc17.x86_64 and 3.4.3-1.fc17.x86_64.
I already opened a bug against F17:
2016 May 14
1
[PATCH] drm/nouveau: check function before using it
Do not unconditionally invoke function 0x1B without checking for its
availability, it leads to an infinite loop on some firmware.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791
Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)")
Signed-off-by: Peter Wu <peter at lekensteyn.nl>
---
Hi,
I am not sure what exactly 0x1B is used for, it seems related to HDMI
2012 Mar 23
3
[PATCH 0/3] Prepare nouveau for other switcheroo handlers
While working on a vga_switcheroo handler for Apple's Macbook Pros I stumbled
upon a few bugs regarding the usage of nouveau with other switcheroo handlers
and module unloading, here are my fixes for them.
Andreas Heider (3):
drm/nouveau: Initialize has_optimus
drm/nouveau: Check dsm on switcheroo unregister
drm/nouveau: Unregister switcheroo client on exit
2018 Nov 28
2
4.20.0-rc3 nouveau/Quadro P2000 Mobile: runpm causing ACPI errors, lockups
On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote:
> +linux-acpi
>
> Hi Michael,
>
> On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote:
> > So a new thinkpad:
> > 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM [Quadro P2000 Mobile] (rev a1)
> >
> > Hangs whenever I try to poke at the card. It starts happily
2016 May 30
2
[PATCH 1/9] drm/nouveau: Don't leak runtime pm ref on driver unload
On Sun, May 29, 2016 at 05:50:06PM +0200, Lukas Wunner wrote:
> Hi Peter,
>
> On Fri, May 27, 2016 at 03:07:33AM +0200, Peter Wu wrote:
> > On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> > > nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0,
> > > but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally.
> >
2015 Mar 12
52
[Bug 89558] New: Unknown chipset error for GeForce 840M
https://bugs.freedesktop.org/show_bug.cgi?id=89558
Bug ID: 89558
Summary: Unknown chipset error for GeForce 840M
Product: xorg
Version: unspecified
Hardware: Other
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Driver/nouveau
Assignee: nouveau at
2016 May 27
2
[PATCH 1/9] drm/nouveau: Don't leak runtime pm ref on driver unload
On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0,
> but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally.
> We therefore leak a runtime pm ref whenever nouveau is loaded with
> runpm=0 and then unloaded. The GPU will subsequently never runtime
> suspend even if nouveau is loaded again
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 +++++++++++++++-----------