Re: Error report on FreeBSD-14.2-BETA2 - graphics problem
Date: Thu, 14 Nov 2024 17:42:04 UTC
On 11/14/24 04:09, Hans Ottevanger wrote: > On 11/14/24 10:33, Ronald Klop wrote: >> Op 12-11-2024 om 19:17 schreef Zahemszky Gábor: >>> Hi! >>> >>> On a Lenovo Thinkpad T470 (with an Intel Core i7-6600U CPU plus an >>> Intel GPU), I have this problem: >>> >>> I cannot switch into character based virtual terminals from >>> the X11 graphical screen. When I press Alt-Ctrl-F[1-7] the >>> machine "freeze" - it doesn't do anything, mouse / keyboard >>> doesn't work after it. I can only halt the machine with >>> the power button. >>> >>> It worked under 14.1 - on all of the patch levels. >>> >>> $ pciconf -lv >>> vgapci0@pci0:0:2:0: class=0x030000 rev=0x07 hdr=0x00 >>> vendor=0x8086 device=0x1916 subvendor=0x17aa subdevice=0x2245 >>> vendor = 'Intel Corporation' >>> device = 'Skylake GT2 [HD Graphics 520]' >>> class = display >>> subclass = VGA >>> >>> >>> $ pkg info -x drm >>> drm-61-kmod-6.1.92 >>> drm-kmod-20220907_3 >>> libdrm-2.4.123,1 >>> >>> Some strange lines from dmesg: >>> >>> ... >>> drm] Got Intel graphics stolen memory base 0x7a800000, size 0x2000000 >>> drmn0: <drmn> on vgapci0 >>> vgapci0: child drmn0 requested pci_enable_io >>> vgapci0: child drmn0 requested pci_enable_io >>> skl_dmc_ver1_27.bin: could not load binary firmware /boot/firmware/ >>> skl_dmc_ver1_27.bin either >>> i915/skl_dmc_ver1_27.bin: could not load binary firmware /boot/ >>> firmware/i915/skl_dmc_ver1_27.bin either >>> i915_skl_dmc_ver1_27.bin: could not load binary firmware /boot/ >>> firmware/i915_skl_dmc_ver1_27.bin either >>> drmn0: successfully loaded firmware image 'i915/skl_dmc_ver1_27.bin' >>> drmn0: [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin >>> (v1.27) >>> ... >>> iic2: <I2C generic I/O> on iicbus2 >>> drmn0: [drm] [ENCODER:102:DDI B/PHY B] is disabled/in DSI mode with >>> an ungated DDI clock, gate it >>> drmn0: [drm] [ENCODER:117:DDI C/PHY C] is disabled/in DSI mode with >>> an ungated DDI clock, gate it >>> sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)! >>> ... >>> ic5: <I2C generic I/O> on iicbus5 >>> [drm] Initialized i915 1.6.0 20201103 for drmn0 on minor 0 >>> VT: Driver priority 0 too low. Current 101 >>> fbd0: not attached to vt(4) console; another device has precedence >>> (err=17) >>> acpi_ibm0: <ThinkPad ACPI Extras> on acpi0 >>> acpi_ibm0: Firmware version is 0x200 >>> acpi_video0: <ACPI video extension> on vgapci0 >>> ... >>> Security policy loaded: MAC/ntpd (mac_ntpd) >>> drmn0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 >>> drmn0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 >>> hdac0: Command 0x20220011 timeout on address 2 >>> hdac0: Command 0x20270d01 timeout on address 2 >>> hdac0: Command 0x20270620 timeout on address 2 >>> ... >>> >>> Bye, >>> >>> ZAHEMSZKY, Gabor >>> >>> >> >> >> Hi, >> >> Did you rebuild the drm*kmod packages? These packages tent to depend >> on kernel internals which might be out of sync. The official packages >> are not build against FreeBSD 14.2-BETA. >> BTW: I'm not involved on the graphics stack. Just repeating what I >> read on here more often. >> >> Ronald. >> >> 14.1-RELEASE-p6 > > > > I also had the same issue with one of my antique Intel Q6600 based > systems, equipped with a Radeon HD6450 graphics adapter. As soon as > radeonkms.ko is loaded ttyv[0-7] are unreachable. X keeps running OK on > ttyv8. There is also this suspect message in motd once radeonkms is loaded: > > VT: Driver priority 0 too low. Current 100 > fbd0: not attached to vt(4) console; another device has precedence > (err=17) > > This happened for both BETA1 and BETA2. An identical twin system running > 14.1-RELEASE-p6 does not have the issue. > > I could indeed resolve this problem by rebuilding the drm-61-kmod > package from ports on BETA2. I still wonder what we have to tell an > unsuspecting (possibly beginning) end user who stumbles over this issue. If manually rebuilding drm-kmod fixed it for 14.2-BETA, then that same fix will be needed for 14.2 once released until 14.1 goes EOL (3 or 4 months, I forget which) and then a 14.2 package is built. If packages knowingly won't be built for that while, it would be best if both freebsd-update and pkg could inform users of the incompatible state (preferrably requiring a manual override to continue) .