sky2 still badly broken

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ò

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 <[email protected]>

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.

@@ -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);

@@ -2242,6 +2242,7 @@ struct sky2_port {
 	u16		     rx_data_size;
 	u16		     rx_nfrags;
 	u16		     rx_tag;
+	u8		     rx_vlan;
 
 	struct {
 		unsigned long last;

From: Stephen Hemminger <[email protected]>
Date: Fri, 27 Apr 2012 13:41:27 -0700

Nothing sets ->rx_vlan in that patch.

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 <[email protected]>

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.

---

@@ -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:

@@ -2242,6 +2242,7 @@ struct sky2_port {
 	u16		     rx_data_size;
 	u16		     rx_nfrags;
 	u16		     rx_tag;
+	u8		     rx_vlan;
 
 	struct {
 		unsigned long last;

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ò

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

Il 28/04/2012 04:46, Stephen Hemminger ha scritto:

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

Niccolò

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

Il 30/04/2012 18:19, Stephen Hemminger ha scritto:

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

Niccolò

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.

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

@@ -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))

@@ -2241,7 +2241,6 @@ struct sky2_port {
 	u16		     rx_pending;
 	u16		     rx_data_size;
 	u16		     rx_nfrags;
-	u16		     rx_tag;
 
 	struct {
 		unsigned long last;

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

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

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.

Il 30/04/2012 21:25, Stephen Hemminger ha scritto:

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

Niccolò

Il 30/04/2012 21:25, Stephen Hemminger ha scritto:

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.

Il 02/05/2012 20:56, Stephen Hemminger ha scritto:

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.

Il 03/05/2012 17:23, Stephen Hemminger ha scritto:

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

Il 03/05/2012 20:15, Stephen Hemminger ha scritto:

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

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

Niccolò

Il 03/05/2012 17:23, Stephen Hemminger ha scritto:

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ò

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