On Thu 2016-12-15 23:33:22, Lino Sanfilippo wrote:
On 15.12.2016 22:32, Lino Sanfilippo wrote:
quoted
Ah ok. Then maybe priv->hw->dma->stop_tx() does not do the job correctly (stop the
tx path properly) and the HW is still active on the tx path while the tx buffers are
freed. OTOH stmmac_release() also stops the phy before the tx (and rx) paths are stopped.
Did you try to stop the phy fist in stmmac_tx_err_work(), too?
Regards,
Lino
And this is the "sledgehammer" approach: Do a complete shutdown and restart
of the hardware in case of tx error (against net-next and only
compile tested).
Wow, thanks a lot. I'll try to get the driver back to the non-working
state, and try it.
I believe I have some idea what is wrong there. (Missing memory barriers).
+static void stmmac_tx_err_work(struct work_struct *work)
+{
+ struct stmmac_priv *priv = container_of(work, struct stmmac_priv,
+ tx_err_work);
+ /* restart netdev */
+ rtnl_lock();
+ stmmac_release(priv->dev);
+ stmmac_open(priv->dev);
+ rtnl_unlock();
+}
Won't this up/down the interface, in a way userspace can observe?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html