On Fri, Jul 24, 2020 at 5:19 PM David Christensen <d...@linux.vnet.ibm.com> wrote:
> In the working case, tg3_init_hw() returns successfully, resulting in > every instance of napi_disable() being followed by an instance of > napi_enable(). > > In the failing case, tg3_hw_init() returns an error. (This is not > surprising since the system is now preventing the adapter from accessing > its MMIO registers. I'm curious why it doesn't always fail.) When > tg3_hw_init() fails, tg3_netif_start() is not called, and we end up with > two sequential calls to napi_disable(), resulting in multiple hung task > messages. > If the driver fails to initialize the chip completely, the tg3_flags should indicate we are in this failed state. We already have TG3_FLAG_INIT_COMPLETE. Perhaps, we can expand the use of this flag to cover the scenario that you described above. We can clear TG3_FLAG_INIT_COMPLETE before calling tg3_halt() and only set it back when tg3_hw_init() completes successfully. This is the rough idea, but a more detailed analysis on how this flag is used needs to be done first. Assuming this works, the EEH handler can check TG3_FLAG_INIT_COMPLETE to see if we should call tg3_netif_stop(). Another way to fix it is to call dev_close() if tg3_reset_task() fails to re-initialize the device.
