From: andrew@lunn.ch (Andrew Lunn)
To: linux-arm-kernel@lists.infradead.org
Subject: net: mv643xx: interface does not transmit after some time
Date: Wed, 10 Feb 2016 23:57:17 +0100 [thread overview]
Message-ID: <20160210225717.GD14610@lunn.ch> (raw)
In-Reply-To: <A6128DBC-59DB-4231-A08D-B84C1D8C26CC@schloeter.net>
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@schloeter.net>:
> >
> >
> >> Am 07.02.2016 um 22:07 schrieb Thomas Schl?ter <thomas@schloeter.net>:
> >>
> >> Am 07.02.2016 um 21:35 schrieb Andrew Lunn <andrew@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
next prev parent reply other threads:[~2016-02-10 22:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-06 18:24 net: mv643xx: interface does not transmit after some time Thomas Schlöter
2016-02-06 18:34 ` Andrew Lunn
2016-02-06 23:19 ` Martin Michlmayr
2016-02-07 16:15 ` Adam Baker
2016-02-07 18:04 ` Andrew Lunn
[not found] ` <2ACB3A0B-DD51-43C1-A56E-E7C175645554@schloeter.net>
2016-02-07 20:35 ` Andrew Lunn
2016-02-07 21:07 ` Thomas Schlöter
2016-02-08 18:49 ` Thomas Schlöter
2016-02-10 18:40 ` Thomas Schlöter
2016-02-10 22:57 ` Andrew Lunn [this message]
2016-02-11 14:38 ` Ezequiel Garcia
2016-02-11 14:38 ` Ezequiel Garcia
2016-02-27 20:06 ` Adam Baker
2016-02-27 20:06 ` Adam Baker
2016-02-07 21:11 ` Thomas Schlöter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160210225717.GD14610@lunn.ch \
--to=andrew@lunn.ch \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.