lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 12 Dec 2008 16:41:55 +0900
From:	ohashi-h@...dnes.nec.co.jp
To:	Jeff Kirsher  <jeffrey.t.kirsher@...el.com>
Cc:	jesse.brandeburg@...el.com, bruce.w.allan@...el.com,
	peter.p.waskiewicz.jr@...el.com, john.ronciak@...el.com,
	jgarzik@...ox.com, netdev@...r.kernel.org,
	e1000-devel@...ts.sourceforge.net, h-shimamoto@...jp.nec.com,
	ohashi-h@...dnes.nec.co.jp
Subject: Re: e1000: LED indicates trouble, and [PATCH] enable/disable of force-link-up


ohashi-h@...dnes.nec.co.jp wrote (2008/12/04 18:24:21 +0900 ):
>
>Jeff Kirsher wrote (2008/12/03 17:12:00 +0900 ):
>
>>On Tue, Dec 2, 2008 at 11:36 PM,  <ohashi-h@...dnes.nec.co.jp> wrote:
>>> From: Hiroki Ohashi  <ohashi-h@...dnes.nec.co.jp>
>>>
>>> Hi all,
>>>
>>> I faced the following situations.
>>> The LED of NIC was indicated, even when the system was not linked
>>> the network (auto-negotiation failed or link partner cannot
>>> auto-negotiate).
>>> LED should be indicate only when the network was linked.
>>> And so, it is a problem that LED indicates.
>>>
>>> I think the indicating the LED is a problem for maintenance.
>>> I cannot know the condition of the link, because I confirm
>>> to link up by LED's indication.
>>>
>>> We are using 82571EB ethernet controler and serdes interface.
>>>
...

>>
>>I am a little confused.  You state you are using an NIC (82571EB)
>>which is currently not supported by e1000, but is supported in the
>>e1000e driver.  Then you suggest a change to the e1000 driver to
>>resolve an issue you see with your 82571EB NIC.
>>
>>So I would suggest you use the e1000e driver first.
>
>Thank you, I will try again using e1000e driver.
>
>>Also the Link LED is supposed to indicated that there is a "physical"
>>link, in which case you can have a physical connection and still fail
>>auto-neg.  So I do not necessarily agree with your interpretation of
>>what a link LED is supposed to indicate.
>
>My explanation was insufficiently.
>My system was NOT connected LAN cable to NIC, but the Link LED
>was indicated.
>So the problem is the LED is indicated without connecting the cable.
>

I tried again using kernel 2.6.27.8 (e1000e driver).
The LED of NIC was indicated, even when the system was not 
connected LAN cable.
When I deleted logic of force-link-up (the following modification.),
the LED was turned off.

I think it is a problem that LED indicates.
If you have any good way to modify, please let me know.
(Patches are considering.)

================================================
--- drivers/net/e1000e/lib.c.org
+++ drivers/net/e1000e/lib.c
@@ -539,8 +539,6 @@ s32 e1000e_check_for_serdes_link(struct 
                        mac->autoneg_failed = 1;
                        return 0;
                }
+#if 0
                hw_dbg(hw, "NOT RXing /C/, disable AutoNeg and force link.\n");
 
                /* Disable auto-negotiation in the TXCW register */
@@ -550,7 +548,7 @@ s32 e1000e_check_for_serdes_link(struct 
                ctrl = er32(CTRL);
                ctrl |= (E1000_CTRL_SLU | E1000_CTRL_FD);
                ew32(CTRL, ctrl);
+#endif
-
                /* Configure Flow Control after forcing link up. */
                ret_val = e1000e_config_fc_after_link_up(hw);
                if (ret_val) {
================================================

Hiroki Ohashi
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ