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

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?

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.)

  -ilia

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.

Phil

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