Bug 254190
| Summary: | graphics/drm-kmod: I get corruption at the top of all of my consoles | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Steven Friedrich <Steven.E.Friedrich> |
| Component: | Individual Port(s) | Assignee: | freebsd-x11 (Nobody) <x11> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | grahamperrin, manu, mizhka, zeising |
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(x11) |
| Version: | Latest | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248628 | ||
|
Description
Steven Friedrich
2021-03-10 14:08:31 UTC
This seem to miss a lot of information. What exactly is the problem? Which version of FreeBSD, which version of drm-*-kmod? You missed the information at the bottom of the bug report. Here it is again: Note the drm message regarding stolen memory. You can't use stolen memory. It is causing my console corruption. drm-fbsd12.0-kmod-4.16.g20201016_1 = drm-kmod-g20190710_1 = drm_info-2.2.0_1 = libdrm-2.4.104,1 = HP-Slimline 290-p0014 Desktop using integrated UHD Graphics 630 FreeBSD FreeBSD 12.2-RELEASE-p4 FreeBSD 12.2-RELEASE-p4 r369434 Special amd64 Path: /usr/ports Working Copy Root Path: /usr/ports URL: https://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 567992 Node Kind: directory Schedule: normal Last Changed Author: vd Last Changed Rev: 567992 Last Changed Date: 2021-03-10 05:29:13 -0500 (Wed, 10 Mar 2021) (In reply to Steven Friedrich from comment #2) Yes, I missed it. All I noticed was a pasted dmesg and a bug title that said graphics/drm-kmod, no hint about anything else. In any case, what type of corruption? Have you tried on FreeBSD 13, the driver has seen a lot of updates there. yes, sir. I tried 13RC-1. Same "stolen memory" in dmesg. When I use mouse console cut and paste, or launch x11, I get corruption at the top of all of my consoles. Sometimes it shows the freebsd beastie graphic. Is this a regression? Does it work fine on Linux? Are other display servers affected (kmscube, wlroots, arcan)? Maybe try playing with (reserved) onboard video memory in BIOS, disabling framebuffer compression (compat.linuxkpi.i915_enable_fbc=0 in /boot/loader.conf) or switching from modesetting (builtin generic DDX) to xf86-video-intel then enable SNA+DRI3. "Got stolen memory" is normal behavior on Intel iGPUs, see https://github.com/freebsd/drm-kmod/blob/drm_v5.4.92_1/drivers/gpu/drm/i915/gem/i915_gem_stolen.c#L21-L29 (In reply to Jan Beich from comment #5) No, it's not a regression, it has been this way for YEARS. Does it work fine on Linux? I didn't previously know FreeBSD users were supposed to test Linux. I happen to be tracking KDE Neon, Ubuntu, and Linux Mint Cinnamon, and no I don't see this there, but I also don't see any boot messages on Linux. Maybe try playing with (reserved) onboard video memory in BIOS I see nothing of the sort in my BIOS. disabling framebuffer compression (compat.linuxkpi.i915_enable_fbc=0 in /boot/loader.conf This I could try... switching from modesetting (builtin generic DDX) to xf86-video-intel then enable SNA+DRI3. I have no idea what you're talking about. You are the video expert, I'm a user. "Got stolen memory" is normal behavior on Intel iGPUs Maybe because it's existed since Intel build i915 into their chips and you guys have ignored the problem since the beginning? Doesn't that phrase "stolen memory" bother you? I don't mean to be disrespectful, but I think you guys should consult with Intel about this memory. I don't think it's for your use at all. Stolen memory is the reserved memory by the bios assign to the graphics card region. It is perfectly normal to see that in dmesg You don't see the message on Linux as it's a FreeBSD custom message : https://github.com/freebsd/drm-kmod/blob/master/drivers/gpu/drm/i915/gem/i915_gem_stolen.c#L387 So this isn't your problem root cause. For the logos appearing there is a bug on this, I still haven't found the root cause. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248628 As an old hardware guy, I was curious when I saw this message:
"unknown: memory range not supported"
and this device:
none0@pci0:0:20:2: class=0x050000 card=0x72708086 chip=0xa36f8086 rev=0x10 hdr=0x00
vendor = 'Intel Corporation'
device = 'Cannon Lake PCH Shared SRAM'
class = memory
subclass = RAM
I thought, what is that? Well I found a rather opaque description in an Intel document at: https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/300-series-chipset-on-package-pch-datasheet-vol-1.pdf
21.7.2 SRAM
The local SRAM is used for ISH FW code storage and to read/write operational data. The local SRAM block includes both the physical SRAM as well as the controller logic. The SRAM is a total of 640 kbytes organized into banks of 32 kB each and is 32-bit wide. The SRAM is shared with Intel CSME as shareable memory. To protect against memory errors, the SRAM includes ECC support. The ECC mechanism is able to detect multi-bit errors and correct for single bit errors. The ISH firmware has the ability to put unused SRAM banks into lower power states to reduce power consumption.
That sounds to me like memory Intel uses between their OWN devices.
I would hope you would contact technical support at Intel and get clarification of whether you should be ignoring this memory range and leave it untouched.
(In reply to Steven Friedrich from comment #0) > graphics/drm-kmod Maybe a better prefix for the summary line: graphics/drm-fbsd12.0-kmod Is this still happening ? In addition: (In reply to Steven Friedrich from comment #4 (2021-03-10)) > … 13RC-1 … corruption at the top … Sometimes … beastie … In the absence of a photograph, I'll guess. Anything like this? <https://forums.freebsd.org/attachments/1641932927943-png.12590/> * that's not the BSD Daemon a.k.a. beastie, however the orb (pictured) is derivative – whilst FreeBSD-SA-22:01.vt <https://www.freebsd.org/security/advisories/FreeBSD-SA-22:01.vt.asc> (2022-01-11) did not mention 248628, the two commits at and under bug 248628 comment 16 _did_ mention the security advisory. ---- Triage: * in progress (status) goes with assignment to a person, not a group * … > * in progress (status) goes with assignment to a person, not a group
@manu sorry, that was perfunctory/impolite. Should I have assigned to you?
(In reply to Graham Perrin from comment #12) No. never. "* in progress (status) goes with assignment to a person, not a group" Where is this rule defined ? (In reply to Graham Perrin from comment #11) What's the point of guessing ? You're producing noise for nothing here. (In reply to Emmanuel Vadot from comment #13) Basics under <https://wiki.freebsd.org/Bugzilla/TriageTraining>. (In reply to Graham Perrin from comment #15) Yeah that don't make sense to me, graphics bug shouldn't be assigned to anyone else than x11@ and this bug is likely fixed by PR 248628 so put it back as "in progress." ^Triage: apparently fixed by PR 248628. |
