Bug 234044 - graphics/drm-kmod: kernel: Failed to add WC MTRR for [0xe0000000-0xefffffff]: -22; performance may suffer
Summary: graphics/drm-kmod: kernel: Failed to add WC MTRR for [0xe0000000-0xefffffff]:...
Status: Closed Not Accepted
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Johannes M Dieterich
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-15 21:17 UTC by Lorenzo Salvadore
Modified: 2019-03-10 09:26 UTC (History)
3 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Lorenzo Salvadore freebsd_committer 2018-12-15 21:17:38 UTC
I get the following message when loading the i915dms.ko module:
kernel: Failed to add WC MTRR for [0xe0000000-0xefffffff]: -22; performance may suffer

Performance do not suffer in a significant manner, however I think there might be a slight penalty (supertuxkart does not run as smoothly as I would expect).

This is the relevant part of my system log:

kernel: drmn0: <drmn> on vgapci0
kernel: vgapci0: child drmn0 requested pci_enable_io
syslogd: last message repeated 1 times
kernel: [drm] Memory usable by graphics device = 2048M
kernel: Failed to add WC MTRR for [0xe0000000-0xefffffff]: -22; performance may suffer
kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
kernel: [drm] Driver supports precise vblank timestamp query.
kernel: [drm] Connector LVDS-1: get mode from tunables:
kernel: [drm]   - kern.vt.fb.modes.LVDS-1
kernel: [drm]   - kern.vt.fb.default_mode
kernel: [drm] Connector VGA-1: get mode from tunables:
kernel: [drm]   - kern.vt.fb.modes.VGA-1
kernel: [drm]   - kern.vt.fb.default_mode
kernel: [drm] Connector HDMI-A-1: get mode from tunables:
kernel: [drm]   - kern.vt.fb.modes.HDMI-A-1
kernel: [drm]   - kern.vt.fb.default_mode
kernel: [drm] Connector DP-1: get mode from tunables:
kernel: [drm]   - kern.vt.fb.modes.DP-1
kernel: [drm]   - kern.vt.fb.default_mode
kernel: [drm] Initialized i915 1.6.0 20170123 for drmn0 on minor 0
kernel: VT: Replacing driver "efifb" with new "fb".
kernel: start FB_INFO:
kernel: type=11 height=768 width=1366 depth=32
kernel: cmsize=16 size=4227072
kernel: pbase=0xe0236000 vbase=0xfffff800e0236000
kernel: name=drmn0 flags=0x0 stride=5504 bpp=32
kernel: cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000
kernel: end FB_INFO
kernel: drmn0: fb0: inteldrmfb frame buffer device

I never had problems with the i915kms.ko module from kernel. However, because of the announce that its code will be removed in 13.0, I made the transitition to the drm-kmod passage.
I am on 12.0-RELEASE. The port installed by the metaport is drm-fbsd12.0-kmod-g20181210.

The details of my graphic controller can be find here:
https://ark.intel.com//products/72061/Intel-Celeron-Processor-1007U-2M-Cache-1_50-GHz

A similar issue has been discussed in the past here:
https://github.com/FreeBSDDesktop/DEPRECATED-freebsd-base-graphics/issues/144

I was unsure if it was better to report the bug here or on github. Finally I thought that a report here was a good idea as it does concern FreeBSD as an OS; if an issue is opened on github (as it probably should) it can be easily linked. Moreover, this bug report will probably be easier to find, in particular by users not used to github.
Comment 1 vermaden 2018-12-16 09:40:56 UTC
Same error message on 2011 ThinkPad T420s with Intel(R) Core(TM) i5-2520M cpu.
Comment 2 vermaden 2018-12-16 09:41:28 UTC
... on 11.2-RELEASE system:

% uname -v
FreeBSD 11.2-RELEASE-p5 #0: Tue Nov 27 09:33:52 UTC 2018     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC
Comment 3 Lorenzo Salvadore freebsd_committer 2018-12-19 20:39:35 UTC
I've updated to drm-fbsd12.0-kmod-g20181215 adn the error messages changed.
Here is the relevant section of the log:

vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] Unable to create a private tmpfs mount, hugepage support will be disabled(-19).
__pm_runtime_resume not implemented -- see your local kernel hacker
Failed to add WC MTRR for [0xe0000000-0xefffffff]: -22; performance may suffer
[drm] Got stolen memory base rxdbe00000, size 0x4000000
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] Connector LVDS-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.LVDS-1
[drm]   - kern.vt.fb.default_mode
pm_runtime_mark_last_busy not implemented -- see your local kernel hacker
__pm_runtime_suspend not implemented -- see your local kernel hacker
[drm] Connector VGA-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.VGA-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-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-1
[drm]   - kern.vt.fb.default_mode
pm_runtime_get_if_in_use not implemented -- see your local kernel hacker
sched_setscheduler_nocheck not implemented -- see your local kernel hacker
register_oom_notifier not implemented -- see your local kernel hacker
acpi_lid_notifier_register not implemented -- see your local kernel hacker
[drm] Initialized i915 1.6.0 20171222 for drmn0 on minor 0
register_acpi_notifier not implemented -- see your local kernel hacker
async_schedule is dodgy -- see your local kernel hacker
pm_runtime_set_autosuspend_delay not implemented -- see your local kernel hacker
__pm_runtime_use_autosuspend not implemented -- see your local kernel hacker
async_synchronize_cookie not implemented -- see your local kernel hacker
VT: Replacing driver "efifb" with new "fb".

After many normal lines, I also get the following lines:

get_nr_swap_pages not implemented -- see your local kernel hacker
current_is_kswapd not implemented -- see your local kernel hacker

Everything seems to work just as before the update.

A new bug has been opened that might be related to this one: bug #234171.
Comment 4 Johannes M Dieterich freebsd_committer 2018-12-26 21:30:40 UTC
This is not a problem with the port itself but with the actual DRM. Please report this upstream (i.e., https://github.com/FreeBSDDesktop/kms-drm ) which is where these issues are being tracked and where they are being worked on and fixed. Thanks.
Comment 5 Lorenzo Salvadore freebsd_committer 2018-12-29 18:04:24 UTC
I opened this issue to continue discussion about the bug:

https://github.com/FreeBSDDesktop/kms-drm/issues/118

The issue links to https://github.com/FreeBSDDesktop/kms-drm/issues/58 where only the "kernel: Failed to add WC MTRR for [0xe0000000-0xefffffff]: -22; performance may suffer" message is discussed and it is said that this message can be ignored.