search

FreeBSDDesktop / DEPRECATED-freebsd-base-graphics

Fork of FreeBSD's base repository to work on graphics-stack-related projects
Other
49 stars 13 forks source link

Add Support For Kabylake Firmware #151

Closed nomadlogic closed 6 years ago

nomadlogic commented 7 years ago

It looks like we have not added support yet for Kabylake GPU firmware. Here is the page listing all the firmware for products:

https://01.org/linuxgraphics/downloads/firmware

Here are the in links to individual firmware tar-balls. GuC: https://01.org/linuxgraphics/downloads/kabylake-guc-9.14

DMC: https://01.org/linuxgraphics/downloads/kabylake-dmc-1.01

Huc: https://01.org/linuxgraphics/downloads/kabylake-huc-2.0

I'll take a poke around - but I'm not very proficient so someone else may be able to bang this out quicker than me. If that's the case I'll be more than willing to provide testing :)

nomadlogic commented 7 years ago

I made some progress on this last night. I've added the uuencoded bin file for GuC and placed it here:

    new file:   sys/contrib/dev/drm/i915kmsfw/kbl_guc_ver9_14.bin.uu

i then added this Makefile:

$ cat sys/modules/drm/i915/i915kmsfw/kblguc/Makefile
# $FreeBSD$

KMOD    = i915_kbl_guc_ver9_14.bin
NAME    = i915/kbl_guc_ver9_14.bin
IMG = kbl_guc_ver9_14
.include <bsd.kmod.mk>

and then added kblguc to the i915kmsfw Makefile:

$ git diff sys/modules/drm/i915/i915kmsfw/Makefile
diff --git a/sys/modules/drm/i915/i915kmsfw/Makefile b/sys/modules/drm/i915/i915kmsfw/Makefile
index 682df880149..6b3cfefcba5 100644
--- a/sys/modules/drm/i915/i915kmsfw/Makefile
+++ b/sys/modules/drm/i915/i915kmsfw/Makefile
@@ -2,6 +2,7 @@

 SUBDIR=                                                                        \
        sklguc          \
-       skldmc
+       skldmc          \
+        kblguc

 .include <bsd.subdir.mk>

So, the good news is when i make and install a kernel with these changes dmesg reports my system trying to load the module. unfortunately it fails:

drm:intel_guc_init] GuC firmware pending, path i915/kbl_guc_ver9_14.bin
[drm:guc_fw_fetch] before requesting firmware: GuC fw fetch status PENDING
i915/kbl_guc_ver9_14.bin: could not load firmware image, error 2
drmn0: failed to load firmware image i915_kbl_dmc_ver1_01_bin
drmn0: Failed to load DMC firmware [https://01.org/linuxgraphics/intel-linux-graphics-firmwares], disabling runtime power management.
drmn0: failed to load firmware image i915_kbl_guc_ver9_14_bin
[drm] Failed to fetch valid GuC firmware from i915/kbl_guc_ver9_14.bin (error -2)
[drm:guc_fw_fetch] GuC fw fetch status FAIL; err -2, fw 0, obj 0
<snip>
[drm:intel_guc_setup] GuC fw status: path i915/kbl_guc_ver9_14.bin, fetch FAIL, load NONE
[drm] GuC firmware load failed: -5

I also verified that the md5 sum of the downloaded .bin file from Intel matches the .bin generated during makeworld:

$ md5 sys/modules/drm/i915/i915kmsfw/kblguc/kbl_guc_ver9_14.bin ~/Downloads/kbl_guc_ver9_14/tmp/kbl_guc_ver9_14.bin
MD5 (sys/modules/drm/i915/i915kmsfw/kblguc/kbl_guc_ver9_14.bin) = 23366cc1eaa04732c1cec496c619a328
MD5 (/home/pwright/Downloads/kbl_guc_ver9_14/tmp/kbl_guc_ver9_14.bin) = 23366cc1eaa04732c1cec496c619a328

So...not sure what's going wrong at this point, I'll keep poking around but any pointers if I'm missing something obvious would be great!

nomadlogic commented 7 years ago

Update on this issue, after the commit to enable this in issue #160 I am still seeing the same behavior on Kabylake failing to load the GuC and DMC firmwares. Hopefully now that this has been imported into drm-next it'll make it easier for us to debug and fix the issue.

nomadlogic commented 7 years ago

Testing latest code merged in #160 causes a reproducible panic on my kabylake system. i suspect the culprit is in the DMC firmware (the GuC fails to load) - the good news is i'm able to capture a core. here's some relevant info for debugging, full core can be provided if needed:

FreeBSD runner 12.0-CURRENT FreeBSD 12.0-CURRENT #25 86963c42c2dc(drm-next): Mon Aug 14 10:54:20 PDT 2017     pwright@runner:/usr/obj/usr/home/pwright/git/freebsd-base-graphics/sys/GENERIC  amd64

panic: Most recently used by linux

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
Memory modified after free 0xfffff80036e8c080(56) val=deadc0df @ 0xfffff80036e8c08c
vt_kms_postswitch() at vt_kms_postswitch+0x52/frame 0xfffffe045a777400
vt_window_switch() at vt_window_switch+0xdb/frame 0xfffffe045a777440
vtterm_cngrab() at vtterm_cngrab+0x20/frame 0xfffffe045a777460
cngrab() at cngrab+0x42/frame 0xfffffe045a777480
vpanic() at vpanic+0x10a/frame 0xfffffe045a777500
panic() at panic+0x43/frame 0xfffffe045a777560
mtrash_dtor() at mtrash_dtor/frame 0xfffffe045a777580
uma_zalloc_arg() at uma_zalloc_arg+0x52f/frame 0xfffffe045a7775e0
malloc() at malloc+0x1dd/frame 0xfffffe045a777630
zfs_get_data() at zfs_get_data+0x137/frame 0xfffffe045a7776a0
Dumping 1272 out of 16110 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91%
<snip>
Loaded symbols for /boot/kernel/ng_socket.ko
#0  doadump (textdump=0) at pcpu.h:232
232     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump (textdump=0) at pcpu.h:232
#1  0xffffffff829689dc in vt_kms_postswitch (arg=<value optimized out>)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/dev/drm/linux_fb.c:80
#2  0xffffffff808ee5cb in vt_window_switch (vw=0xffffffff8179f4e8)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/dev/vt/vt_core.c:540
#3  0xffffffff808ebd90 in vtterm_cngrab (tm=<value optimized out>)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/dev/vt/vt_core.c:1498
#4  0xffffffff80a08ee2 in cngrab ()
    at /usr/home/pwright/git/freebsd-base-graphics/sys/kern/kern_cons.c:368
#5  0xffffffff80a665ea in vpanic (
    fmt=0xffffffff8146b19f "Most recently used by %s\n", 
    ap=0xfffffe045a777540)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/kern/kern_shutdown.c:765
#6  0xffffffff80a66703 in panic (fmt=<value optimized out>)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/kern/kern_shutdown.c:710
#7  0xffffffff80d5de10 in mtrash_ctor (mem=<value optimized out>, 
    size=<value optimized out>, arg=<value optimized out>, 
    flags=<value optimized out>)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/vm/uma_dbg.c:160
#8  0xffffffff80d598ef in uma_zalloc_arg (zone=0xfffff804823c6000, udata=0x0, 
    flags=<value optimized out>)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/vm/uma_core.c:2093
#9  0xffffffff80a4197d in malloc (size=<value optimized out>, 
    mtp=<value optimized out>, flags=258) at uma.h:336
#10 0xffffffff8215fbb7 in zfs_get_data (arg=0xfffffe0006b36000, 
    lr=0xfffff8000b5e20b8, 
    buf=0xfffff8000b5e2178 "<DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE>
<DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD>
<DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0>
<AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE>
<C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE><DE><C0><AD><DE>"..., 
    zio=0xfffff803f7a69000)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1322
#11 0xffffffff8212b4c6 in zil_commit (zilog=<value optimized out>, 
    foid=<value optimized out>)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c:1157
#12 0xffffffff82166f53 in zfs_freebsd_fsync (ap=<value optimized out>)
    at /usr/home/pwright/git/freebsd-base-graphics/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:2627
#13 0xffffffff81017720 in VOP_FSYNC_APV (vop=<value optimized out>, 
    a=0xfffffe045a777838) at vnode_if.c:1331
#14 0xffffffff80b3d986 in kern_fsync (td=0xfffff80010639000, 
    fd=<value optimized out>, fullsync=true) at vnode_if.h:549
#15 0xffffffff80ef02db in amd64_syscall (td=0xfffff80010639000, traced=0)
    at subr_syscall.c:132
#16 0xffffffff80ecf7db in Xfast_syscall ()
    at /usr/home/pwright/git/freebsd-base-graphics/sys/amd64/amd64/exception.S:396
#17 0x0000000800bc973a in ?? ()
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal
(kgdb)
hselasky commented 7 years ago

OK, this might look like a memory leak / user after free in the failure path of getting the firmware. Did you try loading the kaby lake firmware files from the loader before booting?

hselasky commented 7 years ago

@nomadlogic : Can you re-test with the above mentioned patch?

nomadlogic commented 7 years ago

hrm just did a pull and rebuilt my kernel but i am seeing same behaviour. i'm going to do a clean build of my kernel with the latest commit and will let you know if i see any changes (my test was done using the -DKERNFAST option to buildkernel).

paranormal commented 7 years ago

Hi guys. Same here with ee3a6b91e1b

[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
i915/kbl_dmc_ver1_01.bin: could not load firmware image, error 2
[drm] Connector eDP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.eDP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-2
[drm]   - kern.vt.fb.default_mode
[drm] GuC firmware load skipped
[drm] Initialized i915 1.6.0 20160919 for drmn on minor 0
VT: Replacing driver "efifb" with new "fb".
start FB_INFO:
type=11 height=1440 width=2560 depth=32
cmsize=16 size=14745600
pbase=0xd0000000 vbase=0xfffff800d0000000
name=drmn0 flags=0x0 stride=10240 bpp=32
cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000
end FB_INFO
drmn0: fb0: inteldrmfb frame buffer device
i915/kbl_dmc_ver1_01.bin: could not load firmware image, error 2
[drm] Finished loading i915/kbl_dmc_ver1_01.bin (v1.1)
[drm] RC6 on

Although it works somehow.

valpackett commented 6 years ago

Although it works somehow.

i915/kbl_dmc_ver1_01.bin: could not load firmware image, error 2
[drm] Finished loading i915/kbl_dmc_ver1_01.bin (v1.1)

The same happens on amdgpu, there are "could not load firmware image" messages but then the same images get loaded successfully.

mattmacy commented 6 years ago

@myfreeweb It tries multiple times and it reports an error on the first failure. If you want to put that in the TO FIX queue please file a separate issue. AFAICT this issue has been dealt with, no?

valpackett commented 6 years ago

@mattmacy I have the current drm-next-kmod port, it does show these messages…

mattmacy commented 6 years ago

@myfreeweb this issue is the absence of the firmware. You're talking about it reporting failure prematurely - which is a completely separate issue.

valpackett commented 6 years ago

@mattmacy Wasn't the absence of firmware solved? I mean:

[drm] Finished loading i915/kbl_dmc_ver1_01.bin (v1.1)
mattmacy commented 6 years ago

@myfreeweb it was solved, yes. And that was what corresponds to this issue. Reporting failure incorrectly is a separate issue.