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