Re: More on rl0 woes
> > 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. Weeelll... I'm a cheap bastard & I actually expected it to work - not real fast, but work reliably anyway. I'm trying to convert my home network over to 100Mbs and the box this is going into is not a performance monster. > 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? I'll check that tonight. > You say 'traffic continues > normally.' This is very confusing: SHOW ME AN EXAMPLE OF WHAT YOU MEAN. OK - the "ls" of the directory remains hung, but I can still ping the box. It's as if NFS reckons it's sent the reply to the READDIR packet, but it never actually made its way out of the card. > 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? I ran tcpdump on the server and observed READDIR packets being received, but no response being emitted. > 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? I'll try this when I get home. Don't know enough about the contents of NFS packets yet to tell if it's garbled. > > 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. Orright.. Just give me a little time. Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: More on rl0 woes
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.raa26...@ariadne.tensor.pgs.com>, > > `shock...@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: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@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 majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: More on rl0 woes
On 4 Apr 1999, Murata Shuuichirou wrote: > In message <199904040913.raa26...@ariadne.tensor.pgs.com>, > `shock...@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. > > To reproduce: > Install bytebench on the RealTek machine. > Set env var TMPDIR to somewhere NFS mounted dir. > Do "bytebench fstime". I have a solution and a workaround for you guys, solution: ditch the cheap PoS cards and get an fxp or xl card workaround: switch from UDP to TCP mounts or TCP to UDP, make sure the packet size used for the NFS mounts is a small value, try NFSv3, or if you are already using NFSv3, try NFSv2. Yes, the workaround seems like "just try several permutations", but I experianced the same problems, tweaking my NFS mounts, especially to use smaller read/write values made the problem go away. I think that switching to TCP may help. When i got some decent network hardware, my problems went away. -Alfred > > -- > Murata Shuuichirou > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Alfred Perlstein - Admin, coder, and admirer of all things BSD. -- There are operating systems, and then there's FreeBSD. -- http://www.freebsd.org/4.0-current To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: More on rl0 woes
> > 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 > > 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. > > To reproduce: > Install bytebench on the RealTek machine. > Set env var TMPDIR to somewhere NFS mounted dir. > Do "bytebench fstime". heh... i guess I too have similar problems. Though, I've always assumed it was nfs, not the network card. 3coms in the server, realteks in the clients. I've found that inbound traffic on a read-only mount doesn't hang anything. Heavy writes kill me all the time. (Make world for example). To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: More on rl0 woes
In message <199904040913.raa26...@ariadne.tensor.pgs.com>, `shock...@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. To reproduce: Install bytebench on the RealTek machine. Set env var TMPDIR to somewhere NFS mounted dir. Do "bytebench fstime". -- Murata Shuuichirou To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
More on rl0 woes
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. Stephen .e w. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
