Date: Fri, 08 Mar 2002 12:36:31 -0500 From: The Anarcat <anarcat@anarcat.dyndns.org> To: Mike Silbersack <silby@silby.com> Cc: silby@FreeBSD.org, freebsd-bugs@FreeBSD.org, danny@clari.net.au Subject: Re: kern/35640: heavy collision rate hangs vr network interface Message-ID: <3C88F69F.3050608@anarcat.dyndns.org> References: <20020308003224.T3443-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel O'Callaghan added to CC: I'll answer both questions in the same email, since there's been information mispread. :) Mike Silbersack wrote: >On Thu, 7 Mar 2002, The Anarcat wrote: > >>>Of course, that doesn't explain the vr system locking up, but it >>>may be a good enough solution for you. >>> >>It's not fixing the problem. The collision rate is unchanged. >> >>Something I don't understand though... The collision rate isn't the same >>on the client and on the server... >> >>client: >> >> input (Total) output >> packets errs bytes packets errs bytes colls >> 467 0 30822 691 0 1061314 709 >> >>server: >> input (Total) output >> packets errs bytes packets errs bytes colls >> 711 0 1073558 512 0 31396 439 >> >> >> >>At any rate, this PR should be put back in the Open state, no? >> >>A. >> > >Ok, I moved the PR back to open > Good. >Have you investigated playing around with the duplex settings on the vr >interface? > I did, I think. But I will again test some more a bit later. The thing is I don't think is full-duplex anywhere. >Perhaps it has the same problem the rl driver had? > Possible, but the rl problem doesn't seem to be solved either. I'm not even sure the problem is due to the rl.. >Could you try hooking up the two machines with a crossover cable or a >100mbps hub to see if anything changes? > I did try to hook up the 2 machines with a crossover, with the same results. I never tried to push to connection to 100mbps, though. I guest I have some more tests to run. The problem is that this is now a production machine, so I am hesitant of pulling it off the network. Daniel O'Callaghan wrote: >>Same results before and after patching. The higher collision rate is due >>to the fact that the mesures are not the same on the server and the >>client (why?): >> >I thought collisions were detected by the transmitting end. Have you >tried a different hub? > No. I have no other hub to test with. The reports I first made were done with mesures taken on the server side. For some reason, the collision rate is not the same on the client side, it is higher there, which might indicate the source of the problem is the rl... >Hmm, strange. I don't think I saw anything like that here. I'll have to fire up an rl machine and check it out, though. > >The patch fixes the autosense operation in 10 Mbps. The workaround prior to patching was to manually set the media to UTP. > I figured that part before the patch already. When I connected the interface to the network the first time, autonegotiation was broken so I had to manually set media to UTP. The patch of course didn't change anything wrt that. :) I will test autonegotiation asap, though. > Obviously there is something different about your setup which is causing the collisions. >I'm not really a device driver guru. I just tested a patch which someone else submitted. I'll set up a test box and look at the collision rate, though. > I will try to pull the machine off the network (sigh) for a while and test: - crosslink connection at 10 and 100mbps - autosense on both ends Past this point, if behavior is the same, I'm ready to break into debugging on the vr interface. It should be easier than the rl since we have a mark when the interface stops working properly, the "watchdog timeout" message. A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C88F69F.3050608>