On Wed, 2022-08-24 at 21:11 +0000, Yu, Fenghua wrote: > Hi, Jerry, > > > I see another potential issue. If a software reset is attempted > > idxd_device_reinit() > > will be called which walks the wqs, and if a wq has the state > > IDXD_WQ_ENABLED it calls idxd_wq_enable(), but the first thing > > idxd_wq_enable() does is see that the state is IDXD_WQ_ENABLED and > > returns 0. > > Without the wq enable command being sent, it will not be re- > > enabled, yes? > > Could you please describe how to reproduce the issues and test case? Nothing special, just running dsa_user_test_runner.sh from idxd-config (3.4.6.3) with intel_iommu=on,sm_on (default is lazy dma domain) on an Intel supplied SPR system. During the run there is a dmar fault, halts the device with it needing an flr reset. That is where the deadlock was noticed. Then after the dsa_user_runner.sh fails, if you do modprobe -r idxd, you hit the warning in devm_iounmap(). The idxd_device_reinit() case I haven't reproduced, I'm just looking at the code. I should note that I've only run into an issue with that model of system. The other models of SPR systems don't hit an issue. This is with a 6.0-rc1 kernel, and our kernel. I'm guessing there is an issue with that model of system/fw. I've seen both fault reasons 0x50 and 0x58 when it faults. Regards, Jerry > > Thanks. > > -Fenghua
