On Sat, Jan 23, 2010 at 11:27 AM, Steve D... <blitt...@gmail.com> wrote: > On Thu, Jan 21, 2010 at 7:25 PM, Mike Connors <mconno...@gmail.com> wrote: >> Denis Heidtmann wrote: >>> I am glad you have focused on this. Since it is the only thing I have >>> found which is consistently different between failed and working >>> modes, it deserves some scrutiny. I think it is interesting that the >>> unused capability (1000baseT) is what is missing when in the failed >>> mode. Does it mean that the negotiation failed at that point? Is >>> there any way to snoop on the negotiation process? I have wireshark, >>> but am not familiar with running it. >>> >>> Thanks for you interest. >>> >>> -Denis >> Argh, I'm baffled by this auto-neg behavior because why does it only >> happy once in blue moon and only upon booting. So yeah, you could use >> tcpdump and filter on any traffic for that eth interface. But I suspect >> by the time you get it setup the problem will have already occurred. > > Ethernet auto-negotiation occurs down at the physical level. It > involves sets of "link pulses" and "fast link pulses" that are > exchanged between the partners to advertise and negotiate the link > parameters. You need a digital storage oscilloscope to monitor the > negotiation. > > Autonegotiation > http://en.wikipedia.org/wiki/Autonegotiation > > It's essentially magic. The Ethernet PHY chip handles the link and > reports the results to the higher layers. You can't get involved from > the keyboard. > > The newer chipsets end up doing a lot of renegotiation. The power > saving modes in the new motherboards will down speed the link to > 10Full when the system goes into sleep or hibernation modes. Laptops > are especially aggressive about down speeding to help save power. > They renegotiates back to higher speeds when system activity wakes the > machine back up. > > Any Gig ethernet port will probably also contain some power saving > modes. You need to visually monitor the link LEDs in the back of the > card to figure out what mode your eth phy is running in. The ethtool > command will not tell you what is really happening. > >> What might be a simpler and possibly more effective is to use ethtool to >> restart auto-neg and tail the log file and capture the auto-neg mssgs. >> See link below for how-to. Then when the networking fails, cat the log >> file and grep for any mssgs for that eth interface. > > You need to remember that some link modes will result in a Duplex > Mismatch. You can create link problems by manually configuring an > invalid configuration. > > General Troubleshooting for 10/100/1000 Mbps NICs > Autonegotiation Valid Configuration Table > http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a00800a7af0.shtml#auto_neg_valid > > Steve D...
Thanks for all the information. You have saved me from a fruitless bunch of tests. I do not claim to have gotten my head around all the stuff in those links, but I have the impression that if the NIC is misbehaving during the autonegotiation process I have no reasonable way to find that out. The connection has not had a failure for some days now (many shutdowns and reboots, but no interruption of power to the modem or the computer), even though renegotiation is likely happening often. Also, when failure occurs the only thing which appears to fix it is to shut down and power down the computer. I conclude from this that most likely the NIC occasionally gets into a bad state during power-up. Do you see this as an accurate assessment? -Denis _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
