From owner-freebsd-hardware Fri Jan 29 15:22:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29514 for freebsd-hardware-outgoing; Fri, 29 Jan 1999 15:22:20 -0800 (PST) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id PAA29505; Fri, 29 Jan 1999 15:22:15 -0800 (PST) (envelope-from wpaul@skynet.ctr.columbia.edu) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id SAA26781; Fri, 29 Jan 1999 18:28:47 -0500 From: Bill Paul Message-Id: <199901292328.SAA26781@skynet.ctr.columbia.edu> Subject: Re: Network/ARP problem? Maybe pn driver? To: chris@netmonger.net (Christopher Masto) Date: Fri, 29 Jan 1999 18:28:46 -0500 (EST) Cc: fenner@parc.xerox.com, current@FreeBSD.ORG, hardware@FreeBSD.ORG In-Reply-To: <19990129180612.C3237@netmonger.net> from "Christopher Masto" at Jan 29, 99 06:06:12 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Of all the gin joints in all the towns in all the world, Christopher Masto had to walk into mine and say: > On Fri, Jan 29, 1999 at 02:52:07PM -0800, Bill Fenner wrote: > > Can you run a "tcpdump arp" on the machine that is having the problem, > > as well? This could help to determine if it's a driver problem (e.g. > > if the replies don't show up) or an ARP problem (e.g. if the replies > > do show up but arp doesn't use them). > > Good idea. > > Hmm. Running tcpdump seems to make the problem go away. The ARP > replies show up immediately appear in the table. Clue. You should have tried that first. There's something I'd like you to try for me. (Don't delay in trying this; I've had a long string of people who appear suddenly, complain about a problem of some sort, then vanish before I can extract enough information from them to find a solution.) I was menaced by a bug in the PNIC's receive DMA operation which, according to all my tests, only appeared in promiscuous mode. I devised a workaround, however it's only enabled when the IFF_PROMISC flag is set on the interface. Running tcpdump (without the -p flag) places the interface in promiscuous mode and enables the workaround. Given what you've said, it's possible that we need to enable the workaround all the time, not just in promiscuous mode. Do me the following: - Bring up /sys/pci/if_pn.c in your favorite editor. - Locate the pn_rxeof() function and find the following code: #ifdef PN_PROMISC_BUG_WAR /* * XXX The PNIC seems to have a bug that manifests * when the promiscuous mode bit is set: we have to * watch for it and work around it. */ if (sc->pn_promisc_war && ifp->if_flags & IFF_PROMISC) { [...] - Change the if() clause so that it looks like this: if (sc->pn_promisc_war /*&& ifp->if_flags & IFF_PROMISC*/) { (In other words, comment out the test for the IFF_PROMISC flag.) This will enable the workaround all the time and allow the receiver bug to be detected and handled properly. Compile a new kernel with this change and see if the problem persists. Report back your findings (one way or the other) so that I'll know if I should modify the code in the repository. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message