sky2 still badly broken

sky2 still badly broken

[Niccolò Belli]

dmesg is full of

[ 1464.914044] sky2 0000:06:00.0: eth0: rx error, status 0x5220002 
length 1314
[ 1465.005628] sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
length 532
[ 1465.204459] sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
length 532
[ 1465.825909] sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
length 532
[ 1468.715858] net_ratelimit: 3 callbacks suppressed
[ 1468.715865] sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
length 532

dhcp does not work (after a few minutes it does not renew the ip)

while under heavy load the card resets and I have to unload and reload 
the module

also transfer rate is VERY low.

lowering the mtu does help a bit, but it doesn't make miracles...

kernel 3.4.0-rc4

06:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8055 PCI-E 
Gigabit Ethernet Controller (rev 13)

http://forums.gentoo.org/viewtopic-t-487018-start-0-postdays-0-postorder-asc-highlight-.html

Thanks,
Niccolò

[RFT] sky2: fix status length check on older chips

[Stephen Hemminger]

Mirko and I were working on a related issue, here is his fix.
I proposed a similar alternative, but he was unavailable to test it,
and therefore was still pending.  Does this fix your problem?
=================


From: From: Mirko Lindner <mlindner@marvell.com>

Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older
supported chips. Sometimes the VLAN bit is not set for valid VLAN packets
and also sometimes the VLAN bit is set for non-VLAN packets that came after
a VLAN packet. This results in a receive length error when VLAN hardware
tagging is enabled.

Fix: The driver uses only VLAN information included in VLAN status list elements,
that signals that the VLAN tag field is valid. It must ignore the VLAN bit in the
MAC RX Status Word. An additional variable set when evaluating the VLAN opcodes
is used to indicate that the received packet is a VLAN packet and a packet length
correction (subtraction of VLAN header length) must be done.

Signed-off-by: Mirko Lindner <mlindner@marvell.com>



--- a/drivers/net/ethernet/marvell/sky2.c	2012-04-18 23:44:40.637276647 -0700
+++ b/drivers/net/ethernet/marvell/sky2.c	2012-04-27 13:36:07.487834432 -0700
@@ -2580,7 +2580,7 @@ static struct sk_buff *sky2_receive(stru
 	struct sk_buff *skb = NULL;
 	u16 count = (status & GMR_FS_LEN) >> 16;
 
-	if (status & GMR_FS_VLAN)
+	if (sky2->rx_vlan)
 		count -= VLAN_HLEN;	/* Account for vlan tag */
 
 	netif_printk(sky2, rx_status, KERN_DEBUG, dev,
@@ -2646,11 +2646,13 @@ static inline void sky2_tx_done(struct n
 	}
 }
 
-static inline void sky2_skb_rx(const struct sky2_port *sky2,
-			       u32 status, struct sk_buff *skb)
+static inline void sky2_skb_rx(struct sky2_port *sky2,
+				struct sk_buff *skb)
 {
-	if (status & GMR_FS_VLAN)
+	if (sky2->rx_vlan) {
 		__vlan_hwaccel_put_tag(skb, be16_to_cpu(sky2->rx_tag));
+		sky2->rx_vlan = 0;
+	}
 
 	if (skb->ip_summed == CHECKSUM_NONE)
 		netif_receive_skb(skb);
--- a/drivers/net/ethernet/marvell/sky2.h	2012-02-13 09:23:53.642447236 -0800
+++ b/drivers/net/ethernet/marvell/sky2.h	2012-04-27 13:36:07.487834432 -0700
@@ -2242,6 +2242,7 @@ struct sky2_port {
 	u16		     rx_data_size;
 	u16		     rx_nfrags;
 	u16		     rx_tag;
+	u8		     rx_vlan;
 
 	struct {
 		unsigned long last;

Re: [RFT] sky2: fix status length check on older chips

[David Miller]

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Fri, 27 Apr 2012 13:41:27 -0700

> Mirko and I were working on a related issue, here is his fix.
> I proposed a similar alternative, but he was unavailable to test it,
> and therefore was still pending.  Does this fix your problem?

Nothing sets ->rx_vlan in that patch.

Re: [RFT] sky2: fix status length check on older chips

[Stephen Hemminger]

Mirko and I were working on a related issue, here is his fix.
I proposed a similar alternative, but he was unavailable to test it,
and therefore was still pending.  Does this fix your problem?

Resend with missing bits.

The cleaner alternative is to not use the boolean flag, but instead
put tag on skb directly (eliminating rx_tag and rx_vlan from
data structure).
=================

From: From: Mirko Lindner <mlindner@marvell.com>

Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older
supported chips. Sometimes the VLAN bit is not set for valid VLAN packets
and also sometimes the VLAN bit is set for non-VLAN packets that came after
a VLAN packet. This results in a receive length error when VLAN hardware
tagging is enabled.

Fix: The driver uses only VLAN information included in VLAN status list elements,
that signals that the VLAN tag field is valid. It must ignore the VLAN bit in the
MAC RX Status Word. An additional variable set when evaluating the VLAN opcodes
is used to indicate that the received packet is a VLAN packet and a packet length
correction (subtraction of VLAN header length) must be done.

Signed-off-by: Mirko Lindner <mlindner@marvell.com>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

---
--- a/drivers/net/ethernet/marvell/sky2.c	2012-04-18 23:44:40.637276647 -0700
+++ b/drivers/net/ethernet/marvell/sky2.c	2012-04-27 13:52:06.154756866 -0700
@@ -2580,7 +2580,7 @@ static struct sk_buff *sky2_receive(stru
 	struct sk_buff *skb = NULL;
 	u16 count = (status & GMR_FS_LEN) >> 16;
 
-	if (status & GMR_FS_VLAN)
+	if (sky2->rx_vlan)
 		count -= VLAN_HLEN;	/* Account for vlan tag */
 
 	netif_printk(sky2, rx_status, KERN_DEBUG, dev,
@@ -2646,11 +2646,13 @@ static inline void sky2_tx_done(struct n
 	}
 }
 
-static inline void sky2_skb_rx(const struct sky2_port *sky2,
-			       u32 status, struct sk_buff *skb)
+static inline void sky2_skb_rx(struct sky2_port *sky2,
+				struct sk_buff *skb)
 {
-	if (status & GMR_FS_VLAN)
+	if (sky2->rx_vlan) {
 		__vlan_hwaccel_put_tag(skb, be16_to_cpu(sky2->rx_tag));
+		sky2->rx_vlan = 0;
+	}
 
 	if (skb->ip_summed == CHECKSUM_NONE)
 		netif_receive_skb(skb);
@@ -2772,10 +2774,12 @@ static int sky2_status_intr(struct sky2_
 			break;
 
 		case OP_RXVLAN:
+			sky2->rx_vlan = 1;
 			sky2->rx_tag = length;
 			break;
 
 		case OP_RXCHKSVLAN:
+			sky2->rx_vlan = 1;
 			sky2->rx_tag = length;
 			/* fall through */
 		case OP_RXCHKS:
--- a/drivers/net/ethernet/marvell/sky2.h	2012-02-13 09:23:53.642447236 -0800
+++ b/drivers/net/ethernet/marvell/sky2.h	2012-04-27 13:36:07.487834432 -0700
@@ -2242,6 +2242,7 @@ struct sky2_port {
 	u16		     rx_data_size;
 	u16		     rx_nfrags;
 	u16		     rx_tag;
+	u8		     rx_vlan;
 
 	struct {
 		unsigned long last;

Re: [RFT] sky2: fix status length check on older chips

[Niccolò Belli]

It doesn't compile against 3.4-rc4:

   CC [M]  drivers/net/ethernet/intel/e1000e/param.o
   CC [M]  drivers/net/ethernet/marvell/sky2.o
   CC [M]  drivers/net/ethernet/intel/e1000e/ethtool.o
   CC [M]  net/sunrpc/svc_xprt.o
drivers/net/ethernet/marvell/sky2.c: In function ‘sky2_status_intr’:
drivers/net/ethernet/marvell/sky2.c:2769:4: warning: passing argument 2 
of ‘sky2_skb_rx’ makes pointer from integer without a cast
drivers/net/ethernet/marvell/sky2.c:2649:20: note: expected ‘struct 
sk_buff *’ but argument is of type ‘u32’
drivers/net/ethernet/marvell/sky2.c:2769:4: error: too many arguments to 
function ‘sky2_skb_rx’
drivers/net/ethernet/marvell/sky2.c:2649:20: note: declared here
make[4]: *** [drivers/net/ethernet/marvell/sky2.o] Errore 1
make[3]: *** [drivers/net/ethernet/marvell] Errore 2
make[3]: *** Attesa dei processi non terminati....
   CC [M]  net/sunrpc/backchannel_rqst.o
   CC [M]  drivers/net/ethernet/intel/e1000e/netdev.o


Niccolò

Re: [RFT] sky2: fix status length check on older chips

[Stephen Hemminger]

Are you using VLAN's? the whole problem report only applies if using VLAN
on old hardware.

[PATCH] sky2: fix receive length error in mixed non-VLAN/VLAN traffic

[Stephen Hemminger]

Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older
supported chips. Sometimes the VLAN bit is not set for valid VLAN packets
and also sometimes the VLAN bit is set for non-VLAN packets that came after
a VLAN packet. This results in a receive length error when VLAN hardware
tagging is enabled.

Fix: The driver uses only VLAN information included in VLAN status list elements,
that signals that the VLAN tag field is valid. It must ignore the VLAN bit in the
MAC RX Status Word. An additional variable set when evaluating the VLAN opcodes
is used to indicate that the received packet is a VLAN packet and a packet length
correction (subtraction of VLAN header length) must be done.

This is an alternative to Mirko's patch that relies on the new method of
encoding VLAN tag, and therefore means extra code can be removed.

Testing: Tested with regular and VLAN traffic on 88E8056, but this chip
does not have the bug, just proves that the alternative method of handling
VLAN tag will work.

Reported-by: Mirko Lindner <mlindner@marvell.com>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

---
This version is built and tested against net-next (3.4-rc4)

--- a/drivers/net/ethernet/marvell/sky2.c	2012-04-27 19:37:31.891137630 -0700
+++ b/drivers/net/ethernet/marvell/sky2.c	2012-04-27 19:42:54.242757283 -0700
@@ -2568,6 +2568,14 @@ nobuf:
 	return NULL;
 }
 
+/* Apply vlan tag to the current Rx skb */
+static inline void sky2_rx_tag(struct sky2_port *sky2, u16 tag)
+{
+	struct rx_ring_info *re = sky2->rx_ring + sky2->rx_next;
+
+	__vlan_hwaccel_put_tag(re->skb, be16_to_cpu(tag));
+}
+
 /*
  * Receive one packet.
  * For larger packets, get new buffer.
@@ -2580,7 +2588,7 @@ static struct sk_buff *sky2_receive(stru
 	struct sk_buff *skb = NULL;
 	u16 count = (status & GMR_FS_LEN) >> 16;
 
-	if (status & GMR_FS_VLAN)
+	if (vlan_tx_tag_present(re->skb))
 		count -= VLAN_HLEN;	/* Account for vlan tag */
 
 	netif_printk(sky2, rx_status, KERN_DEBUG, dev,
@@ -2646,12 +2654,9 @@ static inline void sky2_tx_done(struct n
 	}
 }
 
-static inline void sky2_skb_rx(const struct sky2_port *sky2,
-			       u32 status, struct sk_buff *skb)
+static inline void sky2_skb_rx(struct sky2_port *sky2,
+			       struct sk_buff *skb)
 {
-	if (status & GMR_FS_VLAN)
-		__vlan_hwaccel_put_tag(skb, be16_to_cpu(sky2->rx_tag));
-
 	if (skb->ip_summed == CHECKSUM_NONE)
 		netif_receive_skb(skb);
 	else
@@ -2764,7 +2769,7 @@ static int sky2_status_intr(struct sky2_
 
 			skb->protocol = eth_type_trans(skb, dev);
 
-			sky2_skb_rx(sky2, status, skb);
+			sky2_skb_rx(sky2, skb);
 
 			/* Stop after net poll weight */
 			if (++work_done >= to_do)
@@ -2772,11 +2777,11 @@ static int sky2_status_intr(struct sky2_
 			break;
 
 		case OP_RXVLAN:
-			sky2->rx_tag = length;
+			sky2_rx_tag(sky2, length);
 			break;
 
 		case OP_RXCHKSVLAN:
-			sky2->rx_tag = length;
+			sky2_rx_tag(sky2, length);
 			/* fall through */
 		case OP_RXCHKS:
 			if (likely(dev->features & NETIF_F_RXCSUM))
--- a/drivers/net/ethernet/marvell/sky2.h	2012-04-27 19:37:31.891137630 -0700
+++ b/drivers/net/ethernet/marvell/sky2.h	2012-04-27 19:41:01.857495110 -0700
@@ -2241,7 +2241,6 @@ struct sky2_port {
 	u16		     rx_pending;
 	u16		     rx_data_size;
 	u16		     rx_nfrags;
-	u16		     rx_tag;
 
 	struct {
 		unsigned long last;

Re: [PATCH] sky2: fix receive length error in mixed non-VLAN/VLAN traffic

[Stephen Hemminger]

On Fri, 27 Apr 2012 20:03:10 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:

> Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older
> supported chips. Sometimes the VLAN bit is not set for valid VLAN packets
> and also sometimes the VLAN bit is set for non-VLAN packets that came after
> a VLAN packet. This results in a receive length error when VLAN hardware
> tagging is enabled.
> 
> Fix: The driver uses only VLAN information included in VLAN status list elements,
> that signals that the VLAN tag field is valid. It must ignore the VLAN bit in the
> MAC RX Status Word. An additional variable set when evaluating the VLAN opcodes
> is used to indicate that the received packet is a VLAN packet and a packet length
> correction (subtraction of VLAN header length) must be done.
> 
> This is an alternative to Mirko's patch that relies on the new method of
> encoding VLAN tag, and therefore means extra code can be removed.
> 
> Testing: Tested with regular and VLAN traffic on 88E8056, but this chip
> does not have the bug, just proves that the alternative method of handling
> VLAN tag will work.
> 
> Reported-by: Mirko Lindner <mlindner@marvell.com>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> 

This doesn't work. Furthur testing just crapped out with lots
of rx length errors in mixed vlan/non-vlan traffic case.

Re: [RFT] sky2: fix status length check on older chips

[Niccolò Belli]

Il 28/04/2012 04:46, Stephen Hemminger ha scritto:
> Are you using VLAN's? the whole problem report only applies if using VLAN
> on old hardware.

No, I don't use VLANs. There are VLANs in my network but I simply 
connect to the default one from my laptop.

Niccolò

Re: [RFT] sky2: fix status length check on older chips

[Stephen Hemminger]

On Sat, 28 Apr 2012 12:25:33 +0200
Niccolò Belli <darkbasic@linuxsystems.it> wrote:

> Il 28/04/2012 04:46, Stephen Hemminger ha scritto:
> > Are you using VLAN's? the whole problem report only applies if using VLAN
> > on old hardware.
> 
> No, I don't use VLANs. There are VLANs in my network but I simply 
> connect to the default one from my laptop.

Still your laptop will receive vlan frames (even just broadcasts).

Re: [RFT] sky2: fix status length check on older chips

[Niccolò Belli]

Il 30/04/2012 18:19, Stephen Hemminger ha scritto:
> Still your laptop will receive vlan frames (even just broadcasts).

Right, so I tested it with a point2point connection: I have the very 
same problem.

Niccolò

Re: sky2 still badly broken

[Stephen Hemminger]

On Fri, 27 Apr 2012 22:15:10 +0200
Niccolò Belli <darkbasic@linuxsystems.it> wrote:

> dmesg is full of
> 
> [ 1464.914044] sky2 0000:06:00.0: eth0: rx error, status 0x5220002 
> length 1314
> [ 1465.005628] sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
> length 532
> [ 1465.204459] sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
> length 532
> [ 1465.825909] sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
> length 532
> [ 1468.715858] net_ratelimit: 3 callbacks suppressed
> [ 1468.715865] sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
> length 532
> 
> dhcp does not work (after a few minutes it does not renew the ip)
> 
> while under heavy load the card resets and I have to unload and reload 
> the module
> 
> also transfer rate is VERY low.
> 
> lowering the mtu does help a bit, but it doesn't make miracles...
> 
> kernel 3.4.0-rc4
> 
> 06:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8055 PCI-E 
> Gigabit Ethernet Controller (rev 13)
> 
> http://forums.gentoo.org/viewtopic-t-487018-start-0-postdays-0-postorder-asc-highlight-.html

You are getting CRC and FIFO overrun errors. What laptop is this?
Everything works fine on my old Fuijitsu with same chip (but rev 14).
You could try taking out the status bit checks and see if the
packets are really okay and the Marvell chip is complaining about
bogus status.


The Gentoo thread is so old as to be meaningless and unrelated.

Re: sky2 still badly broken

[Niccolò Belli]

Il 30/04/2012 21:25, Stephen Hemminger ha scritto:
> You are getting CRC and FIFO overrun errors. What laptop is this?
> Everything works fine on my old Fuijitsu with same chip (but rev 14).
> You could try taking out the status bit checks and see if the
> packets are really okay and the Marvell chip is complaining about
> bogus status.

Laptop is a Samsung X360. I will make a little dump.

Niccolò

Re: sky2 still badly broken

[Niccolò Belli]

Il 30/04/2012 21:25, Stephen Hemminger ha scritto:
> You are getting CRC and FIFO overrun errors. What laptop is this?
> Everything works fine on my old Fuijitsu with same chip (but rev 14).
> You could try taking out the status bit checks and see if the
> packets are really okay and the Marvell chip is complaining about
> bogus status.

I compiled 3.4-rc5 + both sky2 patches you recently published and I did 
some more tests:

Point to point: works flawlessly.
Attached to the switch: rx errors, even downloading a very small 89 KB 
file :(

This is the dump using IPv4:
http://files.linuxsystems.it/temp/2012-05/sky2_ipv4.pcap

dmesg (I did an rmmod -f sky2 before doing the test):
[ 1147.885026] sky2 0000:06:00.0: eth0: disabling interface
[ 1148.909548] sky2: driver version 1.30
[ 1148.909764] sky2 0000:06:00.0: Yukon-2 EC Ultra chip revision 3
[ 1148.914367] sky2 0000:06:00.0: irq 45 for MSI/MSI-X
[ 1148.916310] sky2 0000:06:00.0: eth0: addr 00:13:77:b4:1b:fa
[ 1148.942297] sky2 0000:06:00.0: eth0: enabling interface
[ 1148.944225] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1151.496295] sky2 0000:06:00.0: eth0: Link is up at 1000 Mbps, full 
duplex, flow control rx
[ 1151.497614] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1178.479437] device eth0 entered promiscuous mode
[ 1179.541707] *sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
length 1468*
[ 1179.544110] *sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
length 1468*
[ 1181.642598] device eth0 left promiscuous mode




This is the dump using IPv6:
http://files.linuxsystems.it/temp/2012-05/sky2_ipv6.pcap

dmesg (I did an rmmod -f sky2 before doing the test):
[ 1314.225572] sky2 0000:06:00.0: eth0: disabling interface
[ 1315.248523] sky2: driver version 1.30
[ 1315.248731] sky2 0000:06:00.0: Yukon-2 EC Ultra chip revision 3
[ 1315.249333] sky2 0000:06:00.0: irq 45 for MSI/MSI-X
[ 1315.250307] sky2 0000:06:00.0: eth0: addr 00:13:77:b4:1b:fa
[ 1315.271364] sky2 0000:06:00.0: eth0: enabling interface
[ 1315.273015] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1317.875985] sky2 0000:06:00.0: eth0: Link is up at 1000 Mbps, full 
duplex, flow control rx
[ 1317.877311] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1345.946062] device eth0 entered promiscuous mode
[ 1349.119848] device eth0 left promiscuous mode
[ 1376.231698] device eth0 entered promiscuous mode
[ 1377.369095] *sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
length 1468*
[ 1379.618257] device eth0 left promiscuous mode



Switch is a Netgear GS724Tv3 firmware 5.0.3.5


Cheers,
Niccolò

Re: sky2 still badly broken

[Stephen Hemminger]

On Wed, 02 May 2012 17:12:06 +0200
Niccolò Belli <darkbasic@linuxsystems.it> wrote:

> Il 30/04/2012 21:25, Stephen Hemminger ha scritto:
> > You are getting CRC and FIFO overrun errors. What laptop is this?
> > Everything works fine on my old Fuijitsu with same chip (but rev 14).
> > You could try taking out the status bit checks and see if the
> > packets are really okay and the Marvell chip is complaining about
> > bogus status.
> 
> I compiled 3.4-rc5 + both sky2 patches you recently published and I did 
> some more tests:
> 
> Point to point: works flawlessly.
> Attached to the switch: rx errors, even downloading a very small 89 KB 
> file :(
> 
> This is the dump using IPv4:
> http://files.linuxsystems.it/temp/2012-05/sky2_ipv4.pcap
> 
> dmesg (I did an rmmod -f sky2 before doing the test):
> [ 1147.885026] sky2 0000:06:00.0: eth0: disabling interface
> [ 1148.909548] sky2: driver version 1.30
> [ 1148.909764] sky2 0000:06:00.0: Yukon-2 EC Ultra chip revision 3
> [ 1148.914367] sky2 0000:06:00.0: irq 45 for MSI/MSI-X
> [ 1148.916310] sky2 0000:06:00.0: eth0: addr 00:13:77:b4:1b:fa
> [ 1148.942297] sky2 0000:06:00.0: eth0: enabling interface
> [ 1148.944225] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 1151.496295] sky2 0000:06:00.0: eth0: Link is up at 1000 Mbps, full 
> duplex, flow control rx
> [ 1151.497614] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [ 1178.479437] device eth0 entered promiscuous mode
> [ 1179.541707] *sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
> length 1468*
> [ 1179.544110] *sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
> length 1468*
> [ 1181.642598] device eth0 left promiscuous mode
> 
> 
> 
> 
> This is the dump using IPv6:
> http://files.linuxsystems.it/temp/2012-05/sky2_ipv6.pcap
> 
> dmesg (I did an rmmod -f sky2 before doing the test):
> [ 1314.225572] sky2 0000:06:00.0: eth0: disabling interface
> [ 1315.248523] sky2: driver version 1.30
> [ 1315.248731] sky2 0000:06:00.0: Yukon-2 EC Ultra chip revision 3
> [ 1315.249333] sky2 0000:06:00.0: irq 45 for MSI/MSI-X
> [ 1315.250307] sky2 0000:06:00.0: eth0: addr 00:13:77:b4:1b:fa
> [ 1315.271364] sky2 0000:06:00.0: eth0: enabling interface
> [ 1315.273015] ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 1317.875985] sky2 0000:06:00.0: eth0: Link is up at 1000 Mbps, full 
> duplex, flow control rx
> [ 1317.877311] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [ 1345.946062] device eth0 entered promiscuous mode
> [ 1349.119848] device eth0 left promiscuous mode
> [ 1376.231698] device eth0 entered promiscuous mode
> [ 1377.369095] *sky2 0000:06:00.0: eth0: rx error, status 0x7ffc0001 
> length 1468*
> [ 1379.618257] device eth0 left promiscuous mode
> 
> 
> 
> Switch is a Netgear GS724Tv3 firmware 5.0.3.5
> 
> 
> Cheers,
> Niccolò

It could be that your switch doesn't do autonegotiation or flow
control. You are getting receive fifo overflow errors.

Re: sky2 still badly broken

[Niccolò Belli]

Il 02/05/2012 20:56, Stephen Hemminger ha scritto:
> It could be that your switch doesn't do autonegotiation or flow
> control. You are getting receive fifo overflow errors.

I don't have this problem with other NICs. Also transfer rate is very 
low (even 2 MB/s sometimes) while I get ~110MB/s with other NICs (and 
the same switch of course).

Niccolò

Re: sky2 still badly broken

[Stephen Hemminger]

On Thu, 03 May 2012 11:40:10 +0200
Niccolò Belli <darkbasic@linuxsystems.it> wrote:

> Il 02/05/2012 20:56, Stephen Hemminger ha scritto:
> > It could be that your switch doesn't do autonegotiation or flow
> > control. You are getting receive fifo overflow errors.
> 
> I don't have this problem with other NICs. Also transfer rate is very 
> low (even 2 MB/s sometimes) while I get ~110MB/s with other NICs (and 
> the same switch of course).
> 
> Niccolò

The receiver on some versions of the chip can't keep up with full speed
of 1G bit/sec. The receive  FIFO has hardware issues, and since I don't
work for Marvell, working around the problem is guesswork. Without exact
information all that can be done is have a timeout and blunt force reset
logic. The vendor driver sk98lin has the same brute force logic, but may
just not print the message.

Re: sky2 still badly broken

[Niccolò Belli]

Il 03/05/2012 17:23, Stephen Hemminger ha scritto:
> The receiver on some versions of the chip can't keep up with full speed
> of 1G bit/sec. The receive  FIFO has hardware issues, and since I don't
> work for Marvell, working around the problem is guesswork. Without exact
> information all that can be done is have a timeout and blunt force reset
> logic. The vendor driver sk98lin has the same brute force logic, but may
> just not print the message.

If I lower the speed to 100Mb/s I don't have rx errors anymore *BUT* 
when using dhcp after a while the network doesn't work anymore:

64 bytes from 8.8.8.8: icmp_req=590 ttl=47 time=61.7 ms
64 bytes from 8.8.8.8: icmp_req=591 ttl=47 time=62.0 ms
64 bytes from 8.8.8.8: icmp_req=592 ttl=47 time=62.0 ms
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable


I have no problems with dhcp using wifi or other NICs.

Niccolò

Re: sky2 still badly broken

[Stephen Hemminger]

On Thu, 03 May 2012 20:06:11 +0200
Niccolò Belli <darkbasic@linuxsystems.it> wrote:

> Il 03/05/2012 17:23, Stephen Hemminger ha scritto:
> > The receiver on some versions of the chip can't keep up with full speed
> > of 1G bit/sec. The receive  FIFO has hardware issues, and since I don't
> > work for Marvell, working around the problem is guesswork. Without exact
> > information all that can be done is have a timeout and blunt force reset
> > logic. The vendor driver sk98lin has the same brute force logic, but may
> > just not print the message.
> 
> If I lower the speed to 100Mb/s I don't have rx errors anymore *BUT* 
> when using dhcp after a while the network doesn't work anymore:
> 
> 64 bytes from 8.8.8.8: icmp_req=590 ttl=47 time=61.7 ms
> 64 bytes from 8.8.8.8: icmp_req=591 ttl=47 time=62.0 ms
> 64 bytes from 8.8.8.8: icmp_req=592 ttl=47 time=62.0 ms
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> ping: sendmsg: Network is unreachable
> 
> 
> I have no problems with dhcp using wifi or other NICs.
> 
> Niccolò

Maybe ethtool registers have some info?

# ethtool -S eth0
NIC statistics:
     tx_bytes: 3640274
     rx_bytes: 61588953
     tx_broadcast: 641
     rx_broadcast: 9964
     tx_multicast: 126
     rx_multicast: 1501
     tx_unicast: 32683
     rx_unicast: 50415
     tx_mac_pause: 0
     rx_mac_pause: 0
     collisions: 0
     late_collision: 0
     aborted: 0
     single_collisions: 0
     multi_collisions: 0
     rx_short: 0
     rx_runt: 0
     rx_64_byte_packets: 8704
     rx_65_to_127_byte_packets: 4414
     rx_128_to_255_byte_packets: 6218
     rx_256_to_511_byte_packets: 1289
     rx_512_to_1023_byte_packets: 1777
     rx_1024_to_1518_byte_packets: 39478
     rx_1518_to_max_byte_packets: 0
     rx_too_long: 0
     rx_fifo_overflow: 0
     rx_jabber: 0
     rx_fcs_error: 0
     tx_64_byte_packets: 1628
     tx_65_to_127_byte_packets: 27483
     tx_128_to_255_byte_packets: 2885
     tx_256_to_511_byte_packets: 637
     tx_512_to_1023_byte_packets: 429
     tx_1024_to_1518_byte_packets: 388
     tx_1519_to_max_byte_packets: 0
     tx_fifo_underrun: 0


And if you enable the debugfs option there is more info
hidden there.

# mount -t debugfs debugfs /sys/kernel/debug
# cat /sys/kernel/debug/sky2/eth0

Re: sky2 still badly broken

[Niccolò Belli]

Il 03/05/2012 20:15, Stephen Hemminger ha scritto:
> Maybe ethtool registers have some info?
>
> # ethtool -S eth0

After:
64 bytes from 8.8.8.8: icmp_req=592 ttl=47 time=61.0 ms
64 bytes from 8.8.8.8: icmp_req=593 ttl=47 time=64.9 ms
64 bytes from 8.8.8.8: icmp_req=594 ttl=47 time=61.8 ms
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
ping: sendmsg: Network is unreachable
[...]

I get:

laptop ~ # ethtool eth0
Settings for eth0:
         Supported ports: [ TP ]
         Supported link modes:   10baseT/Half 10baseT/Full
                                 100baseT/Half 100baseT/Full
                                 1000baseT/Half 1000baseT/Full
         Supported pause frame use: No
         Supports auto-negotiation: Yes
         Advertised link modes:  100baseT/Full
         Advertised pause frame use: No
         Advertised auto-negotiation: Yes
         Speed: 100Mb/s
         Duplex: Full
         Port: Twisted Pair
         PHYAD: 0
         Transceiver: internal
         Auto-negotiation: on
         MDI-X: Unknown
         Supports Wake-on: pg
         Wake-on: g
         Current message level: 0x000000ff (255)
                                drv probe link timer ifdown ifup rx_err 
tx_err
         Link detected: yes
laptop ~ # ethtool -S eth0
NIC statistics:
      tx_bytes: 118170
      rx_bytes: 891033
      tx_broadcast: 36
      rx_broadcast: 346
      tx_multicast: 4
      rx_multicast: 332
      tx_unicast: 1131
      rx_unicast: 1235
      tx_mac_pause: 0
      rx_mac_pause: 0
      collisions: 0
      late_collision: 0
      aborted: 0
      single_collisions: 0
      multi_collisions: 0
      rx_short: 0
      rx_runt: 0
      rx_64_byte_packets: 344
      rx_65_to_127_byte_packets: 654
      rx_128_to_255_byte_packets: 362
      rx_256_to_511_byte_packets: 50
      rx_512_to_1023_byte_packets: 11
      rx_1024_to_1518_byte_packets: 492
      rx_1518_to_max_byte_packets: 0
      rx_too_long: 0
      rx_fifo_overflow: 0
      rx_jabber: 0
      rx_fcs_error: 0
      tx_64_byte_packets: 45
      tx_65_to_127_byte_packets: 1074
      tx_128_to_255_byte_packets: 0
      tx_256_to_511_byte_packets: 52
      tx_512_to_1023_byte_packets: 0
      tx_1024_to_1518_byte_packets: 0
      tx_1519_to_max_byte_packets: 0
      tx_fifo_underrun: 0

> And if you enable the debugfs option there is more info
> hidden there.
>
> # mount -t debugfs debugfs /sys/kernel/debug
> # cat /sys/kernel/debug/sky2/eth0

There is no sky2 directory, maybe I don't have enough debug options in 
my kernel config.

Niccolò

Re: sky2 still badly broken

[Niccolò Belli]

Il 03/05/2012 17:23, Stephen Hemminger ha scritto:
> The receiver on some versions of the chip can't keep up with full speed
> of 1G bit/sec. The receive  FIFO has hardware issues, and since I don't
> work for Marvell, working around the problem is guesswork.

Just one question: if that is true why don't I have any problem with a 
point to point gigabit link? I did transfer 3GB from ram to ram (ramfs) 
at 100+MB/s without any issue in a point to point setup, as soon as I 
attach it to the switch I have problems (very low transfer rate and tons 
of rx errors).

Niccolò

Re: sky2 still badly broken

[Stephen Hemminger]

On Thu, 03 May 2012 21:36:50 +0200
Niccolò Belli <darkbasic@linuxsystems.it> wrote:

> Il 03/05/2012 17:23, Stephen Hemminger ha scritto:
> > The receiver on some versions of the chip can't keep up with full speed
> > of 1G bit/sec. The receive  FIFO has hardware issues, and since I don't
> > work for Marvell, working around the problem is guesswork.
> 
> Just one question: if that is true why don't I have any problem with a 
> point to point gigabit link? I did transfer 3GB from ram to ram (ramfs) 
> at 100+MB/s without any issue in a point to point setup, as soon as I 
> attach it to the switch I have problems (very low transfer rate and tons 
> of rx errors).

I don't know but the PHY interaction is different with auto-crossover.

Re: [RFT] sky2: fix status length check on older chips

[Ivan Minev]

Still vlan don't work and have rx lenght errors chipset:88E8072 rev 10