[Nouveau] HP Zbook17 Dock and UEFI conflict with GK107GLM aka Quadro K1100M

Phil Turmel philip at turmel.org
Wed Feb 1 15:40:51 UTC 2017


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>


More information about the Nouveau mailing list