Re: Realtek RT8139 (onboard) - failed to receive packet in loopback mode

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 _at_
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