Hi! > sorry for the late reply.
No problem. Thanks for the help.
> On 11.12.2016 21:11, Pavel Machek wrote:
> >
> > Do you understand what stmmac_tx_err(priv); is supposed to do? In
> > particular, if it is called while the driver is working ok -- should
> > the driver survive that?
>
> As far as I understood it is supposed to fixup an errorneous tx path, e.g. a
> missing tx completion for transmitted frames.
>
> Some drivers do this by restarting only the HW parts responsible for tx, some
> others by restarting the complete hardware.
> But IMO it should also be ok to be called if the HW is still working fine.
>
> > Because it does not currently, and I don't know how to test that
> > code. Unplugging the cable does not provoke that.
> >
> > I tried
> >
> > } else if (unlikely(status == tx_hard_error))
> > stmmac_tx_err(priv);
> > +
> > + {
> > + static int i;
> > + i++;
> > + if (i==1000) {
> > + i = 0;
> > + printk("Simulated error\n");
> > + stmmac_tx_err(priv);
> > + }
> > + }
> > }
> >
>
> Ok, there is this race that Francois mentioned so it is not surprising that
> the driver does not survive the call of stmmac_tx_err() as it is called now.
> Thats why I suggested to do a proper shutdown and restart of the tx path to
> avoid the race.
I actually did experiment with adding locking there, too, and no, no
luck. It seems stmmac_tx_err() is more broken than just locking.
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
