The iprb driver attempts to detect a transmit stall by keeping the transmit time of the last outstanding frame submitted to the controller. Each time we submit a command to the controller, we update tx_wdog with the current time. We also update tx_wdog each time we reclaim a command that the controller has completed. In iprb_periodic(), we check to make sure this value is not more than 15 seconds in the past, and if it is we reset the controller.

Unfortunately, we only seem to trigger the reclaim routine when we're trying to transmit another packet. If the link is not particularly busy, and no data is transmitted for 15 seconds, it seems like we will spuriously reset the controller which causes a variety of other issues on a system that would have otherwise been working correctly.

A report from the field suggests that by pinging the computer with iprb from another computer, the problem goes away; presumably because we are sending an echo reply each second and keeping the watchdog at bay.

One way to fix this is to call iprb_cmd_reclaim() in the periodic routine, right before we check the watchdog value, to ensure that things are moving along. Indeed, an iprb with this patch applied improves the behaviour.

Another question is: in iprb_cmd_submit(), we set the CB_CMD_I flag on the submitted command iff we believe it is the last available command; i.e., if we have dispatched 128 commands to the controller and heard nothing back. I can't see how this would trigger a reclaim, though, unless there was already another packet about to be sent out -- which in some cases on idle systems there may not be.