Nouveau - Nov 2014 - [Bug 86537] New: [NV96] Unable to handle page request from nv50_crtc_prepare

https://bugs.freedesktop.org/show_bug.cgi?id=86537

            Bug ID: 86537
           Summary: [NV96] Unable to handle page request from
                    nv50_crtc_prepare
           Product: xorg
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: pierre.morrow at free.fr
        QA Contact: xorg-team at lists.x.org

Created attachment 109818
  --> https://bugs.freedesktop.org/attachment.cgi?id=109818&action=edit
dmesg

Hardware:
* 9600M GT (NV96)
* 9400M (NVAC)

Tested on something newer than 3.17-rc5.
Though it is not visible in the dmesg, I set "config=NvForcePost=1"
which had
no effect on the issue.

When using the NV96 to drive the display - this is set before booting -, a BUG:
unable to handle kernel page request is thrown by nv50_crtc_prepare after the
fb was allocated for the NV96 - the NVAC wasn't initialised yet.

-- 
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/20141121/ce79484f/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

--- Comment #1 from l3iggs <j at greyltc.com> ---
I've also experienced this bug with my MacBook Pro 5,1 (same GPUs as
parent).

I've seen it with linux 3.18 rc5 when I run 'modprobe nouveau' :
http://hastebin.com/qusumotusi.m

-- 
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/20141121/eadca951/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

--- Comment #2 from Emil Velikov <emil.l.velikov at gmail.com> ---
l3iggs for the future please try to attach logs (in text/plain format) here, as
links to other sites tend to expire. Esp. hastebin ones :P

-- 
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/20141122/62f7737a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

--- Comment #3 from l3iggs <j at greyltc.com> ---
Created attachment 109938
  --> https://bugs.freedesktop.org/attachment.cgi?id=109938&action=edit
journalctl when I modprobe nouveau

I've attached my journalctl output when I 'modprobe nouveau' on my
MacBook Pro
5,1 which has GeForce 9400M and GeForce 9600M GPUs.

This bug generally occurs during the boot process which prevents the machine
from booting.

-- 
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/20141124/9fb5414c/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

--- Comment #4 from l3iggs <j at greyltc.com> ---
I've found a workaround for this bug (tested with 3.18-rc5):

(1) Append 'modprobe.blacklist=nouveau' to the kernel boot parameters
This allows the system to boot.
(2) Once booted, as root, reset the 9600M GPU: 'echo 1 >
/sys/bus/pci/devices/0000:02:00.0/reset'
(3) 'echo 1 > /sys/bus/pci/devices/0000:02:00.0/rescan'
(4) 'modprobe nouveau'

Note that 0000:02:00.0 is the PCI bus address of my 9600M GT GPU, which I
learned by inspecting the output of lspci.

The trick here is getting the GPU into the proper state before the nouveau
module is loaded. I've found that the internal state of the GPU can
frequently
be inconsistent across reboots making troubleshooting difficult. Resetting and
then rescanning it before loading nouveau seems to solve things for every
scenario I've tested.

With the above workaround I can start a display manager (GDM for gnome 3.14.2)
and everything seems to work as expected, ex. glxgears.

The 9400M GPU can optionally be disabled between steps (3) and (4): 'echo 1
>
/sys/bus/pci/devices/0000:03:00.0/remove'

where 0000:03:00.0 is the PCI address of my 9400M.

-- 
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/20141124/ad655626/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

--- Comment #5 from Pierre Moreau <pierre.morrow at free.fr> ---
(In reply to l3iggs from comment #4)
> I've found a workaround for this bug (tested with 3.18-rc5):
> 
> (1) Append 'modprobe.blacklist=nouveau' to the kernel boot
parameters
> This allows the system to boot.
> (2) Once booted, as root, reset the 9600M GPU: 'echo 1 >
> /sys/bus/pci/devices/0000:02:00.0/reset'
> (3) 'echo 1 > /sys/bus/pci/devices/0000:02:00.0/rescan'
> (4) 'modprobe nouveau'
It does work indeed, and seems to solve some other issues related to that card
(powering it down using vgaswitcheroo, suspending the laptop - resuming
doesn't
work though).
> 
> Note that 0000:02:00.0 is the PCI bus address of my 9600M GT GPU, which I
> learned by inspecting the output of lspci.
> 
> The trick here is getting the GPU into the proper state before the nouveau
> module is loaded. I've found that the internal state of the GPU can
> frequently be inconsistent across reboots making troubleshooting difficult.
> Resetting and then rescanning it before loading nouveau seems to solve
> things for every scenario I've tested.
> 
> With the above workaround I can start a display manager (GDM for gnome
> 3.14.2) and everything seems to work as expected, ex. glxgears.
> 
> The 9400M GPU can optionally be disabled between steps (3) and (4):
'echo 1
> > /sys/bus/pci/devices/0000:03:00.0/remove'
> 
> where 0000:03:00.0 is the PCI address of my 9400M.
vgaswitcheroo should be able to connect the integrated to the display (look at
http://nouveau.freedesktop.org/wiki/Optimus/) using apple-gmux driver.

-- 
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/20141126/50701649/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

--- Comment #6 from Pierre Moreau <pierre.morrow at free.fr> ---
Created attachment 114138
  --> https://bugs.freedesktop.org/attachment.cgi?id=114138&action=edit
Kmesg with EVO debug messages

Still an issue. I've been playing with PDISPLAY and PFB regs by following
the
blob, but never managed to make it work.

-- 
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/20150308/41d325a1/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #7 from Pierre Moreau <pierre.morrow at free.fr> ---


*** This bug has been marked as a duplicate of bug 82714 ***

-- 
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/20150404/4c250074/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |---
            Summary|[NV96] Unable to handle     |[NV96] Unable to handle
                   |page request from           |page request from
                   |nv50_crtc_prepare           |nv50_crtc_(prepare,disable)
                   |                            |on dual Nvidia setup

--- Comment #8 from Pierre Moreau <pierre.morrow at free.fr> ---
Reopening this bug as its core issue is different from the other bug's one.

Setting the 8 LSB of register 0x8841c (PPCI.CONFIG) to 0 makes it possible to
interact with the card normally, without any crashes. Though after powering off
the G96, switching to it from the MCP79 will result in a blank screen: no error
message outputed, no hang, just a blank screen. I'll push a hacky patch for
those who wants to use their G96, or power it down; you may alternatively run
`nvapoke -c0 0x8841c 28400` **before** loading Nouveau.

This bit resetting is also done by the PCI reset step.

-- 
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/20150705/fb6eb3e6/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

--- Comment #9 from Pierre Moreau <pierre.morrow at free.fr> ---
Created attachment 118038
  --> https://bugs.freedesktop.org/attachment.cgi?id=118038&action=edit
Disable bits 5 and 6 of 0x8841c

The extremely hacky attached patch gets the laptop into a working state: being
able to load Nouveau and X properly, switch between cards, and power down/up
the inactive card.

-- 
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/20150901/33c5ba3a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #118038|0                           |1
        is obsolete|                            |

--- Comment #10 from Pierre Moreau <pierre.morrow at free.fr> ---
Created attachment 118042
  --> https://bugs.freedesktop.org/attachment.cgi?id=118042&action=edit
Enable EXT_TAG if hardware allows it

Apparently enabling EXT_TAG, as the hardware supports it, is enough to fix the
bug. So apparently, bits 5 and 6 can only be enabled if EXT_TAG is also
enabled?

-- 
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/20150902/1b0b2390/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=86537

Pierre Moreau <pierre.morrow at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Pierre Moreau <pierre.morrow at free.fr> ---
Fix is now available at
http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=a978bf48487cbc9828de47b724ce682e0e073cbf.

-- 
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/20151012/44e966f5/attachment.html>