Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 10 Aug 2002 22:34:40 -0400
From:      Mike Tancsa <mike@sentex.net>
To:        Ian Dowse <iedowse@maths.tcd.ie>
Cc:        stable@FreeBSD.ORG, luigi@FreeBSD.ORG
Subject:   Re: fxp problems with latest stable Re: panics after upgrading to -STABLE Aug 9, 2002 (still something up) 
Message-ID:  <5.1.0.14.0.20020810221634.0150a6d8@192.168.0.12>
In-Reply-To: <200208110304.aa47521@salmon.maths.tcd.ie>
References:  <Your message of "Sat, 10 Aug 2002 21:18:57 EDT." <5.1.0.14.0.20020810210400.0622d770@192.168.0.12>

next in thread | previous in thread | raw e-mail | index | archive | help

Thanks for the patch Ian!   One more bit of info, the problem seems to be 
in one direction.  e.g.

 From an OLD machine to a machine with the new driver
ping -i .1 192.168.43.91
PING 192.168.43.91 (192.168.43.91): 56 data bytes
64 bytes from 192.168.43.91: icmp_seq=33 ttl=64 time=0.140 ms
64 bytes from 192.168.43.91: icmp_seq=60 ttl=64 time=0.141 ms
64 bytes from 192.168.43.91: icmp_seq=100 ttl=64 time=0.148 ms
64 bytes from 192.168.43.91: icmp_seq=129 ttl=64 time=0.138 ms
^C
--- 192.168.43.91 ping statistics ---
135 packets transmitted, 4 packets received, 97% packet loss
round-trip min/avg/max/stddev = 0.138/0.142/0.148/0.004 ms
pyroxene#

But from the machine with the new possibly buggy driver to a machine with 
the old driver

--- 192.168.43.1 ping statistics ---
246 packets transmitted, 246 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.118/0.132/0.245/0.014 ms


In case it was something simple like the committer only testing with 
DEVICE_POLLING, I enabled it in the kernel, but the same results.


Anyways, with the patch I am still seeing the same problem :-(

         ---Mike




At 03:04 AM 8/11/2002 +0100, Ian Dowse wrote:
>In message <5.1.0.14.0.20020810210400.0622d770@192.168.0.12>, Mike Tancsa 
>write
>s:
> >I did some more tests with the new driver with 2 machines on a totally
> >different segment and the same sorts of packet loss on simple pings.  If I
> >revert to the previous version, no packet loss at all.
>
>Hi Mike,
>
>thanks for tracking down the commit that caused this. I had a quick
>look at the changes in that revision, and although there were no
>obvious problems I could see, a few things stood out as possible
>candidates:
>
>The FXP_RFA_RNRMARK flag: Luigi, do you have hardware documentation
>for the Intel etherexpress chips that explicitly says that this bit
>is free for use by the device driver? If not, this would be my first
>guess at the problem. A patch that just #if 0's out this code
>(breaking the DEVICE_POLLING case) is below. It would be very useful
>to know if this makes a difference.
>
>Total packet size: the old code used rfa->actual_size & (MCLBYTES - 1)
>and the new version uses a mask of 0x3fff. I assume this is correct,
>but to test if it is the problem, change the 0x3fff to 0x1fff.
>
>Ian
>
>Index: if_fxp.c
>===================================================================
>RCS file: /home/iedowse/CVS/src/sys/dev/fxp/if_fxp.c,v
>retrieving revision 1.110.2.24
>diff -u -r1.110.2.24 if_fxp.c
>--- if_fxp.c    9 Aug 2002 02:04:20 -0000       1.110.2.24
>+++ if_fxp.c    11 Aug 2002 01:46:23 -0000
>@@ -1292,7 +1292,9 @@
>         * info will be used in the subsequent polling cycle.
>         */
>
>+#if 0
>  #define        FXP_RFA_RNRMARK         0x4000  /* used to mark a pending 
> RNR intr */
>+#endif
>
>         for (;;) {
>                 m = sc->rfa_headm;
>@@ -1307,8 +1309,10 @@
>                 if ( (rfa->rfa_status & FXP_RFA_STATUS_C) == 0)
>                         break;
>
>+#if 0
>                 if (rfa->rfa_status & FXP_RFA_RNRMARK)
>                         rnr = 1;
>+#endif
>                 /*
>                 * Remove first packet from the chain.
>                 */
>@@ -1342,15 +1346,19 @@
>                 }
>         }
>         if (rnr) {
>+#if 0
>                 if (rfa->rfa_status & FXP_RFA_STATUS_C)
>                         rfa->rfa_status |= FXP_RFA_RNRMARK;
>                 else {
>+#endif
>                         fxp_scb_wait(sc);
>                         CSR_WRITE_4(sc, FXP_CSR_SCB_GENERAL,
>                             vtophys(sc->rfa_headm->m_ext.ext_buf) +
>                                 RFA_ALIGNMENT_FUDGE);
>                         fxp_scb_cmd(sc, FXP_SCB_COMMAND_RU_START);
>+#if 0
>                 }
>+#endif
>         }
>  }
>
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with "unsubscribe freebsd-stable" in the body of the message

--------------------------------------------------------------------
Mike Tancsa,                          	          tel +1 519 651 3400
Sentex Communications,     			  mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada			  www.sentex.net/mike


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.0.20020810221634.0150a6d8>