[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:
> 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