[PLUG] Network issues

jen montserrat jen.montserrat at gmail.com
Wed Jan 20 23:43:39 UTC 2010


Have you tried using another patch cable, just to rule out the possibility
of it being the network cable?  If this is a wireless interface, please
ignore this post

On Wed, Jan 20, 2010 at 11:23 PM, Denis Heidtmann <denis.heidtmann at gmail.com
> wrote:

> On Wed, Jan 20, 2010 at 2:32 PM, Mike Connors <mconnors1 at gmail.com> wrote:
> > drew wymore wrote:
> >> Would love to try what you suggest, except I do not understand.  Is
> >> this something that I can do when the network is in the failed state?
> > Okay, so let me see if I got this straight? Networking only fails upon
> > bootup and when it doesn't work you can't ping the router and you don't
> > see an entry "1000baseT/Full"under "Advertised link modes"?
>
> Correct.
>
> >
> > Okay, so lets start from OSI layer 1 and work up.
> >
> > 1. When networking fails upon bootup are there lights on your ethernet
> > ports on the computer and on the router?
>
> It is up now (obviously, as it is my only communication route), but I
> recall seeing lights at the computer when it was in failed mode.  On
> the next failure I will make note of which lights and which color.
> When the network is broken the lights on the modem are the same as
> when the network is up.
> >
> > 2. When you run the command "ifconfig -a", is the eth interface listed?
> > Does it have an ip addr?
> Captured when failed:
> parents at R2D4:~$ ifconfig -a
> eth0      Link encap:Ethernet  HWaddr 00:22:15:b9:82:9a
>          inet addr:192.168.0.70  Bcast:192.168.0.255  Mask:255.255.255.0
>          inet6 addr: fe80::222:15ff:feb9:829a/64 Scope:Link
>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:180 (180.0 B)  TX bytes:0 (0.0 B)
>          Interrupt:252 Base address:0x2000
>
> lo        Link encap:Local Loopback
>          inet addr:127.0.0.1  Mask:255.0.0.0
>          inet6 addr: ::1/128 Scope:Host
>          UP LOOPBACK RUNNING  MTU:16436  Metric:1
>          RX packets:97 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:97 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>          RX bytes:9457 (9.4 KB)  TX bytes:9457 (9.4 KB)
>
> vboxnet0  Link encap:Ethernet  HWaddr 0a:00:27:00:00:00
>          BROADCAST MULTICAST  MTU:1500  Metric:1
>          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
> Note: No change from when functioning  except RX/TX packet counts.
>
> > 3A. If the eth interface is listed, what happens if you attempt to
> > manually bring up the eth interface with "ifup eth#" command.
> >
> > Does it say it's already configured?
>
> I have not tried that without first running ifdown.  Add that to my list.
>
> > root at mc-goose:~# "ifup eth2"
> > ifup: interface eth2 already configured
> >
> > Or does is say throw an error?
> >
> > 3B.  If the eth interface is *not* listed, what happens if you grep
> > dmesg for that interface, such as:
>
> The dmesg currently contains only one eth0 entry:
> [    4.509313] forcedeth 0000:00:0a.0: ifname eth0, PHY OUI 0x732 @ 3,
> addr 00:22:15:b9:82:9a
>
> However, in scanning the kern log for yesterday I see something which
> looks nasty:
> Jan 19 19:29:09 R2D4 kernel: [ 7055.002395] eth0: link down.
> Jan 19 19:29:16 R2D4 kernel: [ 7061.616375] eth0: link up.
> Jan 19 19:29:34 R2D4 kernel: [ 7080.188668] eth0: link down.
> Jan 19 19:29:54 R2D4 kernel: [ 7099.237281] eth0: link up.
> Jan 19 19:30:01 R2D4 kernel: [ 7107.162817] eth0: link down.
> Jan 19 19:30:03 R2D4 kernel: [ 7109.134846] eth0: link up.
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804117] ------------[ cut here
> ]------------
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804126] WARNING: at
> /build/buildd/linux-2.6.28/net/sched/sch_generic.c:226
> dev_watchdog+0x270/0x280()
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804131] NETDEV WATCHDOG: eth0
> (forcedeth): transmit timed out
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804135] Modules linked in:
> binfmt_misc vboxnetadp vboxnetflt vboxdrv input_polldev lp
> snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy
> snd_seq_oss snd_seq_midi ppdev snd_rawmidi snd_seq_midi_event snd_seq
> snd_timer snd_seq_device nvidia(P) pcspkr snd video soundcore output
> k8temp shpchp usblp snd_page_alloc parport_pc parport usbhid forcedeth
> floppy raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0
> multipath linear fbcon tileblit font bitblit softcursor
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804199] Pid: 0, comm: swapper
> Tainted: P           2.6.28-17-generic #58-Ubuntu
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804203] Call Trace:
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804207]  <IRQ>
> [<ffffffff80250b57>] warn_slowpath+0xb7/0xf0
> ...
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804411] ---[ end trace 95ed138ef01fbafe
> ]---
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804416] eth0: Got tx_timeout. irq:
> 00000000
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804419] eth0: Ring at 3759a000
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804422] eth0: Dumping tx registers
> Jan 19 19:30:44 R2D4 kernel: [ 7149.804430]   0: 00000000 000000ff
> 00000003 01a603ca 00000000 00000000 00000000 00000000
> ...
> Jan 19 19:30:44 R2D4 kernel: [ 7149.805331] eth0: Dumping tx ring
> Jan 19 19:30:44 R2D4 kernel: [ 7149.805335] 000: 00000000 7554b802
> a0000059 // 00000000 37582c02 a000004d // 00000000 3792bc02 a0000029
> // 00000000 375a6802 a0000045
> ...
> Jan 19 19:30:44 R2D4 kernel: [ 7149.805875] eth0: tx_timeout: dead entries!
> Jan 19 19:48:52 R2D4 kernel: Inspecting /boot/System.map-2.6.28-17-generic
> ....
>
> Unfortunately I cannot say what was going on at the time. I believe
> the network was up, but perhaps this indicates a problem occurring
> while the machine is up (as opposed to just during boot).  I have had
> problems with Evolution locking up, requiring "killev" action.  Next
> time this occurs I will check dmesg and the kernel log.
>
> See my other post about MII-tool:
>
> sudo mii-tool -v
> SIOCGMIIPHY on 'eth0' failed: Operation not supported
> no MII interfaces found
>
> Thanks for your step-by-step.  Just what I need.
>
> -Denis
> _______________________________________________
> PLUG mailing list
> PLUG at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>



More information about the PLUG mailing list