On 9/18/2026, Tantilov, Emil S wrote: > Actually we can't wait on shutdown. If the MBX is defunct, like CP is > down or unresponsive, the shutdown will hang for a very long time. This > is the reason why we wanted to avoid communication on shutdown. Have you > tested the shutdown after stopping the control plane?
No, I have not, and I cannot on this platform: the control plane sits behind the device and I have no way to stop it from the host. So I have to take your point as given, and as written the patch is not acceptable: each teardown transaction uses IDPF_VC_XN_DEFAULT_TIMEOUT_MSEC (60 s), and the teardown per vport is disable_vport, disable_queues (which also waits for the SW marker) and destroy_vport. With a dead CP and two vports that is minutes of hang on every reboot, to remove a fault that only shows up on warm reboots. That trade is wrong. What I would like to propose for v2 is to keep the teardown but bound it: a shutdown-specific timeout, on the order of a second or two, used for those three transactions when the driver is shutting down. If the CP answers, the device is told to stop its queues and the stray writes go away; if it does not, shutdown loses a bounded couple of seconds instead of minutes. Does that direction look acceptable to you, and is there a timeout value you would consider safe? If you would rather not have any mailbox traffic on shutdown at all, then I think the fix has to come from the device side instead, and I would rather know that before sending v2. > This logic already exists in the reset handling, there should be no need > to replicate it here. Do you have a trace and/or exact scenario that > leads to remove being called while in a reset, but MBX is still alive? No, I do not have such a trace. I added idpf_is_reset_detected() defensively rather than from an observed case, and I will drop it in v2. For the record, what we do see without any of this, on arm64 with two idpf functions: after a warm reboot the device still has its queues enabled with the previous kernel's ring addresses, and the first queue reconfiguration in the next boot makes it write SW_MARKER completions into memory that kernel has already reused. 20 of 20 warm reboots on an unpatched control node, none in 151 with the teardown messages delivered. Thanks for the review.
