Re: cpsw device timeouts
A 3rd check against a self compiled kernel based on the latest anoncvs tree without any patches shows the same behaviour as described below. # i=219 # while [ $i -le 226 ];do > ping -f -n -c100 -s$i 192.168.7.1 > i=$(( $i + 1 )) > done PING 192.168.7.1 (192.168.7.1): 219 data bytes --- 192.168.7.1 ping statistics --- 101 packets transmitted, 100 packets received, 1.0% packet loss round-trip min/avg/max/std-dev = 2.106/5.609/18.494/2.818 ms PING 192.168.7.1 (192.168.7.1): 220 data bytes --- 192.168.7.1 ping statistics --- 101 packets transmitted, 100 packets received, 1.0% packet loss round-trip min/avg/max/std-dev = 2.076/8.117/17.884/3.961 ms PING 192.168.7.1 (192.168.7.1): 221 data bytes --- 192.168.7.1 ping statistics ---..^C 69 packets transmitted, 0 packets received, 100.0% packet loss PING 192.168.7.1 (192.168.7.1): 222 data bytes --- 192.168.7.1 ping statistics --- 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 2.075/5.448/9.705/1.633 ms PING 192.168.7.1 (192.168.7.1): 223 data bytes --- 192.168.7.1 ping statistics --- 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 4.089/5.867/8.911/0.821 ms PING 192.168.7.1 (192.168.7.1): 224 data bytes --- 192.168.7.1 ping statistics --- 100 packets transmitted, 100 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 2.075/5.684/7.629/1.196 ms PING 192.168.7.1 (192.168.7.1): 225 data bytes --- 192.168.7.1 ping statistics --- 101 packets transmitted, 100 packets received, 1.0% packet loss round-trip min/avg/max/std-dev = 2.075/10.302/17.548/5.581 ms PING 192.168.7.1 (192.168.7.1): 226 data bytes --- 192.168.7.1 ping statistics --- 101 packets transmitted, 100 packets received, 1.0% packet loss round-trip min/avg/max/std-dev = 2.075/5.893/17.578/3.663 ms dmesg OpenBSD 5.5-current (GENERIC-OMAP) #0: Wed Apr 16 21:56:28 CEST 2014 r...@bbb1.hexa.homeunix.net:/usr/src/sys/arch/armv7/compile/GENERIC-OMAP real mem = 536870912 (512MB) avail mem = 518746112 (494MB) warning: no entropy supplied by boot loader mainbus0 at root cpu0 at mainbus0: ARM Cortex A8 R3 rev 2 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(64b/l,4way) I-cache, 32KB(64b/l,4way) wr-back D-cache omap0 at mainbus0: BeagleBone prcm0 at omap0 rev 0.2 sitaracm0 at omap0: control module, rev 1.0 intc0 at omap0 rev 5.0 edma0 at omap0 rev 0.0 dmtimer0 at omap0 rev 3.1 dmtimer1 at omap0 rev 3.1 omdog0 at omap0 rev 0.1 omgpio0 at omap0: rev 0.1 gpio0 at omgpio0: 32 pins omgpio1 at omap0: rev 0.1 gpio1 at omgpio1: 32 pins omgpio2 at omap0: rev 0.1 gpio2 at omgpio2: 32 pins omgpio3 at omap0: rev 0.1 gpio3 at omgpio3: 32 pins omap0: device tiiic unit 0 not configured omap0: device tiiic unit 1 not configured omap0: device tiiic unit 2 not configured ommmc0 at omap0 sdmmc0 at ommmc0 ommmc1 at omap0 sdmmc1 at ommmc1 com0 at omap0: ti16750, 64 byte fifo com0: console cpsw0 at omap0: version 1.12 (0), address 90:59:af:58:ce:17 ukphy0 at cpsw0 phy 0: Generic IEEE 802.3u media interface, rev. 1: OUI 0x0001f0, model 0x000f scsibus0 at sdmmc0: 2 targets, initiator 0 sd0 at scsibus0 targ 1 lun 0: SCSI2 0/direct fixed sd0: 7384MB, 512 bytes/sector, 15122432 sectors scsibus1 at sdmmc1: 2 targets, initiator 0 sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct fixed sd1: 1832MB, 512 bytes/sector, 3751936 sectors vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets boot device: sd0 root on sd0a (6a8ab8283a822f44.a) swap on sd0b dump on sd0b - Ben On 04/16/14 20:49, Benjamin Baier wrote: I patched this against (1st) the latest anoncvs tree and (2nd) against your cpsw patch from 04/12/14 (2). Both times it works (compile, boot) and so I tested the timeout bug described at http://marc.info/?l=openbsd-bugs&m=138275913126582&w=2 First i can reproduce the timeout bug with the latest snapshot kernel OpenBSD 5.5 (GENERIC-OMAP) #11: Sat Mar 8 12:52:57 EST 2014 With the patched kernels (1) and (2) the timeout shiftet. # ping -f -n -c100 -s289 runs with 0% packet loss # ping -f -n -c100 -s225 runs with 0% packet loss # ping -f -n -c100 -s221 runs with complete packet loss (100%), sometimes I get 1 return packet. All others -s1 up to -s1000 come back mixed, with 1/3rd coming back with max. 1 lost packet and 2/3rd coming back with 0% packet loss. - Ben On 04/14/14 20:18, Brandon Mercer wrote: whoops, small typo in the previous diff: cvs diff: Diffing sys/arch/armv7/omap/ Index: sys/arch/armv7/omap//if_cpsw.c === RCS file: /cvs/src/sys/arch/armv7/omap/if_cpsw.c,v retrieving revision 1.21 diff -u -p -u -r1.21 if_cpsw.c --- sys/arch/armv7/omap//if_cpsw.c 26 Nov 2013 20:33:11 - 1.21 +++ sys/arch/armv7/omap//if_cpsw.c 14 Apr 2014 17:37:27 - @@ -816,6 +816,8 @@ cpsw_init(struct ifnet *ifp) cpsw_write_
Re: cpsw device timeouts
I patched this against (1st) the latest anoncvs tree and (2nd) against your
cpsw patch from 04/12/14 (2).
Both times it works (compile, boot) and so I tested the timeout bug
described at
http://marc.info/?l=openbsd-bugs&m=138275913126582&w=2
First i can reproduce the timeout bug with the latest snapshot kernel
OpenBSD 5.5 (GENERIC-OMAP) #11: Sat Mar 8 12:52:57 EST 2014
With the patched kernels (1) and (2) the timeout shiftet.
# ping -f -n -c100 -s289
runs with 0% packet loss
# ping -f -n -c100 -s225
runs with 0% packet loss
# ping -f -n -c100 -s221
runs with complete packet loss (100%), sometimes I get 1 return packet.
All others -s1 up to -s1000 come back mixed, with 1/3rd coming back with
max. 1 lost packet and 2/3rd coming back with 0% packet loss.
- Ben
On 04/14/14 20:18, Brandon Mercer wrote:
whoops, small typo in the previous diff:
cvs diff: Diffing sys/arch/armv7/omap/
Index: sys/arch/armv7/omap//if_cpsw.c
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpsw.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 if_cpsw.c
--- sys/arch/armv7/omap//if_cpsw.c 26 Nov 2013 20:33:11 -
1.21
+++ sys/arch/armv7/omap//if_cpsw.c 14 Apr 2014 17:37:27 -
@@ -816,6 +816,8 @@ cpsw_init(struct ifnet *ifp)
cpsw_write_4(sc, CPSW_CPDMA_SOFT_RESET, 1);
while(cpsw_read_4(sc, CPSW_CPDMA_SOFT_RESET) & 1);
+
+ cpsw_write_4(sc, CPSW_SS_FLOW_CONTROL, 0);
for (i = 0; i < 8; i++) {
cpsw_write_4(sc, CPSW_CPDMA_TX_HDP(i), 0);
Index: sys/arch/armv7/omap//if_cpswreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpswreg.h,v
retrieving revision 1.5
diff -u -p -u -r1.5 if_cpswreg.h
--- sys/arch/armv7/omap//if_cpswreg.h 15 Nov 2013 14:31:52 -
1.5
+++ sys/arch/armv7/omap//if_cpswreg.h 14 Apr 2014 18:08:52 -
@@ -39,6 +39,7 @@
#define CPSW_SS_SOFT_RESET (CPSW_SS_OFFSET + 0x08)
#define CPSW_SS_STAT_PORT_EN (CPSW_SS_OFFSET + 0x0C)
#define CPSW_SS_PTYPE (CPSW_SS_OFFSET + 0x10)
+#define CPSW_SS_FLOW_CONTROL (CPSW_SS_OFFSET + 0x24)
#define CPSW_PORT_OFFSET 0x0100
#define CPSW_PORT_P_TX_PRI_MAP(p) (CPSW_PORT_OFFSET + 0x118 +
((p-1) * 0x100))
Re: cpsw device timeouts
whoops, small typo in the previous diff:
cvs diff: Diffing sys/arch/armv7/omap/
Index: sys/arch/armv7/omap//if_cpsw.c
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpsw.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 if_cpsw.c
--- sys/arch/armv7/omap//if_cpsw.c 26 Nov 2013 20:33:11 -
1.21
+++ sys/arch/armv7/omap//if_cpsw.c 14 Apr 2014 17:37:27 -
@@ -816,6 +816,8 @@ cpsw_init(struct ifnet *ifp)
cpsw_write_4(sc, CPSW_CPDMA_SOFT_RESET, 1);
while(cpsw_read_4(sc, CPSW_CPDMA_SOFT_RESET) & 1);
+
+ cpsw_write_4(sc, CPSW_SS_FLOW_CONTROL, 0);
for (i = 0; i < 8; i++) {
cpsw_write_4(sc, CPSW_CPDMA_TX_HDP(i), 0);
Index: sys/arch/armv7/omap//if_cpswreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpswreg.h,v
retrieving revision 1.5
diff -u -p -u -r1.5 if_cpswreg.h
--- sys/arch/armv7/omap//if_cpswreg.h 15 Nov 2013 14:31:52 -
1.5
+++ sys/arch/armv7/omap//if_cpswreg.h 14 Apr 2014 18:08:52 -
@@ -39,6 +39,7 @@
#define CPSW_SS_SOFT_RESET (CPSW_SS_OFFSET + 0x08)
#define CPSW_SS_STAT_PORT_EN (CPSW_SS_OFFSET + 0x0C)
#define CPSW_SS_PTYPE (CPSW_SS_OFFSET + 0x10)
+#define CPSW_SS_FLOW_CONTROL (CPSW_SS_OFFSET + 0x24)
#define CPSW_PORT_OFFSET 0x0100
#define CPSW_PORT_P_TX_PRI_MAP(p) (CPSW_PORT_OFFSET + 0x118 +
((p-1) * 0x100))
cpsw device timeouts
I've been trying to track down what's causing the cpsw device timeouts on the
beaglebone and beaglebone black. As best I can tell disabling hardware
flow control does the trick. If you're able to recreate that issue
please test this diff and report your findings. Thanks.
cvs diff: Diffing sys/arch/armv7/omap/
Index: sys/arch/armv7/omap//if_cpsw.c
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpsw.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 if_cpsw.c
--- sys/arch/armv7/omap//if_cpsw.c 26 Nov 2013 20:33:11 -
1.21
+++ sys/arch/armv7/omap//if_cpsw.c 14 Apr 2014 17:37:27 -
@@ -816,6 +816,8 @@ cpsw_init(struct ifnet *ifp)
cpsw_write_4(sc, CPSW_CPDMA_SOFT_RESET, 1);
while(cpsw_read_4(sc, CPSW_CPDMA_SOFT_RESET) & 1);
+
+ cpsw_write_4(sc, CPSW_SS_FLOW_CONTROL, 0);
for (i = 0; i < 8; i++) {
cpsw_write_4(sc, CPSW_CPDMA_TX_HDP(i), 0);
Index: sys/arch/armv7/omap//if_cpswreg.h
===
RCS file: /cvs/src/sys/arch/armv7/omap/if_cpswreg.h,v
retrieving revision 1.5
diff -u -p -u -r1.5 if_cpswreg.h
--- sys/arch/armv7/omap//if_cpswreg.h 15 Nov 2013 14:31:52 -
1.5
+++ sys/arch/armv7/omap//if_cpswreg.h 14 Apr 2014 17:37:12 -
@@ -39,6 +39,7 @@
#define CPSW_SS_SOFT_RESET (CPSW_SS_OFFSET + 0x08)
#define CPSW_SS_STAT_PORT_EN (CPSW_SS_OFFSET + 0x0C)
#define CPSW_SS_PTYPE (CPSW_SS_OFFSET + 0x10)
+#define CPSW_SS_FLOW_CONTROl (CPSW_SS_OFFSET + 0x24)
#define CPSW_PORT_OFFSET 0x0100
#define CPSW_PORT_P_TX_PRI_MAP(p) (CPSW_PORT_OFFSET + 0x118 +
((p-1) * 0x100))
