Realtek RT8139 (onboard) - failed to receive packet in loopback
mode
Sven Petai
hadara at bsd.ee
Sat Jun 19 20:14:12 GMT 2004
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
More information about the freebsd-current
mailing list