Transmit timed out
Osma Ahvenlampi
oa@razorfish.fi
Tue Feb 9 15:06:37 1999
Bret Martin wrote:
> oa@razorfish.fi (Osma Ahvenlampi) writes:
> > No one definitely knows why the problem occurs (if we did, someone
> > could fix it, right?), but here's some data:
> From your apparent exasperation in some mail to this list, I thought
> you had detailed the problem with some specificity, but that Don
> (presumably most qualified to fix the problem) wasn't paying attention
> to your pleas for some reason. Apologies for my misunderstanding.
Well, with no hard evidence pointing otherwise, I have to assume that
either my diagnosis is faulty or at least incomplete enough to make
tracking the problem down too difficult. I wouldn't want to blame Don
for not paying attention, being grateful for having a driver in the
first place. After all, it does work for me reliably once I figured out
this workaround.
> The problem occurs for me on a network without any AppleTalk at all,
> and I'm not running netatalk. Based on what's been described, I would
> have expected the problem to occur at the same time on all my machines
> (on a given network) with EEPro100s. (They all get the same multicast
> traffic, right?) But it doesn't happen at the same time, and, indeed,
> doesn't happen on all the machines, either.
The machines wouldn't necessarily all receive the same multicast traffic
(multicast being different from broadcast, after all), but most
certainly they wouldn't be interrupt-synchronised. I've only seen the
"transmit timed out" problem (or indeed any disabling problem whatsoever
- if there are nondisabling problems that don't show up in logs nor have
a serious adverse effect on performance, I might have not noticed them)
in relation to the multicast traffic generated on out network by
AppleTalk. We don't receive multicast traffic from the Internet, since
our ISP doesn't support multicast routing, and I've not yet started
playing with other multicast software on the LAN. Our LAN is at times
busy enough that I would expect to see a problem if it could happen with
normal unicast traffic as well, but perhaps I've just been lucky.
Do you have machines that never experience this problem, even though
their based on their configuration they "should"? If that's so, perhaps
we should try to figure out the common denominator in the systems that
do show this behaviour, and their difference to the immune systems. I
can tell you right now that in none of the Linux machines I have with
eepro100 cards is the card sharing interrupts with other hardware, so
this isn't just a shared-interrupt problem.
--
osma ahvenlampi || | || | | | || | r a z o r f i s h
| | | | h e l s i n k i