[nSLUG] no networking

George N. White III aa056 at chebucto.ns.ca
Tue Jan 6 15:02:34 AST 2004


On Tue, 6 Jan 2004, Bill Davidson wrote:

> On January 6, 2004 10:23 am, M Taylor wrote:
> > On Mon, Jan 05, 2004 at 11:15:32PM -0400, bdavidso at supercity.ns.ca wrote:
> > > So this seems to be a problem with the eth0 device.  The message (in your
> > > other post) about "NETDEV WATCHDOG: eth0 transmit timed out" comes from
> > > net/sched/sch_generic.c in function dev_watchdog(), as follows:
> >
> > It appears to be a slightly infrequent but possibly persisent bug in the
> > kernel (from 2.4.5 to at least 2.4.22) that affects various NICs
> > (via_rhine, 3com 3c????, and several cases of Realtek 8139 series).
> > The issue has to do with either power management (APCI) or APIO I think.
>
> I did a little googling on this, too, and also found a lot of references,
> especially with early 2.4 kernels.  The tulip driver seemed to produce this
> problem a lot as well.  I didn't see any references to ACPI, but I did see a
> lot of references to APIC's, (Advanced Programmable Interrupt Controller)
> especially on smp kernels.  Some said booting with noapic would fix the
> problem.  I notice you are (were?) using an smp kernel -- is it a
> multi-processor machine, or are you just being hopeful?

I have a uni-proc. system that runs a 2.2.21 SMP kernel and has network
and USB problems with some APIC and ACPI settings.  Gleaning from problem
reports and the kernel docs, I played with the following options until I
found a combination that works:

apic
noapic
nolapic
lapic
acpi=on
acpi=off
acpi=ht
pci=noacpi apic

> It also seems that sometimes linux NIC drivers get the line
> characteristics wrong, so set FD when it should be HD or something.  I
> recall a discussion here not longago where someone was having similar
> problems (not identical, not reference to NETDEV WATCHDOG) even though
> another OS worked OK on the same hardware.  Turned out he had a wrong
> cable type (xover instead of straight-thru or vice-versa) and the other
> OS's driver corrected for it, but the linux driver didn't (I think he
> was getting a lot of framing errors).  Or something like that (waves
> hands vaguely...).

Not just linux -- SGI systems sometimes have problems with
autonegotiation.  When it happens I rebuild the kernel for F100 and
get the switch port set to match (which means I have to reconfigure
the new kernel for each OS upgrade).

> > Since I didn't have a spare NIC and that is my main home access to the
> > Internet I didn't spend too much time isolating the problem and reinstalled
> > my linux distribution.

Much too drastic and not very informative.

> Well if the reinstall fixed it then I guess that's that, although I am
> curious about what went wrong.  Say, you wouldn't mind breaking it again so
> we could fool around with it some more, would you?

Or at least check if the flags passed to the kernel have changed?

--
George N. White III  <aa056 at chebucto.ns.ca>
  Head of St. Margarets Bay, Nova Scotia, Canada




More information about the nSLUG mailing list