Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
- In reply to: Vladimir Kondratyev : "Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 31 Jan 2022 12:05:12 UTC
On Mon, 31 Jan 2022 14:19:53 +0300 Vladimir Kondratyev <wulf@FreeBSD.org> wrote: > On 30.01.2022 22:43, Stefan Esser wrote: > > Am 30.01.22 um 19:23 schrieb Vladimir Kondratyev: > >> 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. > >>> > >>> 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". > >>> > > [...] > >>> [drm] AMDGPU Display Connectors > >>> [drm] Connector 0: > >>> [drm] DP-1 > >>> [drm] HPD4 > >>> [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 > >>> [drm] Encoders: > >>> [drm] DFP1: INTERNAL_UNIPHY2 > >>> [drm] Connector 1: > >>> [drm] HDMI-A-1 > >>> [drm] HPD1 > >>> [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f > >>> [drm] Encoders: > >>> [drm] DFP2: INTERNAL_UNIPHY2 > >>> [drm] Connector 2: > >>> [drm] DVI-I-1 > >>> [drm] HPD2 > >>> [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b > >>> [drm] Encoders: > >>> [drm] DFP3: INTERNAL_UNIPHY > >>> [drm] CRT1: INTERNAL_KLDSCP_DAC1 > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> drmn0: [drm] Cannot find any crtc or sizes > >>> [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 > >>> > >>> A successful driver attach from a reboot a few days ago had ended in: > >>> > >>> [drm] CRT1: INTERNAL_KLDSCP_DAC1 > >>> [drm] fb mappable at 0xE0503000 > >>> [drm] vram apper at 0xE0000000 > >>> [drm] size 33177600 > >>> [drm] fb depth is 24 > >>> [drm] pitch is 15360 > >>> [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 > >>> > >>> Regards, STefan > >> > >> drm-kmod commit 534aa199c10d forced it to use i2c from base. > > > > Hi Vladimir, > > > > thank you for the information! I'm using drm-devel-kmod, and in fact found > > that 5.5.19.g20211230 works, while 5.7.19.g20220126 (committed as 0c38674b389ad > > on 2022-01-26) causes the failure. > > > >> You may try to checkout previous revision (444dc58f0247) to find out if in-base > >> i2c is guilty or not. > > > > Assuming that the same change to use the system i2c code has been in the latest > > commit to the drm-devel-kmod port, this should be proven, now. ;-) > > > > These is the list of in-kernel i2c modules on my system (a Ryzen 9 5950 on an > > ASUS mainboard with B550 chip-set): > > > > $ kldstat -v | grep iic > > 68 iicsmb/smbus > > 67 iicbus/iicsmb > > 66 iichb/iicbus > > 65 iicbb/iicbus > > 64 iicbus/iic > > 63 iicbus/ic > > 213 lkpi_iicbb/iicbb > > 212 lkpi_iic/lkpi_iicbb > > 211 lkpi_iic/iicbus > > 210 drmn/lkpi_iic > > 56 iichid/hidbus > > > > Can I help debug this issue? > > > > I could re-install the latest version and boot with hw.dri.drm_debug or > > dev.drm.drm_debug set? > > > > Or are there other settings to get a debug log from the i2c side? > > > > Regards, STefan > > > > PS: I'm keeping the CC to current@, since this might be an issue in the i2c > > kernel code ... > > There are no successful lkpi_iic attachments in your output. They look like: > > lkpi_iic0: <LinuxKPI I2C> on drmn0 > > Please share your `devinfo -v` output. > Kldload output with verbose boot enabled can be helpful too. That's because this card is probably using the bitbang part. As stated in the commit this wasn't tested as I don't have compatible hardware. It's likely a timing issue in the bitbang part. That's the main reason it's only in master and 5.7 branch of drm-kmod, so people can debug/fix. -- Emmanuel Vadot <manu@bidouilliste.com> <manu@FreeBSD.org>