Hi!
Thanks for Ronald's idea, reinstalling the drm-61-kmod from ports,
solved my problem.
cd /usr/ports/graphics/drm-61-kmod directory
make all deinstall reinstall
shutdown -r now
And everything works.
(Now, missing the ENCODER lines and the messages about the priority
problem.
Instead, VT: Replacing driver "efifb" with new "drmfb")
ZAHEMSZKY, Gábor
2024-11-14 18:42 időpontban Edward Sanford Sutton, III ezt írta:
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) .
