Nouveau - Feb 2017 - HP Zbook17 Dock and UEFI conflict with GK107GLM aka Quadro K1100M

On Thu, Feb 2, 2017 at 4:54 PM, Phil Turmel <philip at turmel.org>
wrote:
> On 02/02/2017 04:48 PM, Ilia Mirkin wrote:
>> On Thu, Feb 2, 2017 at 4:43 PM, Phil Turmel <philip at
turmel.org> wrote:
>>> On 02/01/2017 10:40 AM, Phil Turmel wrote:
>>>> Hi All,
>>>>
>>>> I've been running Gentoo on a ZBook with great success for
a couple years,
>>>> but I've been stymied in my attempts to implement
SecureBoot by an
>>>> apparent problem with efifb to nouveaufb handoff, but only when
external
>>>> monitors are attached.  The handoff works without issue when
the BIOS is
>>>> in Mixed EFI mode, with and without external monitors, and
>>>> works in Native EFI mode without external monitors.
>>>
>>> Sorted by nouveau.config=NvForcePost=1
>>
>> Bleh. That's unfortunate. Presumably in "Native EFI"
mode, displays
>> work fine with efifb until nouveau takes over?
>
> Yes, at least the laptop's built-in display.  The external displays
> aren't activated in the brief time between efifb startup (penguins)
> and handoff to nouveaufb.
>
>> There was a time when the blob did *something* weird which defeated
>> nouveau's display logic (when flipping between the two drivers).
>> Perhaps this Native EFI mode does something along those lines as well.
>> (Although in those cases, running the VBIOS didn't help... although
>> each VBIOS is a unique snowflake. In some other cases, double-running
>> the VBIOS leads to a hung GPU. Urgh.)
>
> I'm open to experiments.  I've moved to vanilla 4.8.17 from 4.8.15
and
> will jump into 4.9.x this weekend.  I'll check with and without
> NvForcePost as I upgrade.  Not gonna hold my breath, though -- I first
> noticed this a couple years ago and it hasn't been a priority.
>
> But note, the handoff *does* work without NvForcePost if there are no
> external monitors.  That's what's had me scratching my head.
Interesting. Also interesting are the disp prints that happen in the
docked case. You mentioned them in your original mail, but I
misunderstood. I thought you had had debugging enabled, which can
print those. But you don't.

It prints "Base 2" and "Base 3" disp configurations for some
reason.
This is not usual, it probably hits some error condition in the code.

Note that a lot of this stuff has been redone for kernel 4.10 to
conform to atomic modesetting. I wouldn't be surprised if that jiggers
things around enough to fix your issue. But perhaps not. Worth a shot.
[As an aside, this would also enable more reliable reclocking for your
GPU, so not a bad upgrade to make in any case.]

  -ilia

On 02/02/2017 05:01 PM, Ilia Mirkin wrote:
> Note that a lot of this stuff has been redone for kernel 4.10 to 
> conform to atomic modesetting. I wouldn't be surprised if that
> jiggers things around enough to fix your issue. But perhaps not.
> Worth a shot. [As an aside, this would also enable more reliable
> reclocking for your GPU, so not a bad upgrade to make in any case.]
I saw the reclocking improvements.  I'm sure I'll enjoy them, but
it'll
have to wait a bit.  This is my primary work machine and I can't afford
to lose a day here and there cleaning up after a vanilla RC smashing my
filesystems.  Applying a nouveau patch series onto a stable base is
sufficiently low risk.

TBH, I was hoping someone would see the odd "Disp" output and pop in
with an "I know what that is."  /-:

Phil

On Thu, Feb 2, 2017 at 5:09 PM, Phil Turmel <philip at turmel.org>
wrote:
> On 02/02/2017 05:01 PM, Ilia Mirkin wrote:
>
>> Note that a lot of this stuff has been redone for kernel 4.10 to
>> conform to atomic modesetting. I wouldn't be surprised if that
>> jiggers things around enough to fix your issue. But perhaps not.
>> Worth a shot. [As an aside, this would also enable more reliable
>> reclocking for your GPU, so not a bad upgrade to make in any case.]
>
> I saw the reclocking improvements.  I'm sure I'll enjoy them, but
it'll
> have to wait a bit.  This is my primary work machine and I can't afford
> to lose a day here and there cleaning up after a vanilla RC smashing my
> filesystems.  Applying a nouveau patch series onto a stable base is
> sufficiently low risk.
>
> TBH, I was hoping someone would see the odd "Disp" output and pop
in
> with an "I know what that is."  /-:
OK, I'm pretty sure this is from gf119_disp_intr_error:

drm/nouveau/nvkm/engine/disp/gf119.c:
nv50_disp_chan_mthd(disp->chan[chid], NV_DBG_ERROR);

However what's odd is that preceding this line, there should have been a

        nvkm_error(subdev, "chid %d mthd %04x data %08x %08x %08x\n",
                   chid, (mthd & 0x0000ffc), data, mthd, unkn);

which isn't displayed. Furthermore, your logs appear to be missing
some fairly common prints. Did you mess with CONFIG_NOUVEAU_DEBUG*
symbols by any chance? Aha:

CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=2

You should adjust the default to 3 (info). And perhaps for the purpose
of this exercise, it might even be worth booting with
nouveau.debug=debug to hopefully get a bit more info about what's
going on.

Cheers,

  -ilia