Hi, On 05.06.25 17:13, chenglingfei wrote:
> -----原始邮件----- > 发件人: "Sven Peter" <s...@kernel.org> > 发送时间: 2025-06-05 22:02:35 (星期四) > 收件人: chenglingfei <chenglingfei...@ict.ac.cn> > 抄送: j...@jannau.net, aly...@rosenzweig.io, n...@gompa.dev, zhangzhenwei...@ict.ac.cn, wangzh...@ict.ac.cn, ma...@linux.ibm.com, m...@ellerman.id.au, npig...@gmail.com, christophe.le...@csgroup.eu, nav...@kernel.org, andi.sh...@kernel.org, as...@lists.linux.dev, linux-arm-ker...@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-...@vger.kernel.org, linux-ker...@vger.kernel.org > 主题: Re: [BUG] rmmod i2c-pasemi-platform causing kernel crash on Apple M1. > > Hi, > > On 05.06.25 13:55, chenglingfei wrote: > > > > > > > > > -----原始邮件----- > > > 发件人: "Sven Peter" <s...@kernel.org> > > > 发送时间: 2025-06-05 18:25:09 (星期四) > > > 收件人: 程凌飞 <chenglingfei...@ict.ac.cn>, j...@jannau.net, aly...@rosenzweig.io, n...@gompa.dev > > > 抄送: zhangzhenwei...@ict.ac.cn, wangzh...@ict.ac.cn, ma...@linux.ibm.com, m...@ellerman.id.au, npig...@gmail.com, christophe.le...@csgroup.eu, nav...@kernel.org, andi.sh...@kernel.org, as...@lists.linux.dev, linux-arm-ker...@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-...@vger.kernel.org, linux-ker...@vger.kernel.org > > > 主题: Re: [BUG] rmmod i2c-pasemi-platform causing kernel crash on Apple M1. > > > > > > Hi, > > > > > > On 05.06.25 05:02, 程凌飞 wrote: > > > > Hi, all! > > > > > > > > We’ve encountered a kernel crash when running rmmod i2c-pasemi-platform on a Mac Mini M1 (T8103) running Asahi Arch Linux. > > > > > > > > The bug was first found on the Linux v6.6, which is built manually with the Asahi given config to run our services. > > > > At that time, the i2c-pasemi-platform was i2c-apple. > > > > > > > > We noticed in the Linux v6.7, the pasemi is splitted into two separate modules, one of which is i2c-pasemi-platform. > > > > Therefore, we built Linux v6.14.6 and tried to rmmod i2c-pasemi-platform again, the crash still exists. Moreover, we fetched > > > > the latest i2c-pasemi-platform on linux-next(911483b25612c8bc32a706ba940738cc43299496) and asahi, built them and > > > > tested again with Linux v6.14.6, but the crash remains. > > > > > > > > Because kexec is not supported and will never be fully supported on Apple Silicon platforms due to hardware and firmware > > > > design constraints, we can not record the panic logs through kdump. > > > > > > Do you have UART connected to a device under test which you could use to > > > grab the panic log from the kernel? Alternatively you can also run the > > > kernel under m1n1's hypervisor and grab the log that way. It'll emulate > > > the serial port and redirect its output via USB. > > > > > > > I don't have UART, but I have tried to run the kernel under m1n1's hypervisor. However, it does not trigger the release of cs42l83. > > Given that m1n1 provides full peripheral device emulation capability, the most plausible explanation would be an incorrect > > firmware loading sequence. But the documentation of Asahi provides little details about how to generate an initramfs with > > firmware (I think), can you give more guidance about it? > > I'm not sure why you are even trying to create a special initramfs. Just > load your usual kernel using the usual boot flow as a guest. There's > also no firmware involved in i2c and I'm not sure what you mean with > "full peripheral device emulation" either or how that's related to firmware. > You also mention that the crash happens when you run rmmod so I again > don't understand what "it does not trigger the release of cs42l83" means > here. > Well, simply running rmmod i2c-pasemi-platform doesn't directly cause a crash. The crash occurs when the module removal triggers device_remove for cs42l83, which ultimately calls pasemi_smb_waitready in i2c-pasemi-platform. You may refer to the brief analysis provided in my first email for more details. When booting the kernel without m1n1, cs42l83 is automatically probed after i2c-pasemi-platform loads and subsequently removed when executing rmmod i2c-pasemi-platform, resulting in a kernel crash. However, when booting under m1n1, cs42l83 isn't probed or removed -- the device appears to be non-existent. This observation led me to mention "full peripheral device emulation."
I'm still not sure what "full peripheral device emulation" means in that context. If cs42l83 isn't probed that's most likely an issue with your kernel or your device tree or your boot device. Hence my suggestion to just the regular kernel and boot device.
Unrelated, there's something wrong with your email setup, see e.g. https://lore.kernel.org/asahi/6064d018.2b279.19740a7eb1c.coremail.chenglingfei...@ict.ac.cn/ how your mail arrive.
Sven
