Hi!
sorry for the late reply.
No problem. Thanks for the help.
On 11.12.2016 21:11, Pavel Machek wrote:
quoted
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.
quoted
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