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

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.

Diffing dmesg from working (mixed) to nonworking (native), I find
numerous lines like the following immediately after handoff:

+nouveau 0000:01:00.0: disp: Base 2:
+nouveau 0000:01:00.0: disp: ^I0080: 00000000              
+nouveau 0000:01:00.0: disp: ^I0084: 00000000 -> 00000010
+nouveau 0000:01:00.0: disp: ^I0088: 00000000 -> 00000200
+nouveau 0000:01:00.0: disp: ^I008c: 00000000              
+nouveau 0000:01:00.0: disp: ^I0090: 00000000 -> 00000001
+nouveau 0000:01:00.0: disp: ^I0094: 00000000 -> f0000000
+nouveau 0000:01:00.0: disp: ^I00a0: 00000000              

None of these show up in any of the working configurations. In non-working
mode, all three displays (laptop + 2 external) are black and I've found no
intervention that will revive them.

One other notable difference that shows up is the BIOS initial video mode
is different in native EFI mode:

@@ -374,11 +379,11 @@
 pciehp: PCI Express Hot Plug Controller Driver version: 0.4
 nvidiafb: Device ID: 10de0ff6 
 efifb: probing for efifb
-efifb: framebuffer at 0x81000000, using 3072k, total 3072k
-efifb: mode is 1024x768x32, linelength=4096, pages=1
+efifb: framebuffer at 0x70000000, using 8100k, total 8100k
+efifb: mode is 1920x1080x32, linelength=7680, pages=1
 efifb: scrolling: redraw
 efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
-Console: switching to colour frame buffer device 128x48
+Console: switching to colour frame buffer device 240x67
 fb0: EFI VGA frame buffer device
 ACPI: AC Adapter [AC] (on-line)
 input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input0

No functional difference was observed after upgrading the BIOS to v1.36,
which was released in November 2016.

One more data point:  There's no problem if the monitors are unplugged from
the dock and the laptop rebooted.  The monitors may be added any time after
boot without any problem.  There is also no problem if the laptop is
put to sleep with no external monitors and then resumed in the dock with
them.

Boot messages for the different cases were collected and the following script
used to prune them for nice diffs:

#! /bin/bash
for x in *.log; do
 egrep -v '((usb|hub)
[0-9]+-[0-9]+|raid[0-9]+|Thermal|Battery|Bluetooth|ata[0-9]+|scsi
[0-9]+|dracut:|udevd|snd_hda|br[0-9]+|random|sd [0-9]+:)' $x \
 |cut -c16- > ${x%%.log}.boot
done

diff -U3 bios34-uefi-mixed-20170131-1038.boot
uefi-mixed-docked-20170131-1211.boot >bios34-36-mixed.diff
diff -U3 bios34-uefi-native-20170131-1034.boot
uefi-native-docked-20170131-1209.boot >bios34-36-native.diff
diff -U3 bios34-uefi-mixed-20170131-1038.boot
bios34-uefi-native-20170131-1034.boot >bios34-mixed-native.diff
diff -U3 uefi-mixed-undocked-20170131-1226.boot
uefi-mixed-docked-20170131-1211.boot >bios36-mixed-undocked-docked.diff
diff -U3 uefi-native-undocked-20170131-1223.boot
uefi-native-docked-20170131-1209.boot >bios36-native-undocked-docked.diff
diff -U3 uefi-mixed-undocked-20170131-1226.boot
uefi-native-undocked-20170131-1223.boot >bios36-undocked-mixed-native.diff
diff -U3 uefi-mixed-docked-20170131-1211.boot
uefi-native-docked-20170131-1209.boot >bios36-docked-mixed-native.diff
#

This script, the raw and filtered logs, the diffs, and kernel config and
machine data have all been posted on my personal server:

http://www.turmel.org/lists/nouveau/

The docked diff from mixed to native that shows the problem is attached.

The kernel is self-compiled and assembled with its initramfs into
a direct-bootable EFI file, following the general instructions on
Greg Kroah-Hartman's blog:

http://kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/

My intent is to complete those instructions with my own signed kernel after
I can reliably use SecureBoot in my office.

I will also be attempting newer kernels, but I haven't noticed anything
recent
that would impact this.  Of course, if I knew how the driver worked, I
wouldn't
be asking for help. (-:

Any suggestions for config or debugging options that might help here?  Or
debugging information you might like that would help?

Phil Turmel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bios36-docked-mixed-native.diff
Type: text/x-patch
Size: 26898 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20170201/9f7e75ac/attachment-0001.bin>

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

I may have to turn in my geek card. /-:

Phil

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