Date: Sun, 4 Apr 1999 16:02:29 -0400 (EDT) From: wpaul@ctr.columbia.edu (Bill Paul) To: bright@rush.net (Alfred Perlstein) Cc: mrt@notwork.org, shocking@prth.pgs.com, current@freebsd.org Subject: Re: More on rl0 woes Message-ID: <199904042002.QAA14549@sirius.ctr.columbia.edu> In-Reply-To: <Pine.BSF.3.96.990404113125.4169W-100000@cygnus.rush.net> from "Alfred Perlstein" at Apr 4, 99 11:36:36 am
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, Alfred Perlstein had to walk into mine and say: > On 4 Apr 1999, Murata Shuuichirou wrote: > > > In message <199904040913.RAA26683@ariadne.tensor.pgs.com>, > > `shocking@prth.pgs.com' wrote: > > > On the offchance that mty problems were chipset related, I swapped the > > > RealTek with the de0 card in my other machine, a 233MHz k6. It being a > > > socket 7 mboard presumably has a later PCI bios. Still the same symptoms - > > > hangs on NFS access. These can be interrupted and other network traffic > > > continues fine. To reproduce, take your RealTek equipped machine and place a > > > copy of /usr/src on it. Export /usr/src so that it can be NFS mounted by > > > other machines. From the other machines, do an ls -CFR of /usr/src. It will > > > hang partway through. > > > > I have probably same problem here. NFS hangs and other > > network traffic is still alive. Though, my situation > > differs a little from yours. I have two RealTek NFS clients > > and NFS server has another chip. Both of RealTek NFS clients > > (Celeron 300MHz and MediaGX 266MHz) have the problem. Wait wait wait! You're claiming you have the same problem your configurations are different! He's saying he has a problem when the RealTek card is in the server, and the client is using some other NIC. You're saying you have a problem when the RealTek in the client, and the server is using some other NIC. These are completely different scenarios! I will not allow a bunch of you to all jump on me at the same time claiming you've all got the same problem when you CLEARLY DON'T! EVERYBODY PAY ATTENTION TO WHAT THE OTHER IS SAYING AND WAIT YOUR DAMN TURN OR I'M JUST GOING TO IGNORE THE WHOLE LOT OF YOU AND YOU CAN FIX YOUR OWN DAMN PROBLEMS! I can't believe I'm getting so worked up because you cheap bastards insist on buying the absolute worst network adapter in the world. Go buy an ASIX card for crying out loud. They're cheap, and they actually work worth a damn. Now, as punishment for making me mad, I'm going to address Steven's problem, and the rest of you can just lump it. There are things you should be checking when your problem happens. What does ifconfig rl0 show you? Is the OACTIVE flag set? What does netstat -in say? What does netstat -m say? You say 'traffic continues normally.' This is very confusing: SHOW ME AN EXAMPLE OF WHAT YOU MEAN. When the NFS transfer stops, can you still ping the server host, or do you have to interrupt the transfer and wait for a while before you can communicate with the server again? Can you run tcpdump on the client and observe what happens when the transfer stops? Is the client still sending out read requests? Is the server replying or not? Are the replies garbled? Is there a lot of other activity on the network at the time? Can you initiate another (smaller) NFS transfer when the first one wedges? You have to give me as much information as you can. I need to be able to clearly identify the symptoms of the problem with out all the 'oh my god it doesn't work and I tried this and this and this' crap. -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 ============================================================================= "Mulder, toads just fell from the sky!" "I guess their parachutes didn't open." ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904042002.QAA14549>