On Thu 2016-12-15 23:33:22, Lino Sanfilippo wrote: > On 15.12.2016 22:32, Lino Sanfilippo wrote: > > > 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
signature.asc
Description: Digital signature
