From owner-freebsd-current@FreeBSD.ORG Sat Jun 19 20:14:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D721316A4CE for ; Sat, 19 Jun 2004 20:14:11 +0000 (GMT) Received: from bsd.ee (bsd.ee [194.126.101.115]) by mx1.FreeBSD.org (Postfix) with SMTP id 13B1043D2F for ; Sat, 19 Jun 2004 20:14:11 +0000 (GMT) (envelope-from hadara@bsd.ee) Received: (qmail 35479 invoked by uid 1021); 19 Jun 2004 20:14:18 -0000 Received: from hadara@bsd.ee by daemon.bsd.ee by uid 82 with qmail-scanner-1.20 (spamassassin: 2.55. Clear:RC:1(62.65.205.81):. Processed in 0.054147 secs); 19 Jun 2004 20:14:18 -0000 Received: from unknown (HELO depression) (62.65.205.81) by bsd.ee with SMTP; 19 Jun 2004 20:14:17 -0000 From: Sven Petai Organization: NPO BSD Estonia To: wpaul@FreeBSD.ORG (Bill Paul), braukmann@tse-online.de (Andreas Braukmann) Date: Sat, 19 Jun 2004 23:11:46 +0300 User-Agent: KMail/1.5.4 References: <20040618173204.3DE7816A4D2@hub.freebsd.org> In-Reply-To: <20040618173204.3DE7816A4D2@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200406192311.47535.hadara@bsd.ee> cc: freebsd-current@freebsd.org Subject: Re: Realtek RT8139 (onboard) - failed to receive packet in loopback mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jun 2004 20:14:12 -0000 On Friday 18 June 2004 20:32, Bill Paul wrote: > > On 06/18/04 01:51:17 +0000 Bill Paul wrote: > > > Please try the code located at: > > > > > > http://www.freebsd.org/~wpaul/re > > > > thanks. The patched if_re.c doesn't compile. You added a > > member rl_link to the struct rl_softc in pci/if_rlreg.h, > > didn't you? > > > > I'd appreciate getting the appropriate patch for if_rlreg.h. > > Heh. You were able to trivally patch if_re.c but not if_rlreg.h? :) > > I uploaded a new copy and diff of if_rlreg.h to the same URL. Please > try again. Even though I didn't have the problem that this thread is about, I decided to try the patch anyway since I have 8139C+ too. The patched version of re seems to be broken in some strange ways... first I noticed that even though the re0 was recognized the boot hanged for a very long time when starting up dhclient and evevntually it wasn't able to get address.. so I gave it address by hand, it worked but network was unusable... pinging my gateway seems to delay packets until it has ~5-10 of them and then send it in one burst - output of ping & ifconfig is available @ http://bsd.ee/~hadara/debug/re/ping.txt pciconf -lv: http://bsd.ee/~hadara/debug/re/pciconf.txt boot -v: http://bsd.ee/~hadara/debug/re/bootv.txt kernel config: http://bsd.ee/~hadara/debug/re/IKALDUS btw. are you aware of the re's timeout problems other re users have complained about for a long time ? for example threads like: http://groups.google.com/groups?q=freebsd+watchdog+timeout +re0&hl=en&lr=&ie=UTF-8&safe=off&selm=brimcd%241nfh%241% 40FreeBSD.csie.NCTU.edu.tw&rnum=1 http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=477380+479767+/usr/local/www/db/ text/2004/freebsd-current/20040516.freebsd-current basically re gets watchdog timeouts every now and then, but it seems to be dependant on many factors... it's usually easily reproducible with cvsup - in most cases I get first timeouts within a minute, but it depends on a link speed to cvsup server, at home where I have about 1Mbit/s link to server I can reproduce timeouts far faster than I can at work where I have ~50Mbit/s link to the server. Having some CPU load seems to help too, so I would suggest using 2 cvsup files with different cvsup dates and doing something like while 1 cvsup cvsupfile1 cvsup cvsupfile2 end and while 1 make buildkernel end in the other window. Strangely I haven't been able to reproduce timeouts with any other kind of network load, so cvsup must be doing something special. I got around it on my box by setting watchdog timer to 5 in txeof() before rescheduling another interrupt, and it has worked without any problems since then, but this is of course only a workaround not a real fix, since it effectivelly disables watchdog timer alltogether. I also tried setting the timer to 5 in txeof() only when some work has been done and there still are frames left for later, which seems to me as a right thing to do - because why shouldn't I give it more time when it has made some progress and we remove only one frame per entry to txeof() anyway... this made timeouts harder to get (from ~5-10 seconds of cvsup for unpatched version to 5-6 cvsups with the patched one) but eventually they start appearing and once you get the first one you are quaranteed to get more of them in periodic intervals until you kill cvsup. So any ideas on how to debug this one would be most welcome too. Sven Petai