[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170613083852.GA17031@amd>
Date: Tue, 13 Jun 2017 10:38:52 +0200
From: Pavel Machek <pavel@....cz>
To: Niklas Cassel <niklas.cassel@...s.com>
Cc: Alexandre Torgue <alexandre.torgue@...com>,
Giuseppe Cavallaro <peppe.cavallaro@...com>,
Joao Pinto <Joao.Pinto@...opsys.com>,
Lars Persson <larper@...s.com>, netdev <netdev@...r.kernel.org>
Subject: Re: stmmac tx timeout
Hi!
> > @@ -2043,7 +2063,11 @@ static netdev_tx_t stmmac_xmit(struct sk_buff
> > *skb, stru\
> > ct net_device *dev)
> > } else
> > priv->tx_count_frames = 0;
> >
> > + dma_rmb();
> > + dma_wmb();
> > /* To avoid raise condition */
> > + BUG_ON(first->des01.etx.own); /* This BUG_ON seems to be enough.
> > + Replacing it with barriers is _not_enough. */
> > priv->hw->desc->set_tx_owner(first);
> > wmb();
> >
> > No, the BUG_ON() does not trigger. Yes, it still fixes the driver for
> > me. You may want to verify it has same effect for you.
>
> Hello Pavel,
>
> I am sincerely grateful for you help.
>
> I forward ported your patch to 4.9,
> however, I could still get tx timeouts.
>
> Thankfully I finally found the root cause of
> my tx timeouts, see the patch I've submitted
> here:
>
> http://marc.info/?l=linux-kernel&m=149673393525236
Thanks a lot for the information. And unfortunately yes, there's
probably more work to do in the stmmac driver; for example it would be
good if _tx_timeout were actually able to recover the card. I probably
have patch for that somewhere, too...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists