Deja Vu all over again

John F. Kohler jkohler2 at earthlink.net
Sun Apr 1 22:13:33 PDT 2001



ME wrote:

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

That is "doable."  All I need is a "Return Materials Authorization number
(RMA#) from
Jameco, and to take it back there.  30 day return priviliges, 90 day repair
guarantee.

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

I know IRQ11 is not used by others, and an i/o port exists at 0x240, among
others.

> 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
> present io-port.

For that, I need to successfully boot the machine with DOS which is a problem.

I created 2 more boot disks that would, in fact, boot the "old" pc, but not
the
"new" pc so I concluded I have a faulty floppy drive in my "new" pc.

I need to replace the floppy drive, or obtain a cd-rom (ugh) for booting
Windows
to inspect the ports and IRQs.

>
>
> > 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
> computer.

That would be the "Accton" NIC for which my son is downloading the
setup and driver code on his windows machine.

>
>
> > > 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.)
>

I would like to attempt that, but maybe tomorrow, early, when I
can be a little more attentive.  Being a "morning person"  I tend
to make mistakes at night.  Must be low blood sugar or something.

>
> (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
> > successful?
>
> 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.

I, too, am suspecting hardware more now.  I  **know** that I have a
faulty floppy drive, so another hardware problem would not surprise me.


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

Once again, for all the time and thought you have put into my problem...

Thanks...

John




More information about the talk mailing list