From owner-freebsd-stable Sat Aug 10 19:34:44 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B69E537B400; Sat, 10 Aug 2002 19:34:38 -0700 (PDT) Received: from cage.simianscience.com (cage.simianscience.com [64.7.134.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B99C343E6A; Sat, 10 Aug 2002 19:34:37 -0700 (PDT) (envelope-from mike@sentex.net) Received: from house.sentex.net (fcage [192.168.0.2]) by cage.simianscience.com (8.12.5/8.12.5) with ESMTP id g7B2YX6A060900; Sat, 10 Aug 2002 22:34:34 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <5.1.0.14.0.20020810221634.0150a6d8@192.168.0.12> X-Sender: mdtancsa@192.168.0.12 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 10 Aug 2002 22:34:40 -0400 To: Ian Dowse From: Mike Tancsa Subject: Re: fxp problems with latest stable Re: panics after upgrading to -STABLE Aug 9, 2002 (still something up) Cc: stable@FreeBSD.ORG, luigi@FreeBSD.ORG In-Reply-To: <200208110304.aa47521@salmon.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: amavis-20020220 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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