Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?

From: Emmanuel Vadot <manu_at_bidouilliste.com>
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>