net: mv643xx: interface does not transmit after some time

Andrew Lunn andrew at lunn.ch
Wed Feb 10 14:57:17 PST 2016


On Wed, Feb 10, 2016 at 07:40:54PM +0100, Thomas Schlöter wrote:
> 
> > Am 08.02.2016 um 19:49 schrieb Thomas Schlöter <thomas at schloeter.net>:
> > 
> > 
> >> Am 07.02.2016 um 22:07 schrieb Thomas Schlöter <thomas at schloeter.net>:
> >> 
> >> Am 07.02.2016 um 21:35 schrieb Andrew Lunn <andrew at lunn.ch>:
> >>> 
> >>>>> FWIW, we had a similar bug report in Debian recently:
> >>>>> https://lists.debian.org/debian-arm/2016/01/msg00098.html
> >>> 
> >>> Hi Thomas
> >>> 
> >>> I this thread, Ian Campbell mentions a patch. Please could you try
> >>> that patch and see if it fixes your problem.
> >>> 
> >>> Thanks
> >>> 	Andrew
> >> 
> >> Hi Andrew,
> >> 
> >> I just applied the patch and the NAS is now running it. I???ll try to crash it tonight and keep you informed whether it worked.
> >> 
> >> Thanks
> >> 	Thomas
> > 
> > Hi Andrew,
> > 
> > the patch did not fix the problem. After 1.2 GiB RX and 950 MiB TX, the interface crashed again.
> > 
> > Now I switched off RX/TX offload just to make sure we are talking about the same problem. If we are, the interface should be stable without offload, right?
> > 
> > 	Thomas
> 
> Okay, so I have installed ethtool and switched off all offload features available. Now the NAS is running rock solid for two days. I backed up my Mac using Time Machine / netatalk (450 GiB transferred) and some Linux machines via NFS (100 GiB total) without a problem.
> 
> How much code is used for mv643xx offload functionality?
> Is it possible to debug things in the driver and figure out what happens during the crash?
> Is the hardware offload interface proprietary or reverse engineered or is it a well known API that can be analyzed?

Hi Thomas

Ezequiel Garcia probably knows this part of the driver and hardware
the best...

    Andrew



More information about the linux-arm-kernel mailing list