[lug] Networking question ...

[D. Stimits]

rm at mamma.varadinet.de wrote:
> 
> On Tue, Feb 06, 2001 at 06:00:24PM -0700, D. Stimits wrote:
> 
> > This implies that one day the two companies will merge.
> 
> Don't scare me! Actually, i recently found out that my
> local provider technically is owned by QWorst. Global
> market i guess ...
> 
> >
> > There are some ARP options in kernel compile. It is VERY useful if each
> > kernel that is installed and works has an archive storage of its config
> > for comparisons.
> 
> I have those (allways save them, just in case). I would actually
> go for running the thing with the previous 2.0.36 kernel. Un-
> fortunaltely a UPS was added and the proprietary software
> that came with it requests a newer kernel (if i had the time
> i would set up one of the free UPS daemons ...).
> 
> > > There's a webserver attached to the same hub (oh, i forgot
> > > to mention, there's a hub between CISCO and gateway), so
> > > in fact two boxes are set up in parallel. The webserver
> > > works fine al the time and can be reached during downtime
> > > of the gateway. It's not possible to reach the gateway
> > > from the webserver, even so they are on the same bus.
> > > Hence the fibre optic cable seems to be ok, it could
> > > be either a bad hub port (but why would it work after
> > > reboot) or a bad nic (SMC 9432 TX (rev 8) again, why would
> > > it work after reboot) or ??? I suspect that something upsets
> > > the card/driver: from the little info i have it looks like
> > > the external interface has a lot of dropped packages when
> > > in the state of autism.
> >
> > Once it fails, is the machine examined closely to see if ALL other
> > hardware is functioning correctly? It's rather unlikely, but there is a
> > minor possibility that there is a resource conflict that only shows up
> > once in a great while.
> 
> this is 'theory B'. Unfortunately this is entirely possible. When the
> box was delivered i spent a whole day debugging firewall rules and
> network configuration until i realized that one of the interfaces wasn't
> running because of some weired PCI problems. Everything _looked_ fine,
> the driver loaded, link light was up both on the NIC and the hub. The
> damn thing would just not answer even to the most forcefull pings.
> After several hours of despair and frustration i started the worst
> thing one can do in such a situation: trying out things. I plugged
> out one of the NICs (_not_ the dead one) and put it into a different
> slot. All a sudden everything worked.  This is really not how it's
> supposed to be.
> 
> Ralf

Not all pci hardware is a complete implementation, in that not all items
have the ability to be completely redirected to all irq and dma and io
values. For example, I believe there are pci sound cards out there that
only work with irqs 3 through 7. If during bootup a flexible component
of pci uses up a value that the next pci component needs (based on taken
value being the last value that less-flexible actually has a
possibitility to work with), then the later item will fail. In the case
of dual (or more) NICs, I think you have both that possibility and also
the problems of making sure the system knows the proper settings on
every card beyond the first one that shows up on the bus (possibly
requiring reservation of resources, followed by an init script once the
system is basically up).