On Mon, Jan 25, 2010 at 12:33 PM, Steve D... <blitt...@gmail.com> wrote: > On Sat, Jan 23, 2010 at 7:17 PM, Denis Heidtmann > <denis.heidtm...@gmail.com> wrote: >> >> 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. > > Not without a digital storage scope and maybe a PCI(e) bus debugger. :-) > >> 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. > > Things are much more complex than they appear. Motherboards have > brains now. The state of the ethernet negotiation isn't tied to the > front panel power button and the ifconfig command any longer. Newer > motherboards have advanced power and management features like "Green > PC", ACPI, and IPMI. These motherboards have systems running beneath > your level that have their own agenda. Your ability to interact with > these systems is limited. > > You really don't control the motherboard any longer. A > micro-controller called a Management Engine (ME) controls the system > power and PCI/PCIe bus. The MEs have a tendency to do their own > thing. They will down speed and/or renegotiate the link whenever > their programming says to. It ain't easy being a Green PC. > > The ME actually talks directly to the NIC. The PCIe 2.1 standard > (and above) include a serial link from the ME into the PCIe cards. > The older standards used an external serial cable. The ME *controls* > your NIC. It can do all kinds of interesting things, like IPMI and > LOM. The *only* way for a user to determine the state of the NIC is > to monitor the LEDs. > > You may be able to turn off most of the ME by fiddling with the BIOS > and turning off ACPI support in the kernel. You can tell if ACPI is > running by trying to put the OS into Sleep (S3) or Hibernate (S4). > You OS cannot go to S3/S4 unless ACPI and the ME is enabled Turning > off ME (not really... psyc!) may cut down on some of the link problems > you're seeing. It will also disable many of the "Green PC" features > of your system. > >> Do you see this as an accurate assessment? > > Pretty much... Your available choices are: > > 1) Deal with it... You many have to "ifconfig up" your eth port from > time to time. :-) > > 2) Nail your NIC and switch port to 1000-Full. This will only works > on a managed switch. Only nailing one side can result in a > duplex-mismatch. > > 3) Install a different NIC. I like the Intel cards. Make sure to > replace the distro's in-box driver. The latest and greatest Intel > Linux drivers up on Sourceforge are pretty good. > > 4) Open up an issue with your NIC manufacture. They may be willing to > troubleshoot the problem and provide a fixed driver. This would be > good for the Linux community. Somebody has to be willing to feel the > pain so we can all reap the benefits. :-) > > Steve D... > Once again I thank you for the information. I have been thinking that the thing which changes from one power-on--boot to the next is the time from when the juice is connected to the desktop to when I press the front panel button. The stuff about the ME may fit in with this. I can explore this when I feel not having a connection will not be too painful.
With regard to your steps above. 1) I have tried ifdown/ifup to no avail. I have not tried ifconfig up. When I break the network I will try it. 2) my modem does not support 1000, and I have no switch. 3) A new card is on my list. 4) I plan to do that, but the thought of dealing with ASUS (the MB mfg.) makes me think of a tar pit. Thanks. -Denis _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug