On Thu, Jan 21, 2010 at 10:19 AM, drew wymore <drew.wym...@gmail.com> wrote: > On Thu, Jan 21, 2010 at 10:09 AM, Denis Heidtmann > <denis.heidtm...@gmail.com> wrote: >> On Thu, Jan 21, 2010 at 6:50 AM, Steve D... <blitt...@gmail.com> wrote: >>> On Wed, Jan 20, 2010 at 10:38 PM, Denis Heidtmann >>> <denis.heidtm...@gmail.com> wrote: >>>> >>>> I had previously posted this: >>>> 00:0a.0 Ethernet controller: nVidia Corporation MCP78S [GeForce 8200] >>>> Ethernet (rev a2) >>>> Subsystem: ASUSTeK Computer Inc. Device 82f2 >>>> Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 2300 >>>> Memory at fcf7c000 (32-bit, non-prefetchable) [size=4K] >>>> I/O ports at c880 [size=8] >>>> Memory at fcf7f400 (32-bit, non-prefetchable) [size=256] >>>> Memory at fcf7f000 (32-bit, non-prefetchable) [size=16] >>>> Capabilities: [44] Power Management version 2 >>>> Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ >>>> Queue=0/4 Enable+ >>>> Capabilities: [6c] HyperTransport: MSI Mapping Enable+ Fixed+ >>>> Kernel driver in use: forcedeth >>>> Kernel modules: forcedeth >>>> >>>> This tells me the driver name. It is not clear to me what to do with >>>> this information. >>> >>> It sounds like you may have a flaky kernel module for that ethernet >>> chip. The command "modinfo forcedeth" will show you the module >>> version. You can check if the motherboard or chipset manufacture has >>> a more recent module available. You will probably need to install the >>> kernel source code and software build tools to compile the new module. >> ... >>> Steve D... >> >> I found this: http://ubuntuforums.org/showthread.php?t=1095682 >> I do not know if it relates to my issue. >> >> >> pare...@r2d4:~$ modinfo forcedeth >> filename: >> /lib/modules/2.6.28-17-generic/kernel/drivers/net/forcedeth.ko >> license: GPL >> description: Reverse Engineered nForce ethernet driver >> author: Manfred Spraul <manf...@colorfullife.com> >> srcversion: 9C1164A059BC26160F21FCA >> alias: pci:v000010DEd00000AB3sv*sd*bc*sc*i* >> ... (long list)... >> alias: pci:v000010DEd000001C3sv*sd*bc*sc*i* >> depends: >> vermagic: 2.6.28-17-generic SMP mod_unload modversions >> parm: max_interrupt_work:forcedeth maximum events handled >> per interrupt (int) >> parm: optimization_mode:In throughput mode (0), every tx & >> rx packet will generate an interrupt. In CPU mode (1), interrupts are >> controlled by a timer. (int) >> parm: poll_interval:Interval determines how frequent timer >> interrupt is generated by [(time_in_micro_secs * 100) / (2^10)]. Min >> is 0 and Max is 65535. (int) >> parm: msi:MSI interrupts are enabled by setting to 1 and >> disabled by setting to 0. (int) >> parm: msix:MSIX interrupts are enabled by setting to 1 and >> disabled by setting to 0. (int) >> parm: dma_64bit:High DMA is enabled by setting to 1 and >> disabled by setting to 0. (int) >> parm: phy_cross:Phy crossover detection for Realtek 8201 phy >> is enabled by setting to 1 and disabled by setting to 0. (int) >> >> I do not see a module version in a form that is familiar to me. >> >> It occurred to me that since the machine supports wake-on-lan, that as >> long as there is power to the box the network "card" must be active. >> This could explain why a change in state only occurs through a >> power-off cycle. Does this help? >> >> -Denis >> _______________________________________________ >> PLUG mailing list >> PLUG@lists.pdxlinux.org >> http://lists.pdxlinux.org/mailman/listinfo/plug >> > > I would give the command that was used in that post you linked a try > and see what happens, it can't hurt. > > I would try: > > ethtool -s eth0 speed 100 duplex full autoneg off > > You can also try the suggestion of adding to rc.local since it seem so > to be a transient error that clears itself on reboot if I recall you > wrote correctly. > > What kernel version are you using? It might be possible to grok the > mod version of the NIC module from knowing what kernel it was built > into. > > Drew-
pare...@r2d4:~$ uname -a Linux R2D4 2.6.28-17-generic #58-Ubuntu SMP Tue Dec 1 21:27:25 UTC 2009 x86_64 GNU/Linux This is also in the modinfo's first line. Since the failures occur much less frequently than proper operation, a trial such as "ethtool -s eth0 speed 100 duplex full autoneg off" would take a long time to prove anything. A string of commands to try when the network has failed at least gives immediate feedback. Is network restart a possible candidate? Do I need to rmmod as well? If I remove the module, what puts it back? The modprobe man page seems to have some errors in it, so I am reluctant to experiment. (BTW, my system has no such command as "network"). -Denis _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug