Nouveau - May 2019 - Support for GP107(GL)M with Optimus

Hi,

I recently added logs and another report from a ThinkPad P1 with a
Quadro P2000 Mobile (GP107GLM) to issue #100228.

That's with a very recent Linux kernel and current nouveau driver
sources, all booted from an NFS-root setup, making it well reproducible.
 I can optionally boot into a similar NFS installation with the
proprietary Nvidia driver, allowing me to capture MMIO traces as well.

However, I'm not sure where to go from here and would appreciate some
help in diagnosing this and/or moving it forward.  I'm a professional
and experienced developer, but have plenty of other interesting projects
on my table, already.

Do ordinary (non-Optimus) setups with GP107 work?  What do you look for
when reading MMIO traces?  What accompanying data do I need to collect?

Kind Regards

Markus Wanner

thanks for your main.

If you want you could try out those patches on a kernel and see if
those make any difference on your machine:

https://github.com/karolherbst/linux/commits/runpm_fixes

make sure you use the "runpm_fixes" branch. We are kind of aware of
the issues on modern laptops and already try to find a proper
solution, it mostly boils down to testing and checking if there are
other issues left we didn't address yet. Also without knowing what
error message you are getting precisely I can only make an educated
guess on what your issue might be.

Hello Karol,

On 5/29/19 4:04 PM, Karol Herbst wrote:
> If you want you could try out those patches on a kernel and see if
> those make any difference on your machine:
> 
> https://github.com/karolherbst/linux/commits/runpm_fixes
thanks, I tried, see below.  This raises another question: where does
nouveau development take place?  In a tree based on the linux kernel
(such as the above repo) or in some dedicated module-only repo like
skeggsb/nouveau?

I manually "rebased" the last five commits from the
"runpm_fixes" branch
of the repo above onto skeggsb/nouveau, which applied w/o conflicts.
Results below are for a nouveau module built that way.
> make sure you use the "runpm_fixes" branch. We are kind of aware
of
> the issues on modern laptops and already try to find a proper
> solution, it mostly boils down to testing and checking if there are
> other issues left we didn't address yet.
Understood.  That's part of why I setup that infrastructure.
> Also without knowing what
> error message you are getting precisely
Sorry, I thought the reference to issue #100228 was enough.  I certainly
got the exact same "bus: MMIO read of 00000000 FAULT at 409800"
timeout
and figured I better not file a duplicate.

I realize messed up the upload of the kernel log to that issue.  I just
corrected that.

So, current status on skeggsb/nouveau fails that way for me, independent
of the runpm setting.  However, with the five patches from your
runpm_fixes branch added, I see different results:

* no such timeouts any more in kernel logs (yay!)
* X11 recognizes the Dell display connected on HDMI-1 (independent
  of kernel module parameters or X11 config)
* starting X11 with only the nouveau driver, a terminal appears
  on the display (yay!)
* loading nouveau with `debug=debug` and starting X11, the display
  remains dark
* loading nouveau and intel (for the internal display), the external
  display remains dark as well, xrandr does not show it, but
  `xrandr --listproviders` at least lists two providers (I'm not sure
  whether I can somehow enable the external display in this case).


That's all tested on:

* a Lenovo ThinkPad P1, with a  GP107GLM, AKA Quadro P2000
* Debian testing
* linux 5.2-rc1
* X11 started using xinit, loading nothing but an xterm


I'm happy to provide logs from these runs or conduct further
experiments, but would appreciate some guidance on what's useful.  Thank
you.

Kind Regards

Markus