Hi Conn, On 2016-01-10 05:20, Conn O'Griofa wrote: > Hi Felix, > > It appears that my hunch was correct, and both are necessary. The > following patch works 100% fine; when the dma stuck condition occurs, > recovery now completes without any link adjust or any other output > from the kernel log*. The tx timeout condition is also avoided thanks > to checking for stuck dma, internet connectivity remains stable, and > the sirq storm never triggers. It looks like your patch, with my > additions, solves the timeout issue perfectly on my device. > > One issue I'd like to bring to your attention: with my changes, > ag71xx_fast_reset is now called for every chipset as part of the > ag71xx_hw_enable function. Prior to this, it was only called during a > link adjust on the ar724x chipsets, but now it's going to be called > by the ar91xx series, too. > > If ag71xx_fast_reset is not suitable for use on the ar91xx series, > the patch is going to need changes (and isolating ag71xx_fast_reset > to ar724x in ag71xx_hw_enable may not be sufficient for the new > ag71xx_restart_work_func to operate properly on ar91xx chips). But if > it is suitable for all chipsets, perhaps it would be a good idea to > call ag71xx_fast_reset for all chipsets in ag71xx_link_adjust, too? > > Conn > > *When testing on my device, I added some debug to log the dma stuck > condition, just to ensure the problem was actually being triggered > during testing. I did some further debugging and created some test cases to trigger DMA stuck detection and issue a device restart. I committed fixes in r48227 and r48228 which work quite well for me. Please test latest trunk on your device.
Thanks, - Felix _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
