Date: Fri, 29 Jan 1999 18:28:46 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: chris@netmonger.net (Christopher Masto) Cc: fenner@parc.xerox.com, current@FreeBSD.ORG, hardware@FreeBSD.ORG Subject: Re: Network/ARP problem? Maybe pn driver? Message-ID: <199901292328.SAA26781@skynet.ctr.columbia.edu> In-Reply-To: <19990129180612.C3237@netmonger.net> from "Christopher Masto" at Jan 29, 99 06:06:12 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901292328.SAA26781>