Deja Vu all over again
dugan at passwall.com
Sun Apr 1 21:20:31 PDT 2001
On Sun, 1 Apr 2001, John F. Kohler wrote:
> I just ran the utility "Mac TCP Watcher" during dinner. it sent 1580
> pings, and 1183 (74%) were returned. 397 (25%) were lost. Minimum
> transit time was .01 seconds, average .08 seconds and maximum was .11
> seconds. I watched the pings go out in groups of 10 before the window
> would refresh and 3 or 4 packets out of 10 (on average) would record
> "echo timed out." Strange, because it was only going 50 feet to the
> router, and 50 feet back to the machine on the same desk. Next I set
> the Linux box to ping the Mac LC. 51 packets transmitted 40 packets
> received. 21% packet loss round-trip min/avg/max/mdev
> =1.609/1.762/4.853/0.51 ms
The above test combined wih the tests done on the linux box and the
inconsistent behavior based on length of time it is operational
(suggestion of heat/expasion or heat/damage) all point more to hardware
problem instead of software error.
If you can get them to replace the "new" card and then configure a
replacement "new" card to use the same settings as the "old" card, and
notice the same problems, then odds are that the problem lies in the way
the linux kernel talks to the card.
Some other things to try for hardware issues: What yuo describe above can
also happen when you have an IRQ or IOport conflict. I know that
/proc/interrupts and /proc/ioports do not show any devices with the same
resources, it is still possibe that you have another device that is trying
to use the same IRQ 10 and io port (whatever), but were not found by the
kernel or reported during startup. You might want to try doing a "cat
/proc/interrupts" and seeing what *other* IRQs are free and then try to
use the software that came with the new ethernert card to choose another
IRQ other than 10 and another ip-port that is not in use, but not the
> I have asked my son in Cotati to download a good copy of the Vendor setup
> disk and send it to me.
This will be good for trying out the old card with RH 7 on your new
> > As another option, you can look into making your old ethernet card work
> > with an installation of RedHat and then add the "new" card and have 2
> > ethernet cards in your box. From there, you can at least test one and
> > diconnect the other one during testing.
> Would one be identified as eth1 and the other eth0?
Precisely. You can also then specify which one you want to be 1 and which
one you want to be 0 in lilo.conf with an append directive. (I can walk
you through this and point you to the docs that can help with it. It is
not very complicated, but I don't want to detail that unless that is a
path you ish to travel.)
(from other e-mail included here now...)
> One more thought... What if I installed Red Hat 6.2 in my AMD k6
> computer (because it ran so long and well in the older pentium) and was
If the problem is a hardware one, this won't fix it. If it is a matter of
code maturity for the parts of the kernel that deal with your NIC
interface, then an earlier kernnel won't likely help either. I would not
put this high on my list of things to test first, but if you feel
like an adventure, then it can be a learning experience. to try it.
Regression to the earlier NIC will probably work fine in RH6 and
RH7. Reinstallation with both cards is also an option.
> Would that not point to flaws in Red hat 7.0 in areas other
> than the kernel? Or, could the kernel in 7.0 be unreliable.
If it is a software issue (not so likely based on what we have so far)
then it could/would be how the kernel/module-inserted-into-the- -kernel
tries to speak to your hardware. Though it is *possibe* RH may have
tampered with (err "improved") the parts of the kernel that deal with your
NIC, it seems unlikely. I suspect the same kernel in another distro would
also have the same problems.
> The rumour was at the time of the 7.0 release that Red Hat
> rushed the software before
> it was fully checked by the many Linux users over the
> planet, particularly up for
> criticism was the "C" compiler and some security flaws in
> the code.
Security flaws have been an issue with RH for a while. The compiler issue
should not affect us in this place though.
More information about the talk