Date: Tue, 1 Feb 2022 10:39:49 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans <tijl@FreeBSD.org> To: Vladimir Kondratyev <wulf@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: Kernel changes causing AMDGPU / DRM to fail? i2c related? Message-ID: <20220201103949.11e09ce8@FreeBSD.org> In-Reply-To: <20220131170230.3f9155be@FreeBSD.org> References: <a9560156-4d67-7ca2-e276-31e5585ce58e@FreeBSD.org> <4611d16a-ef17-d8f3-c2c0-1b1091723646@FreeBSD.org> <20220131170230.3f9155be@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 31 Jan 2022 17:02:30 +0100 T=C4=B3l Coosemans <tijl@FreeBSD.org> wrote: > On Sun, 30 Jan 2022 21:23:49 +0300 Vladimir Kondratyev > <wulf@FreeBSD.org> wrote: >> On 30.01.2022 00:25, Stefan Esser wrote: >>> After rebooting with freshly built world, kernel and the amdgpu driver >>> my console stopped working. It goes blank and the display goes into a >>> power save mode, as soon as the amdgpu driver is loaded. >>>=20 >>> The GPU (a Radeon R7 250E) is correctly detected as before, but there >>> is an error message "drmn0: [drm] Cannot find any crtc or sizes". >>>=20 >>> I'm asking here and not on the ports list, since the AMDGPU driver has >>> not been updated for half a year. But to be sure that there is no misma= tch >>> between kernel and user land, I have rebuilt all X11 server and library >>> ports. >>>=20 >>> There have been changes affecting the i2c driver, IIRC, and the error >>> message seems to point at an issue obtaining information from the LCD >>> display. >>=20 >> drm-kmod commit 534aa199c10d forced it to use i2c from base. >>=20 >> You may try to checkout previous revision (444dc58f0247) to find out >> if in-base i2c is guilty or not. >=20 > I found that since base dbc920bd9a9b (linuxkpi interval_tree) > linuxkpi.ko now exports some rb_* functions (from rbtree.h). These are > declared static inline but the compiler may decide not to inline them. > These functions conflict with the ones in linuxkpi_gplv2.ko from > drm-kmod, because both implementations use a different order for the > fields in struct rb_node. Here's a list of functions that linuxkpi.ko and linuxkpi_gplv2.ko have in common in my case. Some are probably ok. device_register i2c_transfer linux_compat_init lkpi_arch_phys_wc_add lkpi_arch_phys_wc_del rb_erase_cached rb_insert_color_cached sysctl_handle_attr
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220201103949.11e09ce8>