eepro100 Transmit timeouts - time to cut my losses? & misc

[David Ford]

"Jay Freeman (saurik)" wrote:

> Personally, I am just going to ditch using the card as my main interface and
> get myself a PCI 3c905 and use that instead, but continue trying the new

i prefer tulip based cards.


> Here is something strange:  After upgrading to 1.09l I am still getting
> problems, but I am getting fewer actual "Transmit timed out" messages, and
> instead getting transmission errors every now and then that temporarily
> locks up a single connection while it waits to retry.  Probably useless
> information, but information none-the-less.

donald has a new version, 1.09p, try that.  i haven't yet but i'm on the road.


> On a side note, I am curious, is there any particular reason you don't use
> modules on servers?  I have started advocating the use of modules as much as

performance is one factor, albeit the gain isn't huge.  security is by far the
largest.  i run pretty tight ships with little on them, so it takes a lot more
skill than the drive by hacker to gain access.  eliminating modules gets rid of
even more issues.  once a trojan module is in the kernel, _all_ bets are off
for security.


> thinking.  My main point is that modules seem to allow for the least amount
> of down time when a problem occurs that requires an upgrade, such as this
> Ethernet card.  When a new version of this driver comes out that fixes a

i normally build systems with tulip cards so i don't have ether issues.  by far
and large, my access is via network, so i cannot easily pop modules in and out.



> particular problem, I can upgrade to the new version, taking the Ethernet
> driver out of memory for no more than 15 seconds, and not even sever any of
> the existing, long-term connections that might be in place.  The best

network routing and other oddiments are interrupted when you pull a module.


> explanation I could come up with is that you wanted as much performance as
> you could get, at the expense of availability, but I noticed that you
> mentioned that your client wanted "24/7 connectivity", which is why I bring
> it up.

availability in linux isn't normally a question of driver serviceability.
stuff just works.  so i generally place a higher priority on eliminating
insecurities.


> No one else commented on your mention of IPv6 (at least, that I saw anyway),
> I thought I would mention that I do not have IPv6 compiled into my kernel,
> yet I was still encountering these timeout problems :(.

yes.  ipv6 was another problem and is related to multicast.  hit the l-kernel
and l-net archives for the history.

-d

--
 This is Linux Country. On a quiet night, you can hear Windows NT reboot!
  Do you remember how to -think- ? Do you remember how to experiment? Linux
__ is an operating system that brings back the fun and adventure in computing.
\/  for linux-kernel: please read linux/Documentation/* before posting problems