On Tue, Apr 25, 2023 at 01:14:35PM -0400, Chris Murphy wrote: > > > On Tue, Apr 25, 2023, at 3:01 AM, Mika Westerberg wrote: > > Hi Chris, > > > > Would you be able to bisect this to a mainline commit? > > Difficult in the near term. > > > > At least looking at the changes between v6.3-rc1 and v6.3-rc7 there is > > virtually nothing to any of these drivers involved. The log itself looks > > like: > > > > dev_vdbg(idma64->dma.dev, "%s: status=%#x\n", __func__, status); > > > > so this should not be enabled at all unless CONFIG_DMADEVICES_VDEBUG is > > set to y which seems odd in distro kernel. > > $ grep DMADEVICES /boot/config-6.3.0-0.rc2.20230315git6015b1aca1a2.25.fc39.x86_64+debug > CONFIG_DMADEVICES=y > CONFIG_DMADEVICES_DEBUG=y > # CONFIG_DMADEVICES_VDEBUG is not set > $ grep DMADEVICES /boot/config-6.3.0-0.rc2.20230317git38e04b3e4240.27.fc39.x86_64+debug > CONFIG_DMADEVICES=y > CONFIG_DMADEVICES_DEBUG=y > CONFIG_DMADEVICES_VDEBUG=y > > It follows the bug, though I'm not sure if this is the true source of the problem? Okay, so the issue here I think is just that the VDEBUG is enabled. Since idma64 and I2C share the interrupt, each time a I2C transaction is done the idma64 interrupt handler is called as well: 17: 0 0 18841 0 0 0 0 0 IR-IO-APIC 17-fasteoi i2c_designware.1, idma64.1 so these end up in the dmesg and journal. I suggest to just disable the VDEBUG. Probably was enabled in the Fedora .config by accident as this is something that should not be enabled by distro kernels.