[nSLUG] no networking

bdavidso at supercity.ns.ca bdavidso at supercity.ns.ca
Mon Jan 5 23:15:32 AST 2004


On Sun, 4 Jan 2004, M Taylor wrote:

> Okay I setup a new system with Debian 3.0 (woody) and some 'testing'
> (libc, kernel, xfree86 - which prompted the partial upgrade, I needed
> newer nvidia driver for Geforce4 MX 440) this weekend and now today
> I cannot seem to make it access the network.
> It's running the 2.4.22-686-smp kernel (from testing I believe)
> is using a Realtek 3189 onboard NIC, and gets all its knowhow from
> I am able to use DHCP to renew my leases under other OSes on the
> same machine (OpenBSD 3.4, and that other common OS). So hardware
> and DHCP server are presumably not an issue. OpenBSD uses dhclient
> just like Debian, although I am not certain of which version.

Is the NIC driver loaded?  Try lsmod to see what driver is being used.
Does dmesg show anything interesting about the card or networking?
What about ifconfig?  Do you see TX/RX packets, errors, etc?

Is the machine on a LAN?  If so, can you give it a static IP and see if
things work?

I think you need to breakthe problem down further -- is it an issue with
the card, or DHCP, or what?

> There are some error messages about 'NETDEV: eth0 sending timeout' I think
> it is, but I don't know if this is an accidential symption or a bona fide
> error. Running 'ifup -a' manually doesn't help, it just times out.
> /etc/network/interfaces just has
> iface eth0 dhcp

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:

if (dev->qdisc != &noop_qdisc) {
        if (netif_device_present(dev) &&
            netif_running(dev) &&
            netif_carrier_ok(dev)) {
                if (netif_queue_stopped(dev) &&
                    (jiffies - dev->trans_start) > dev->watchdog_timeo) {
                        printk(KERN_INFO "NETDEV WATCHDOG: %s: transmit
timed out\n", dev->name);

So, to reach that code, the device must be present, it must be running,
carrier must be OK, the queue associated with the device must be stopped,
and some time must have gone by.  I'm no kernel coder, but that at least
tells us something.  I would try replacing the NIC or the cable just for

> Any clues? I'm stumped.
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/cgi-bin/mailman/listinfo/nslug

Bill Davidson
bdavidso at supercity.ns.ca

More information about the nSLUG mailing list