Turn flow control off for sky2. When flow control is on, the transmitter
may get randomly stuck. Perhaps there is hardware problem, but until
Marvell provides errata information for workaround, it should default to off.
Signed-off-by: Stephen Hemminger <[email protected]>
---
drivers/net/sky2.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index 822dd0b..a31dea5 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -3263,7 +3263,7 @@ #endif
/* Auto speed and flow control */
sky2->autoneg = AUTONEG_ENABLE;
- sky2->flow_mode = FC_BOTH;
+ sky2->flow_mode = FC_NONE;
sky2->duplex = -1;
sky2->speed = -1;
--
1.4.1
Hi Stephen,
On Fri, Feb 02, 2007 at 03:34:25PM -0800, Stephen Hemminger wrote:
> Turn flow control off for sky2. When flow control is on, the transmitter
> may get randomly stuck. Perhaps there is hardware problem, but until
> Marvell provides errata information for workaround, it should default to off.
Are you aware of any way to reproduce or at least to increases chances
of occurrences of this problem ? It looks much like a problem I've been
experiencing with Marvell's driver with a 88E8053 chip on 2.4. Doing
"ethtool -r" proved useful to reset the transceiver in production.
When trying to reproduce the problem, I noticed corrupted and duplicated
frames in tcpdump captures when packets between 147 and 496 bytes were
received then re-routed via the same NIC towards a 100 Mbps machine on
the same switch, a Gig Dlink doing flow control. Yes, I know, there are
a lot of variables ! But changing the target machine, or the packet
sizes was enough to stop the corruption. I could not get the transmitter
stuck as I sometimes have in production, but I think that both problems
are related. The fact that a comparable problem is encountered with your
driver really makes me think about a hardware bug :-/
BTW, switching to your driver (sky2-1.5), I could not reproduce the
corruption problem anymore, but I've not yet put it in production
to check if it fixes the transceiver problem. Anyway, it might be
interesting that users who encounter this problem try an old version
of the driver just in case they detect a difference.
regards,
Willy
Stephen Hemminger wrote:
> Turn flow control off for sky2. When flow control is on, the transmitter
> may get randomly stuck. Perhaps there is hardware problem, but until
> Marvell provides errata information for workaround, it should default to off.
>
> Signed-off-by: Stephen Hemminger <[email protected]>
> ---
> drivers/net/sky2.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> index 822dd0b..a31dea5 100644
> --- a/drivers/net/sky2.c
> +++ b/drivers/net/sky2.c
> @@ -3263,7 +3263,7 @@ #endif
>
> /* Auto speed and flow control */
> sky2->autoneg = AUTONEG_ENABLE;
> - sky2->flow_mode = FC_BOTH;
> + sky2->flow_mode = FC_NONE;
I ACK the patch... conditional on some -mm style testing and user ACKs.
Logic: if there were no downsides to disabling flow control globally,
the world's networks would have already done so. Flow control can be
quite helpful, so I while I understand the errata argument, I also want
to understand the full effect of this tiny patch.
Jeff
On Tue, 06 Feb 2007 19:18:07 -0500
Jeff Garzik <[email protected]> wrote:
> Stephen Hemminger wrote:
> > Turn flow control off for sky2. When flow control is on, the transmitter
> > may get randomly stuck. Perhaps there is hardware problem, but until
> > Marvell provides errata information for workaround, it should default to off.
> >
> > Signed-off-by: Stephen Hemminger <[email protected]>
> > ---
> > drivers/net/sky2.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
> > index 822dd0b..a31dea5 100644
> > --- a/drivers/net/sky2.c
> > +++ b/drivers/net/sky2.c
> > @@ -3263,7 +3263,7 @@ #endif
> >
> > /* Auto speed and flow control */
> > sky2->autoneg = AUTONEG_ENABLE;
> > - sky2->flow_mode = FC_BOTH;
> > + sky2->flow_mode = FC_NONE;
>
> I ACK the patch... conditional on some -mm style testing and user ACKs.
>
> Logic: if there were no downsides to disabling flow control globally,
> the world's networks would have already done so. Flow control can be
> quite helpful, so I while I understand the errata argument, I also want
> to understand the full effect of this tiny patch.
>
Actually, the E1000 had it off until recently. The downside is that if
a system is connected on a switch with a gigabit to 100mbit port
and using a stupid protocol like NFS over UDP, then the packet
burst is sure to get truncated so the 8K fragmented UDP
never gets through.