[PLUG] Network issues

drew wymore drew.wymore at gmail.com
Thu Jan 21 11:51:20 PST 2010


On Thu, Jan 21, 2010 at 11:46 AM, Denis Heidtmann
<denis.heidtmann at gmail.com> wrote:
> On Thu, Jan 21, 2010 at 10:19 AM, drew wymore <drew.wymore at gmail.com> wrote:
>> On Thu, Jan 21, 2010 at 10:09 AM, Denis Heidtmann
>> <denis.heidtmann at gmail.com> wrote:
>>> On Thu, Jan 21, 2010 at 6:50 AM, Steve D... <blitters at gmail.com> wrote:
>>>> On Wed, Jan 20, 2010 at 10:38 PM, Denis Heidtmann
>>>> <denis.heidtmann at 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.
>>>
>>>
>>> parents at 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 <manfred at 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 at 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-
>
> parents at 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 at lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>

My bad for missing it in the modinfo output. If you run the command
perhaps the network won't fail, however it's something to keep in the
back of your mind if and when it does fail again. Network restart
would be a candidate. You can either use modprobe or insmod forcedeth
to re-insert the module or just reboot the system which seems to fix
the problem so it doesn't help troubleshooting it.



More information about the PLUG mailing list