netdev - RE: [PATCH] e1000e: introduce new parameter to disable force-link-up on serdes

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 19 Jan 2009 11:06:46 -0800
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	"ohashi-h@...dnes.nec.co.jp" <ohashi-h@...dnes.nec.co.jp>
CC:	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"jgarzik@...ox.com" <jgarzik@...ox.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"h-shimamoto@...jp.nec.com" <h-shimamoto@...jp.nec.com>,
	"Graham, David" <david.graham@...el.com>
Subject: RE: [PATCH] e1000e: introduce new parameter to disable
 force-link-up on serdes

ohashi-h@...dnes.nec.co.jp wrote:
>>>> 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.)
> 
> I send the patch to modify.

I appreciate your work on this issue but I think you're making the wrong
solution.  We've done some work on a similar issue, does the attached
patch fix the issue for you?

inline also, but (probably) whitespace damaged.


Author: Jesse Brandeburg <jesse.brandeburg@...el.com>
Date:   Mon Jan 19 11:04:11 2009 -0800

    e1000e: do not force link on blades
    
    e1000 originally had a workaround to force link up based
    on some hardware errata on ancient parts.  The e1000e driver
    has carried over this workaround even though it doesn't support
    the same hardware.
    
    letting rx sequence errors drive link up/down events is harming the
logic of
    the state machines that control link state on blade connected e1000e
parts.
    
    remove rx sequence errors from causing link events.
    
    Signed-off-by: Jesse Brandeburg <jesse.brandeburg@...el.com>

diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 91817d0..55b2f6b 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1152,7 +1152,7 @@ static irqreturn_t e1000_intr_msi(int irq, void
*data)
 	 * read ICR disables interrupts using IAM
 	 */
 
-	if (icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) {
+	if (icr & E1000_ICR_LSC) {
 		hw->mac.get_link_status = 1;
 		/*
 		 * ICH8 workaround-- Call gig speed drop workaround on
cable
@@ -1218,7 +1218,7 @@ static irqreturn_t e1000_intr(int irq, void *data)
 	 * IMC write
 	 */
 
-	if (icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC)) {
+	if (icr & E1000_ICR_LSC) {
 		hw->mac.get_link_status = 1;
 		/*
 		 * ICH8 workaround-- Call gig speed drop workaround on
cable

Download attachment "e1000e_rxseq.patch" of type "application/octet-stream" (1457 bytes)

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (6703 bytes)