Has anyone exercised the gt64260_eth.c driver (from the MontaVista
BK tree) for any length of time? I ported it and have been using
it successfully for several weeks, but find that it can't sustain
continuous file transfers for more than a few hours.
I'm running a loop with ftp putting/getting a 24-MB file to a remote
Linux system, and find that after a few hours, the "put" times out.
It happens on any of the 3 ports, and to/from several different
systems (G4 Mac or PC). I run the test on the same system through
a I82559 chip and it runs all weekend.
The only clue I have it that the driver reports a flurry of RX CRC
errors when the timeout occurs. After ftp quits, I can ping the
remote system, but the RX packets seem to be mismatched with the
TX (ping reports once a second, but instead of ~100 usec transit
time, it reports 1.000 sec, or 2.000 sec, or 3.000 sec, as if it's
getting RX packets that are 1, 2, 3 seconds old).
Anyone else seen anything like this?
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Thu, 30 May 2002, Bill Fincke wrote:
Has anyone exercised the gt64260_eth.c driver (from the MontaVista
BK tree) for any length of time? I ported it and have been using
it successfully for several weeks, but find that it can't sustain
continuous file transfers for more than a few hours.
I'm running a loop with ftp putting/getting a 24-MB file to a remote
Linux system, and find that after a few hours, the "put" times out.
It happens on any of the 3 ports, and to/from several different
systems (G4 Mac or PC). I run the test on the same system through
a I82559 chip and it runs all weekend.
The only clue I have it that the driver reports a flurry of RX CRC
errors when the timeout occurs. After ftp quits, I can ping the
remote system, but the RX packets seem to be mismatched with the
TX (ping reports once a second, but instead of ~100 usec transit
time, it reports 1.000 sec, or 2.000 sec, or 3.000 sec, as if it's
getting RX packets that are 1, 2, 3 seconds old).
The n-seconds ping times mean that the driver and the hardware got out-of-sync
w.r.t. the current entry in the ring buffer.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Bill Fincke wrote:
Has anyone exercised the gt64260_eth.c driver (from the MontaVista
BK tree) for any length of time? I ported it and have been using
it successfully for several weeks, but find that it can't sustain
continuous file transfers for more than a few hours.
I'm not all that surprised that you've run into something. Both the
ethernet and mpsc (uart) drivers for the controllers on that bridge are
pretty much hacks. They need to be rewritten at some point. To be
honest, after looking at them, I'm surprised they work as well as they
do. Its a project just waiting for a volunteer just like you!! ;)
Mark
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/