Error report on FreeBSD-14.2-BETA2 - graphics problem
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=0x03 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 0x7a80, size 0x200 drmn0: 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: 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: 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: on acpi0 acpi_ibm0: Firmware version is 0x200 acpi_video0: on vgapci0 ... Security policy loaded: MAC/ntpd (mac_ntpd) drmn0: [drm] *ERROR* Fault errors on pipe A: 0x0080 drmn0: [drm] *ERROR* Fault errors on pipe A: 0x0080 hdac0: Command 0x20220011 timeout on address 2 hdac0: Command 0x20270d01 timeout on address 2 hdac0: Command 0x20270620 timeout on address 2 ... Bye, ZAHEMSZKY, Gabor
Error report on FreeBSD-14.2-BETA2 - kernel modul problem
# kldload gpiospi kldload: can't load gpiospi: module already loaded or in kernel It's not true: "kldstat -v | fgrep -A 5 gpio" doesn't show it. But on the console === KLD gpiospi.ko: depends on gpiospi - not available or version mismatch === gpiospi depends on gpiospi ZAHEMSZKY, Gabor
Re: Error report on FreeBSD-14.2-BETA2 - graphics problem
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=0x03 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 0x7a80, size 0x200 drmn0: 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: 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: 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: on acpi0 acpi_ibm0: Firmware version is 0x200 acpi_video0: on vgapci0 ... Security policy loaded: MAC/ntpd (mac_ntpd) drmn0: [drm] *ERROR* Fault errors on pipe A: 0x0080 drmn0: [drm] *ERROR* Fault errors on pipe A: 0x0080 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) .
Re: CFT: repository for kernel modules
A last question: I have an old Nvidia card (Quatro-K4200), which is supported by the nvidia-driver-470 (and not the official nvidia-driver (-570?)). Every time the drm-61-kmod binary package changes, it deinstalls the correct driver and reinstalls the official. Is it possible to handle it? (Every time I have to type: pkg remove -f nvidia-driver && pkg install nvidia-driver-470 Are there a more intelligent way? Thanks, ZAHEMSZKY, Gábor 2025-07-25 15:14 időpontban Tomoaki AOKI ezt írta: On Sat, 28 Dec 2024 11:52:23 +0900 Tomoaki AOKI wrote: On Thu, 26 Dec 2024 14:23:52 +0100 Baptiste Daroussin wrote: > On Thu 26 Dec 13:26, Andriy Gapon wrote: > > On 13/12/2024 16:28, Baptiste Daroussin wrote: > > > On Fri 13 Dec 07:24, Alan Somers wrote: > > > > Success! With drm-61-kmod-6.1.92.1402000_3 I can kldload 915kms on > > > > FreeBSD 14.2. Before switching to this repo, kldload would hang. > > > > > > > > Also, in addition to kmods, there are a few other ports that must be > > > > rebuilt for every minor version. devel/py-libzfs is one. Could that > > > > be added to the new repository? > > > > > > Right now and until we have a thin repository support in poudriere: no :(. > > > > > > One of the limitation is everything is cross build from amd64 so I cannot get > > > much things in that repo considering that in 2024 perl is still not cross build > > > friendly and last I checked python wasn't either. > > > > I guess that's also the reason why nvidia driver packages are not built for > > the kmod repo? > > Because they bundle kernel and userland code in the same port? > > Yes ! > It seems they can be easily split, but I don't have the time to split them now. > And I don't have any nvidia device to test > > Bapt Hi. Bug 288314 is filed that stating, for 14.3, there are no pkg of graphics/nvidia-drm-kmod in FreeBSD-kmods repo. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288314 Is it a temporary delay? Or does it (as it is metaport to choose actual nvidia-drm-*-kmod, it would be one of graphics/nvidia-drm-*-kmod, though) because of kmod parts of x11/nvidia-driver* are NOT splitted from them and graphics/nvidia-drm-*-kmod ports are depending on x11/nvidia-driver[-devel]? If so, I'll try to *split kmod parts from x11/nvidia-driver[-304|-340|-390|-470|-devel] and create corresponding x11/nvidia-kmod[-304|-340|-390|-470|-devel], *let x11/nvidia-driver[-304|-340|-390|-470|-devel] to depend on corresponding kmod port, and *switch dependency of graphics/nvidia-drm-*-kmod[-devel] from x11/nvidia-driver[-devel] to corresponding x11/nvidia-kmod[-devel]. Note that, other than graphics/nvidia-drm-*-kmod[-devel], science/linux-ai-ml-env alone depends on x11/nvidia-driver, but it isn't kmod port and would want library parts, thus, no plan to modify it (if something is needed to do, it would be to allow choosing proper version that support wanted GPU). TBH, I've already started investigating if it is actually possible or not, but not finished. Any insights and/or thoughts? Another thing to mention. All legacy versions of nvidia driver supporting i386 (called x86 upstream) are already deprecated upstream. https://nvidia.custhelp.com/app/answers/detail/a_id/3142 and dissappeared from top page for Unix drivers. https://www.nvidia.com/en-us/drivers/unix/ Actually, any older versions for amd64 (x86_64) can be tracked from Archive link. https://download.nvidia.com/XFree86/FreeBSD-x86_64/ Fortunately, there is still https://download.nvidia.com/XFree86/FreeBSD-x86/ for i386 (just cannot tracked via links) and fetchable. But once nvidia decided to delete them, we have no way to fetch i386 versions and we cannot know when it is. I'm planning to send heads-up for the deprecation, but still a bit wondering whether we should explicitly DEPRECATE legacy versions other than still supported -470 or send heads-up alone and remove affected ports once it becomes unfetchable. Anyway, I wouldn't set EXPIRATION_DATE even if DEPRECATE'ing affected ports, as when to be unfetchable is unknown. Regards. x11/nvidia-driver port is quite complicated with conditionals and reinplaces to support legacy (and unofficially new feature and beta) drivers. (x11/nvidia-driver is the master port of x11/nvidia-driver-* having all required supports/workarounds per-version differences). And it strongly depends on bundled pre-compiled (proprietary) large blobs, so possibly even splitting it into kmod parts and libraries part would not help cross compiling. And more, graphics/nvidia-drm-[510|515|61]-kmod depends on it and corresponding graphics/drm-[510|515|61]-kmod ports, could make it more complicated. But one possibly good news would be that native
