[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4BA1BCC9.1080401@windriver.com>
Date: Thu, 18 Mar 2010 13:40:25 +0800
From: "yucheng.wang" <yucheng.wang@...driver.com>
To: netdev@...r.kernel.org
CC: Bruce.Ashfield@...driver.com, Shuo.Kang@...driver.com,
Bo.Liu@...driver.com, rongkai.zhan@...driver.com,
Yang.Shi@...driver.com, Shuo.Liu@...driver.com
Subject: Help: the 82577 network driver can't work
Hi all,
I need some help for intel 82577 network card driver, named
CONFIG_E1000E in the kernel config.
In the kernel 2.6.31 and 2.6.32, the patch works well, but in the kernel
2.6.33 and 2.6.34-rc1 the dmesg shows some problem below,and the network
card can't work.
**********************************************************************
e1000e: Intel(R) PRO/1000 Network Driver - 1.0.2-k2
e1000e: Copyright (c) 1999 - 2009 Intel Corporation.
e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
0000:00:19.0: 0000:00:19.0: Write-protect NVM Disabled
0000:00:19.0: 0000:00:19.0: Failed to initialize MSI interrupts. Falling
back to legacy interrupts.
ata4: SATA link down (SStatus 0 SControl 300)
ata3: SATA link down (SStatus 0 SControl 300)
ata2.00: SATA link down (SStatus 0 SControl 300)
ata2.01: SATA link down (SStatus 0 SControl 300)
ata1.00: SATA link down (SStatus 0 SControl 0)
ata1.01: SATA link down (SStatus 0 SControl 300)
e1000e 0000:00:19.0: PCI INT A disabled
e1000e: probe of 0000:00:19.0 failed with error -3
********************************************************************
I read the source code using 2.6.34-rc-1 kernel.
When calling e1000e_git_phy_id(), the function returns a wrong value
"-3". The kernel 2.6.31 and 2.6.32 ignores this error, and the kernel
run well. The function e1000_acquire_swflag_ich8lan( ), called by
e1000e_get_phy_id(), return "-3".
************************** The code *********************************
extcnf_ctrl |= E1000_EXTCNF_CTRL_SWFLAG;
ew32(EXTCNF_CTRL, extcnf_ctrl);
while (timeout) {
extcnf_ctrl = er32(EXTCNF_CTRL);
if (extcnf_ctrl& E1000_EXTCNF_CTRL_SWFLAG)
break;
mdelay(1);
timeout--;
}
if (!timeout) {
e_dbg("Failed to acquire the semaphore.\n");
extcnf_ctrl&= ~E1000_EXTCNF_CTRL_SWFLAG;
ew32(EXTCNF_CTRL, extcnf_ctrl);
ret_val = -E1000_ERR_CONFIG;
goto out;
}
************************** The code *********************************
The kernel can't set the bit E1000_EXTCNF_CTRL_SWFLAG of the register
EXTCNF_CTRL.
We found the information in the 82577 user manual:
In the Extended Configuration Control Register.
Software Semaphore FLAG (SWFLAG). This bit is set by the device driver
to gain access permission to shared CSR registers with the firmware and
hardware. The bit is initialized on power up PCI reset and software
reset. and the default value when Reset is "0b".
I don't know why the bit E1000_EXTCNF_CTRL_SWFLAG is not right, and not
find any information about writing the bit. Due to the bit returns 0
when reset the controller, we wrote the patch below.
*****************************The patch**********************************
diff --git a/drivers/net/e1000e/ich8lan.c b/drivers/net/e1000e/ich8lan.c
index 8b6ecd1..b3e20f4 100644
--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -224,6 +224,7 @@ static void
e1000_power_down_phy_copper_ich8lan(struct e1000_hw *hw);
static void e1000_lan_init_done_ich8lan(struct e1000_hw *hw);
static s32 e1000_k1_gig_workaround_hv(struct e1000_hw *hw, bool link);
static s32 e1000_set_mdio_slow_mode_hv(struct e1000_hw *hw);
+static s32 e1000_reset_hw_ich8lan(struct e1000_hw *hw);
static inline u16 __er16flash(struct e1000_hw *hw, unsigned long reg)
{
@@ -276,8 +277,12 @@ static s32 e1000_init_phy_params_pchlan(struct
e1000_hw *hw)
phy->id = e1000_phy_unknown;
ret_val = e1000e_get_phy_id(hw);
- if (ret_val)
- goto out;
+ if (ret_val) {
+ e1000_reset_hw_ich8lan(hw);
+ ret_val = e1000e_get_phy_id(hw);
+ if (ret_val)
+ goto out;
+ }
if ((phy->id == 0) || (phy->id == PHY_REVISION_MASK)) {
/*
* In case the PHY needs to be in mdio slow mode (eg. 82577),
****************************************************************************
I'm not sure it's right, but using the patch, 82577 network can work
well.I need more eyes about this, how can I make the patch better?
Any suggestion would be helped me make the patch better.
By the way, we find 3 patches make it not well.
From 0be8401051c716be4533272e983b7eed3d83946d Mon Sep 17 00:00:00 2001
From: Bruce Allan <bruce.w.allan@...el.com>
Date: Wed, 2 Dec 2009 17:03:18 +0000
Subject: e1000e: correct ICH/PCH PHY operations function pointers
From fddaa1aff881c98f524221236af98ce70dcd04cf Mon Sep 17 00:00:00 2001
From: Bruce Allan <bruce.w.allan@...el.com>
Date: Wed, 13 Jan 2010 01:52:49 +0000
Subject: e1000e: MDIO slow mode should always be done for 82577
From baf86c9d36826fab0160251bbc87dfab3af48a21 Mon Sep 17 00:00:00 2001
From: Bruce Allan <bruce.w.allan@...el.com>
Date: Wed, 13 Jan 2010 01:53:08 +0000
Subject: e1000e: workaround link issues on busy hub in half duplex on
82577/82578
thanks,
Yucheng.Wang
--
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