Bug 249476 - graphics/drm-fbsd12.0-kmod i915kms GT2 attach returned 19
Summary: graphics/drm-fbsd12.0-kmod i915kms GT2 attach returned 19
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-20 08:55 UTC by grarpamp
Modified: 2020-10-13 19:43 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description grarpamp 2020-09-20 08:55:02 UTC
Intel Haswell GT2 Server HD Graphics P4600 vendor=0x8086,dev=0x041a,revid=0x06
download.freebsd.org: FreeBSD 12.2-BETA1 r365618 GENERIC amd64
pkg.freebsd.org: FreeBSD:12:amd64/latest/All/drm-fbsd12.0-kmod-4.16.g20200221.txz

Up to date as above.

Modules kldload and kldstat ok...
Loaded /.../i915kms.ko, id=8
i915kms.ko, drm.ko, linuxkpi.ko, linuxkpi_gplv2.ko, debugfs.ko

But the only dmesg output says they are broken...
kernel: anon_inodefs registered
kernel: debugfs registered
kernel: drmn0: <drmn> on vgapci0
kernel: device_attach: drmn0 attach returned 19

Then upon kldunload of i915kms it panics.



The drm shipped in BETA1, and in drm-legacy-kmod-g20200825, both work.

But they do throw some issues...
kernel: info: [drm] Memory usable by graphics device = 2048M
kernel: info: [drm] MTRR allocation failed.  Graphics performance may suffer.
kernel: error: [drm:pidxxx:i915_write32] *ERROR* Unknown unclaimed register before writing to c5100
...
kernel: error: [drm:pidxxx:drm_mm_takedown] *ERROR* Memory manager not clean. Delaying takedown
kernel: Warning: memory type drm_sman leaked memory on destroy (4 allocations, 512 bytes leaked).

Intel-ARK says this unit has max 1.7GB video mem shared from dram.
Comment 1 Niclas Zeising freebsd_committer 2020-09-20 15:03:00 UTC
Have you rebuilt drm-fbsd12.0-kmod locally to match your kernel?

kldunload of drm modules are generally not supported.
Comment 2 grarpamp 2020-09-22 09:38:40 UTC
Ok, right... even though those are the most recent,
pkg.freebsd.org is built on sys earlier than BETA1,
often earlier than drm too.

So this revision noted 99da0ba does work for xterm.
https://svnweb.freebsd.org/ports/head/graphics/drm-fbsd12.0-kmod/Makefile?view=markup&pathrev=526717

Compared to legacy, the useful list of supported devices
via 'devmatch -d' is no longer printing the quoted strings...

< PNP info for bus vgapci format I:vendor;I:device;D:#; 84 entries (i915kms.ko)
> PNP info for bus pci format I:vendor;I:device; 217 entries (i915kms.ko)
...
<   0x8086:0x41a:'Intel Haswell (GT2 server)':
>   0x8086:0x41a:
...


Here are the compile warnings...

/drm/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c:58:35: warning: unused function 'vmw_overlay' [-Wunused-function]
static inline struct vmw_overlay *vmw_overlay(struct drm_device *dev)

/drm/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29: warning: equality comparison with extraneous parentheses [-Wparentheses-equality]
/drm/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29: note: remove extraneous parentheses around the comparison to silence this warning
/drm/drivers/gpu/drm/amd/powerplay/smumgr/tonga_smumgr.c:419:29: note: use '=' to turn this equality comparison into an assignment
        if ((data->vdd_gfx_control == SMU7_VOLTAGE_CONTROL_BY_SVID2)) {


load log
kernel: [drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
kernel: Failed to add WC MTRR for [0xe0000000-0xefffffff]: -22; performance may suffer

unload log
kernel: Warning: memory type drm_driver leaked memory on destroy (3 allocations, 64 bytes leaked).
kernel: Warning: memory type drm_kms leaked memory on destroy (2 allocations, 1088 bytes leaked).
kernel: Warning: memory type linuxcurrent leaked memory on destroy (3 allocations, 576 bytes leaked).
kernel: Warning: memory type linux leaked memory on destroy (1049 allocations, 231808 bytes leaked).
kernel: Warning: memory type idr leaked memory on destroy (18 allocations, 8448 bytes leaked).

While it appears to unload, it panics and reboots
when starting Xorg again after the second kldload.
But unload is not much important unless for testing drivers.