Re: DPRINTKs in e1000 code (2.6.x kernels)
Auke Kok wrote: Amit Arora wrote: On Wed, 2006-05-31 at 16:30, Auke Kok wrote: On Wed, 31 May 2006 14:31:05 +0530, Amit K Arora [EMAIL PROTECTED] wrote: Should these DPRINTKs be removed from the 2.6.x e1000 code as well ? they already are. the patch was merged in 7.0.38-k2 or so which is over a month ago. I do not think these DPRINTKs have been removed from the latest code. Or, they did get removed at some point of time, but somehow again got added. I checked in 2.16.17-rc4 kernel, and also in the following versions of e1000 codebase (pulled from git://lost.foo-projects.org/~ahkok/git/netdev-2.6): e1000-7.0.38-k1, -k2 ... -k5 e1000-7.0.41 All of the above versions have the concerned DPRINTKs in e1000_suspend() and other routines. Please check once and let me know if I am missing something. Thanks! git-show d0e027db7861ef03de0ac08494a9a61984d8f8b0 it's really in there - please use jgarzik's netdev#upstream branch. Not sure if it already made it to 2.16.17-rc5, but I don't think this made it into 2.16.17-rc4, so that is where you may be missing it. I'm in need of coffee - these changes got queued for 2.6.18. They're in jgarziks netdev-2.6.git, but not anywhere in 2.6.17rcX Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[FIX] e1000: fix irq sharing when running ethtool test
New code added in 2.6.17 caused setup_irq to print a warning when
running ethtool -t eth0 offline.
This test marks the request_irq call made by this test as a probe to
see if the interrupt is shared or not.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
Jeff,
Because upstream and upstream-fixes have a whitespace conflict in them, I've
prepared two separate git branches to pull from so that a subsequent pull or
merge from upstream-fixes into upstream doesn't resolve into a conflict:
please pull from our git-server:
into upstream:
git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
into upstream-fixes:
git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes
Cheers,
Auke
---
e1000_ethtool.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
e1000: fix ethtool test irq alloc as probe
New code added in 2.6.17 caused setup_irq to print a warning when
running ethtool -t eth0 offline.
This test marks the request_irq call made by this test as a probe
to see if the interrupt is shared or not.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
diff --git a/drivers/net/e1000/e1000_ethtool.c b/drivers/net/e1000/e1000_ethtool.c
index ea3..d1c705b 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -870,13 +870,16 @@ e1000_intr_test(struct e1000_adapter *ad
*data = 0;
/* Hook up test interrupt handler just for this test */
- if (!request_irq(irq, e1000_test_intr, 0, netdev-name, netdev)) {
+ if (!request_irq(irq, e1000_test_intr, SA_PROBEIRQ, netdev-name,
+ netdev)) {
shared_int = FALSE;
} else if (request_irq(irq, e1000_test_intr, SA_SHIRQ,
netdev-name, netdev)){
*data = 1;
return -1;
}
+ DPRINTK(PROBE,INFO, testing %s interrupt\n,
+ (shared_int ? shared : unshared));
/* Disable all the interrupts */
E1000_WRITE_REG(adapter-hw, IMC, 0x);
Re: [FIX] e1000: fix irq sharing when running ethtool test
Jeff Garzik wrote: On Fri, Jun 02, 2006 at 03:19:47PM -0700, Auke Kok wrote: Because upstream and upstream-fixes have a whitespace conflict in them, I've prepared two separate git branches to pull from so that a subsequent pull or merge from upstream-fixes into upstream doesn't resolve into a conflict: That won't work, because it creates duplicate changesets in the history. I'll pull the upstream-fixes version, and then merge into #upstream. thanks, I wish I had thought of that first! Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] e1000: fix netpoll with NAPI
Neil Horman wrote: On Tue, Jun 06, 2006 at 09:39:25AM -0700, Mitch Williams wrote: On Tue, 2006-06-06 at 09:52 -0400, Neil Horman wrote: [snip] However, just for the sake of correctness (and paranoia), I'll whip up another patch that does this check. Thanks for the quick feedback! Regards Neil Jeff, please do not commit this patch. Jeff, I've popped the patch off from our gitserver, so you can pull the two outstanding patches while we revamp this one. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] e1000: fix netpoll with NAPI
Jeff Moyer wrote: == Regarding Re: [PATCH 1/2] e1000: fix netpoll with NAPI; Auke Kok [EMAIL PROTECTED] adds: auke-jan.h.kok Neil Horman wrote: On Tue, Jun 06, 2006 at 09:39:25AM -0700, Mitch Williams wrote: On Tue, 2006-06-06 at 09:52 -0400, Neil Horman wrote: auke-jan.h.kok [snip] However, just for the sake of correctness (and paranoia), I'll whip up another patch that does this check. Thanks for the quick feedback! Regards Neil Jeff, please do not commit this patch. auke-jan.h.kok Jeff, auke-jan.h.kok I've popped the patch off from our gitserver, so you can pull the two auke-jan.h.kok outstanding patches while we revamp this one. Would you please send patches to this list? I'd certainly like to review them. I don't think the problem needs solving in the e1000 driver. I think it is an issue that should be handled properly by netpoll. ??? that message was directed to Jeff Garzik, perhaps that was too confusing. They were sent here in the first place: http://marc.theaimsgroup.com/?l=linux-netdevm=114954878711789w=2 Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] Make Intel e1000 driver legacy I/O port free
Kenji Kaneshige wrote:
This patch makes Intel e1000 driver legacy I/O port free.
Signed-off-by: Kenji Kaneshige [EMAIL PROTECTED]
(adding netdev and the other e1000 maintainers to cc:)
without sending this to any of the listed e1000 maintainers *and* not even
including netdev???
I'm going to take a look at it first, and have some other colleagues look at
this and the impact, which is unclear to me at the moment. Please don't commit
this like this.
Auke
---
drivers/net/e1000/e1000.h |6 +
drivers/net/e1000/e1000_main.c | 130 ++---
2 files changed, 75 insertions(+), 61 deletions(-)
Index: linux-2.6.17-rc6/drivers/net/e1000/e1000.h
===
--- linux-2.6.17-rc6.orig/drivers/net/e1000/e1000.h 2006-06-06
21:39:11.0 +0900
+++ linux-2.6.17-rc6/drivers/net/e1000/e1000.h 2006-06-06 21:56:41.0
+0900
@@ -77,8 +77,9 @@
#define BAR_1 1
#define BAR_5 5
-#define INTEL_E1000_ETHERNET_DEVICE(device_id) {\
- PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
+#define E1000_NO_IOPORT(1 0)
+#define INTEL_E1000_ETHERNET_DEVICE(device_id, flags) {\
+ PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id), .driver_data = flags}
struct e1000_adapter;
@@ -338,6 +339,7 @@
#ifdef NETIF_F_TSO
boolean_t tso_force;
#endif
+ int bars; /* BARs to be enabled */
};
Index: linux-2.6.17-rc6/drivers/net/e1000/e1000_main.c
===
--- linux-2.6.17-rc6.orig/drivers/net/e1000/e1000_main.c2006-06-06
21:39:11.0 +0900
+++ linux-2.6.17-rc6/drivers/net/e1000/e1000_main.c 2006-06-06
21:56:41.0 +0900
@@ -86,54 +86,54 @@
* {PCI_DEVICE(PCI_VENDOR_ID_INTEL, device_id)}
*/
static struct pci_device_id e1000_pci_tbl[] = {
- INTEL_E1000_ETHERNET_DEVICE(0x1000),
- INTEL_E1000_ETHERNET_DEVICE(0x1001),
- INTEL_E1000_ETHERNET_DEVICE(0x1004),
- INTEL_E1000_ETHERNET_DEVICE(0x1008),
- INTEL_E1000_ETHERNET_DEVICE(0x1009),
- INTEL_E1000_ETHERNET_DEVICE(0x100C),
- INTEL_E1000_ETHERNET_DEVICE(0x100D),
- INTEL_E1000_ETHERNET_DEVICE(0x100E),
- INTEL_E1000_ETHERNET_DEVICE(0x100F),
- INTEL_E1000_ETHERNET_DEVICE(0x1010),
- INTEL_E1000_ETHERNET_DEVICE(0x1011),
- INTEL_E1000_ETHERNET_DEVICE(0x1012),
- INTEL_E1000_ETHERNET_DEVICE(0x1013),
- INTEL_E1000_ETHERNET_DEVICE(0x1014),
- INTEL_E1000_ETHERNET_DEVICE(0x1015),
- INTEL_E1000_ETHERNET_DEVICE(0x1016),
- INTEL_E1000_ETHERNET_DEVICE(0x1017),
- INTEL_E1000_ETHERNET_DEVICE(0x1018),
- INTEL_E1000_ETHERNET_DEVICE(0x1019),
- INTEL_E1000_ETHERNET_DEVICE(0x101A),
- INTEL_E1000_ETHERNET_DEVICE(0x101D),
- INTEL_E1000_ETHERNET_DEVICE(0x101E),
- INTEL_E1000_ETHERNET_DEVICE(0x1026),
- INTEL_E1000_ETHERNET_DEVICE(0x1027),
- INTEL_E1000_ETHERNET_DEVICE(0x1028),
- INTEL_E1000_ETHERNET_DEVICE(0x105E),
- INTEL_E1000_ETHERNET_DEVICE(0x105F),
- INTEL_E1000_ETHERNET_DEVICE(0x1060),
- INTEL_E1000_ETHERNET_DEVICE(0x1075),
- INTEL_E1000_ETHERNET_DEVICE(0x1076),
- INTEL_E1000_ETHERNET_DEVICE(0x1077),
- INTEL_E1000_ETHERNET_DEVICE(0x1078),
- INTEL_E1000_ETHERNET_DEVICE(0x1079),
- INTEL_E1000_ETHERNET_DEVICE(0x107A),
- INTEL_E1000_ETHERNET_DEVICE(0x107B),
- INTEL_E1000_ETHERNET_DEVICE(0x107C),
- INTEL_E1000_ETHERNET_DEVICE(0x107D),
- INTEL_E1000_ETHERNET_DEVICE(0x107E),
- INTEL_E1000_ETHERNET_DEVICE(0x107F),
- INTEL_E1000_ETHERNET_DEVICE(0x108A),
- INTEL_E1000_ETHERNET_DEVICE(0x108B),
- INTEL_E1000_ETHERNET_DEVICE(0x108C),
- INTEL_E1000_ETHERNET_DEVICE(0x1096),
- INTEL_E1000_ETHERNET_DEVICE(0x1098),
- INTEL_E1000_ETHERNET_DEVICE(0x1099),
- INTEL_E1000_ETHERNET_DEVICE(0x109A),
- INTEL_E1000_ETHERNET_DEVICE(0x10B5),
- INTEL_E1000_ETHERNET_DEVICE(0x10B9),
+ INTEL_E1000_ETHERNET_DEVICE(0x1000, E1000_NO_IOPORT),
+ INTEL_E1000_ETHERNET_DEVICE(0x1001, E1000_NO_IOPORT),
+ INTEL_E1000_ETHERNET_DEVICE(0x1004, E1000_NO_IOPORT),
+ INTEL_E1000_ETHERNET_DEVICE(0x1008, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x1009, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x100C, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x100D, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x100E, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x100F, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x1010, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x1011, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x1012, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x1013, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x1014, E1000_NO_IOPORT),
+ INTEL_E1000_ETHERNET_DEVICE(0x1015, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x1016, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x1017, 0),
+ INTEL_E1000_ETHERNET_DEVICE(0x1018, 0),
+
Re: [PATCH 3/4] Make Intel e1000 driver legacy I/O port free
Kenji Kaneshige wrote: Auke Kok wrote: Kenji Kaneshige wrote: This patch makes Intel e1000 driver legacy I/O port free. Signed-off-by: Kenji Kaneshige [EMAIL PROTECTED] (adding netdev and the other e1000 maintainers to cc:) without sending this to any of the listed e1000 maintainers *and* not even including netdev??? I'm sorry about that. I also didn't see that you were sending this to Greg-KH. I think I got thrown off by that as I wasn't following lkml until yesterday in the first place. I'll toss the patches around over here and see what comes up. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] e1000: fix netpoll with NAPI
Matt Mackall wrote:
On Wed, Jun 07, 2006 at 11:05:22AM -0400, Neil Horman wrote:
Matt, any ideas on this?
Not at the moment.
how about this for a solution? It doesn't make netpoll any more robust, but I
think in the interests of efficiency it would be fair to require that, when
netpolled, a driver must receive frames on the same net device for which it was
polled. With this patch we detect that condition and handle it accordingly in
e1000_intr. This eliminates the need for us to call the clean_rx method from
the poll_controller when napi is configured, instead allowing the poll method to
be called from napi_poll, as the netpoll model currently does. This fixes the
netdump regression, and eliminates the layering violation and the potential race
that we've been discussing. I've just tested it with netdump here and it works
quite well.
Thoughts appreciated.
This looks pretty reasonable, mostly from the perspective that it
doesn't put any further ugliness in netpoll. We might want to add a
comment somewhere in netpoll of the new rule we're now observing.
I'll let the e1000 guys comment on the particulars of the driver change.
Hi,
we're not too happy with this as it puts a branch right in the regular receive
path. We haven't ran the numbers on it yet but it is likely that this will
lower performance significantly during normal receives for something that is
not common use.
Attached below a (revised) patch that adds proper locking around the rx_clean
to prevent the race.
Cheers,
Auke
---
e1000: fix netpoll with NAPI
This fixes netpoll when using NAPI, and protects against a rare race condition
in the netpoll routine, while staying out of our ways from the normal hotpath.
Signed-off-by: Mitch Williams [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
e1000_main.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index bd709e5..876251c 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -4584,10 +4584,25 @@ static void
e1000_netpoll(struct net_device *netdev)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
+#ifdef CONFIG_E1000_NAPI
+ int budget = 0;
+
+ disable_irq(adapter-pdev-irq);
+ if (likely(netif_rx_schedule_prep(adapter-polling_netdev[0]))) {
+ if (spin_trylock(adapter-tx_queue_lock)) {
+ e1000_clean_tx_irq(adapter, adapter-tx_ring[0]);
+ spin_unlock(adapter-tx_queue_lock);
+ }
+ adapter-clean_rx(adapter, adapter-rx_ring,
+budget, netdev-weight);
+ clear_bit(__LINK_STATE_RX_SCHED,
+adapter-polling_netdev[0].state);
+ }
+#else
+
disable_irq(adapter-pdev-irq);
e1000_intr(adapter-pdev-irq, netdev, NULL);
e1000_clean_tx_irq(adapter, adapter-tx_ring);
-#ifndef CONFIG_E1000_NAPI
adapter-clean_rx(adapter, adapter-rx_ring);
#endif
enable_irq(adapter-pdev-irq);
[PATCH RESEND] e100/e1000: fixes and pci error recovery
Jeff, This is a resend of several earlier sent (and Acked) patches for e100 and e1000. They are available on our git server and contain: in branch upstream-fixes: [1] e1000: fix irq sharing when running ethtool test [2] e1000: remove risky prefetch on next_skb-data against netdev-2.6#upstream-fixes e82b0f2cc21be905e504573483fa9542b15df96f [ please note that patch 2 will need manual merging into #upstream ] in branch upstream: [3] e100: add PCI Error Recovery [4] e1000: add PCI Error Recovery against netdev-2.6#upstream 983f27d37d4fc72c252835cb2ee3103b360735a6 Please pull: into #upstream-fixes: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes into #upstream: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream Cheers, Auke Refs [1] http://marc.theaimsgroup.com/?l=linux-netdevm=114928689932374w=2 [2] http://marc.theaimsgroup.com/?l=linux-netdevm=114954878609885w=2 [3] http://marc.theaimsgroup.com/?l=linux-netdevm=114436228823926w=2 [4] http://marc.theaimsgroup.com/?l=linux-pcim=114325705604534w=2 - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[DOC] update bonding documentation with sysfs
Jeff, Attached patch is pushed on top of #upstream on our git server also containing the resent patches earlier today. Please pull: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream Cheers, Auke --- [DOC] Update bonding documentation with sysfs info Bonding documentation needed an update to include sysfs specific information. This patch adds information on how to change bonding parameters at runtime using the sysfs interface. Signed-off-by: Mitch Williams [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- bonding.txt | 323 ++-- 1 file changed, 229 insertions(+), 94 deletions(-) --- [DOC] Update bonding documentation with sysfs info Bonding documentation needed an update to include sysfs specific information. This patch adds information on how to change bonding parameters at runtime using the sysfs interface. Signed-off-by: Mitch Williams [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- bonding.txt | 323 ++-- 1 file changed, 229 insertions(+), 94 deletions(-) --- diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 8d8b4e5..afac780 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -1,7 +1,7 @@ Linux Ethernet Bonding Driver HOWTO - Latest update: 21 June 2005 + Latest update: 24 April 2006 Initial release : Thomas Davis tadavis at lbl.gov Corrections, HA extensions : 2000/10/03-15 : @@ -12,6 +12,8 @@ Corrections, HA extensions : 2000/10/03- - Jay Vosburgh fubar at us dot ibm dot com Reorganized and updated Feb 2005 by Jay Vosburgh +Added Sysfs information: 2006/04/24 + - Mitch Williams mitch.a.williams at intel.com Introduction @@ -38,61 +40,62 @@ Table of Contents 2. Bonding Driver Options 3. Configuring Bonding Devices -3.1 Configuration with sysconfig support -3.1.1 Using DHCP with sysconfig -3.1.2 Configuring Multiple Bonds with sysconfig -3.2 Configuration with initscripts support -3.2.1 Using DHCP with initscripts -3.2.2 Configuring Multiple Bonds with initscripts -3.3 Configuring Bonding Manually +3.1 Configuration with Sysconfig Support +3.1.1 Using DHCP with Sysconfig +3.1.2 Configuring Multiple Bonds with Sysconfig +3.2 Configuration with Initscripts Support +3.2.1 Using DHCP with Initscripts +3.2.2 Configuring Multiple Bonds with Initscripts +3.3 Configuring Bonding Manually with Ifenslave 3.3.1 Configuring Multiple Bonds Manually +3.4 Configuring Bonding Manually via Sysfs -5. Querying Bonding Configuration -5.1 Bonding Configuration -5.2 Network Configuration +4. Querying Bonding Configuration +4.1 Bonding Configuration +4.2 Network Configuration -6. Switch Configuration +5. Switch Configuration -7. 802.1q VLAN Support +6. 802.1q VLAN Support -8. Link Monitoring -8.1 ARP Monitor Operation -8.2 Configuring Multiple ARP Targets -8.3 MII Monitor Operation +7. Link Monitoring +7.1 ARP Monitor Operation +7.2 Configuring Multiple ARP Targets +7.3 MII Monitor Operation -9. Potential Trouble Sources -9.1 Adventures in Routing -9.2 Ethernet Device Renaming -9.3 Painfully Slow Or No Failed Link Detection By Miimon +8. Potential Trouble Sources +8.1 Adventures in Routing +8.2 Ethernet Device Renaming +8.3 Painfully Slow Or No Failed Link Detection By Miimon -10. SNMP agents +9. SNMP agents -11. Promiscuous mode +10. Promiscuous mode -12. Configuring Bonding for High Availability -12.1 High Availability in a Single Switch Topology -12.2 High Availability in a Multiple Switch Topology -12.2.1 HA Bonding Mode Selection for Multiple Switch Topology -12.2.2 HA Link Monitoring for Multiple Switch Topology +11. Configuring Bonding for High Availability +11.1 High Availability in a Single Switch Topology +11.2 High Availability in a Multiple Switch Topology +11.2.1 HA Bonding Mode Selection for Multiple Switch Topology +11.2.2 HA Link Monitoring for Multiple Switch Topology -13. Configuring Bonding for Maximum Throughput -13.1 Maximum Throughput in a Single Switch Topology -13.1.1 MT Bonding Mode Selection for Single Switch Topology -13.1.2 MT Link Monitoring for Single Switch Topology -13.2 Maximum Throughput in a Multiple Switch Topology -13.2.1 MT Bonding Mode Selection for Multiple Switch Topology -13.2.2 MT Link Monitoring for Multiple Switch Topology +12. Configuring Bonding for Maximum Throughput +12.1 Maximum Throughput in a Single Switch Topology +12.1.1 MT Bonding Mode Selection for Single Switch Topology +12.1.2 MT Link Monitoring for Single Switch Topology +12.2 Maximum Throughput in a Multiple Switch Topology +12.2.1 MT Bonding Mode Selection for Multiple Switch Topology +12.2.2 MT Link Monitoring for Multiple Switch Topology -14. Switch Behavior Issues -14.1 Link Establishment and Failover Delays -14.2 Duplicated Incoming Packets +13. Switch Behavior
Re: [patch 4/8] e1000: prevent statistics from getting garbled during reset
Ack,
Jeff, please pull this patch from:
git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
which is against netdev-2.6#upstream cac925a4aab1b7233d3beb591f53498816058a08
Cheers,
Auke
---
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Acked-by: Auke Kok [EMAIL PROTECTED]
---
e1000_main.c |8 +++-
1 files changed, 7 insertions(+), 1 deletion(-)
[EMAIL PROTECTED] wrote:
From: Linas Vepstas [EMAIL PROTECTED]
If a PCI bus error/fault triggers a PCI bus reset, attempts to get the
ethernet packet count statistics from the hardware will fail, returning
garbage data upstream. This patch skips statistics data collection if the
PCI device is not on the bus.
[snip]
e1000: prevent statistics from garbling during bus resets
If a PCI bus error/fault triggers a PCI bus reset, attempts to get
the ethernet packet count statistics from the hardware will fail,
returning garbage data upstream. This patch skips statistics data
collection if the PCI device is not on the bus.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Cc: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Acked-by: Auke Kok [EMAIL PROTECTED]
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 56c7492..a373ccb 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3045,14 +3045,20 @@ void
e1000_update_stats(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = adapter-hw;
+ struct pci_dev *pdev = adapter-pdev;
unsigned long flags;
uint16_t phy_tmp;
#define PHY_IDLE_ERROR_COUNT_MASK 0x00FF
- /* Prevent stats update while adapter is being reset */
+ /*
+ * Prevent stats update while adapter is being reset, or if the pci
+ * connection is down.
+ */
if (adapter-link_speed == 0)
return;
+ if (pdev-error_state pdev-error_state != pci_channel_io_normal)
+ return;
spin_lock_irqsave(adapter-stats_lock, flags);
Re: [patch] e100 statistic value rx_bytes error
Wei Dong wrote:
Hi All:
When I test linux kernel(2.6.9-16), I found that maybe there is a bug
in e100 driver. See function e100_rx_indicate() at line 1847:
nic-net_stats.rx_bytes += actual_size;
Here, actual_size is the actual size of an ethernent frame sans FCS.And
the e100 driver gets it from skb. Because rx_bytes is a statistc value
for a NIC, I think rx_bytes should include the FCS(4 bytes).
The following is the patch for the function in e100.c
This is definately not an issue, and I'm not for changing this: It always was
like this in the first place. It's done for many drivers like this anyway,
mostly those without real hardware counters do it this way anyway (I count
half a dozen or so on first glance).
On top of that we would be changing statistics numbers after x years of e100
driver. I'm sure everyone doing real performance work will frown upon this.
Next it's unlikely that every driver (or worse, every nic in hardware)
accounts for FCS in the rx_bytes count. It really wouldn't surprise me if a
driver (or chip) got this wrong here or there.
Bottom line is that for e100, it's well known and easily seeable that e100 is
counting skb sizes. That's consistent and I think we should keep it that way.
Auke
PS please cc the driver maintainers when you post patches to a specific driver.
diff -ruN old/drivers/net/e100.c new/drivers/net/e100.c
--- old/drivers/net/e100.c 2006-03-20 13:53:29.0 +0800
+++ new/drivers/net/e100.c 2006-06-15 11:16:04.0 +0800
@@ -1844,7 +1844,8 @@
dev_kfree_skb_any(skb);
} else {
nic-net_stats.rx_packets++;
- nic-net_stats.rx_bytes += actual_size;
+ /* Don't forget FCS */
+ nic-net_stats.rx_bytes += actual_size + 4;
nic-netdev-last_rx = jiffies;
netif_receive_skb(skb);
if(work_done)
BR.
Weidong
Signed-off-by: Weidong [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote: A watchdog timeout panic occurred in e1000 driver (7.2.9-NAPI). where's the panic message ? Please CC the maintainers of the driver at all times. Our e-mail addresses are widely visible everywhere. If e1000_watchdog is called when processing ioctl from ethtool, the system could stop inside e1000_watchdog interrupt handler for about 16 seconds and the system panicked as a result of a watchdog timeout. This problem only occurs on a server using ethernet controller inside 631xESB/632xESB, and NMI watchdog enabled. why only this system? have you seen/tried it on other machines? Environment: OS : RHEL4U3(x86_64) kernel : 2.6.9-34.ELsmp e1000 : 7.2.9-NAPI Ethernet controller : Intel Corporation 631x/632xESB DPT LAN Controller Copper (rev 01) Watchdog timer should be enabled with a timeout period of less than 16 seconds. Steps to reproduce: Please apply the attached patch (ethtool.patch) to ethtool (VERSION 5) source code. Run make, and rename the freshly built ethtool as gsetloop. Put gsetloop and the attached shell script (gloop.sh) in the same directory, and execute gloop.sh. The problem should occur within about 5 minutes. Cause: The problem occurs in the following steps. - ioctl is executed in ethtool. - e1000_read_phy_reg() is called from ioctl to read the value from phy register. - e1000_get_hw_eeprom_semaphore() is called from e1000_read_phy_reg() to acquire a semaphore. - E1000_SWSM_SWESMBI bit that is FW semaphore bit is set in e1000_get_hw_eeprom_semaphore(). - When this bit was set, E1000_SWSM_SMBI bit that is driver's semaphore bit is also set. - e1000_watchdog() of interrupt handler is executed before the E1000_SWSM_SMBI bit is unset. - e1000_read_phy_reg() is called from e1000_watchdog() to read the value from phy register. - e1000_get_software_semaphore() is called from e1000_watchdog to confirm whether interruption handler can acquire a semaphore. This function confirms whether E1000_SWSM_SMBI bit is being set. - Therefore the process does loop for hw-eeprom.word_size + 1 msec in e1000_get_software_semaphore(). The value of hw-eeprom.word_size + 1 was 16385 on my system. In other words it loops for 16.385 sec in e1000_get_software_semaphore(). If NMI watchdog is enabled, the system will panic by NMI watchdog within this loop. Fix: In kernels before 2.6.17, the e1000_watchdog() interrupt handler schedules e1000_watchdog_task(). The semaphore is acquired within this task, after ioctl processing for ethtool is finished, and this problem is avoided. e1000_watchdog_task() was remove by the following patch. http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2db10a081c5c1082d58809a1bcf1a6073f4db160 e1000: rework driver hardware reset locking After studying the driver mac reset code it was found that there were multiple race conditions possible to reset the unit twice or bring it e1000_up() double. This fixes all occurences where the driver needs to reset the mac. We also remove irq requesting/releasing into _open and _close so that while the device is _up we will never touch the irq's. This fixes the double free irq bug that people saw. To make sure that the watchdog task doesn't cause another race we let it run as a non-scheduled task. I'm not sure whether there was any reason to actively remove e1000_watchdog_task(). I think that removing e1000_watchdog_task() was a mistake, and it should be brought back in. Reverting this could would not be a fix, but only a workaround that leaves the problem still in the code, and as such not progress in the right direction. I find this report extremely edgy, but I'll look into the fact that the driver attempts to sleep for 16384 + 1 msec, which seems overly long :) As a side note, most other e1000 NIC's use hardcoded word_size numbers, but esb2 systems read it from a register/eeprom. Can you send me the output of `ethtool -e ethX` ? off-list is OK, it might be large. Thanks, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote: Hi, Thank you for your comment. A watchdog timeout panic occurred in e1000 driver (7.2.9-NAPI). where's the panic message ? attached the panic message (e1000_panic). [...] This problem only occurs on a server using ethernet controller inside 631xESB/632xESB, and NMI watchdog enabled. why only this system? have you seen/tried it on other machines? This problem is caused by e1000_get_software_semaphore() being called from within the interrupt handler, while the interrupted code is still holding this semaphore. e1000_get_software_semaphore() is called from e1000_get_hw_eeprom_semaphore() only when hw-mac_type is e1000_80003es2lan. This condition is true only for MACs inside 631xESB/632xESB. When this problem happens e1000_get_software_semaphore() will wait for 16 seconds (inside the interrupt handler) before it fails, thus causing the watchdog timeout. I haven't actually tried it on other machines, but theoretically, it will only happen on MAC inside 631xESB/632xESB chip set. [...] Reverting this could would not be a fix, but only a workaround that leaves the problem still in the code, and as such not progress in the right direction. I find this report extremely edgy, but I'll look into the fact that the driver attempts to sleep for 16384 + 1 msec, which seems overly long :) As a side note, most other e1000 NIC's use hardcoded word_size numbers, but esb2 systems read it from a register/eeprom. Can you send me the output of `ethtool -e ethX` ? off-list is OK, it might be large. attached is the output of ethtool -e ethX (eeprom_eth0). thanks. This panic report falls in the category how hard can I break my system as root. Explicitly abusing the system performing restricted calls depletes resources and harasses the sw lock (in this case). The reason that the driver attempts to wait that long is that in the case of ESB2 systems, the SPI interface to the EEPROM can be slow, thus taking a long time to complete certain commands. We're looking into making this theoretical lock time shorter in the mean time, thanks for reporting this. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e100_shutdown: netif_poll_disable hang
Daniel Walker wrote: My machine annoyingly hangs while rebooting. I tracked it down to e100-fix-reboot-f-with-netconsole-enabled.patch in 2.6.18-rc2-mm2 I review the changes and it seemed to be calling netif_poll_disable one too many time. Once in e100_down(), and again in e100_shutdown(). The second one in e100_shutdown() caused the hang. So this patch removes it. Signed-Off-By: Daniel Walker [EMAIL PROTECTED] --- drivers/net/e100.c |1 - 1 files changed, 1 deletion(-) Index: linux-2.6.18/drivers/net/e100.c === --- linux-2.6.18.orig/drivers/net/e100.c +++ linux-2.6.18/drivers/net/e100.c @@ -2709,7 +2709,6 @@ static void e100_shutdown(struct pci_dev struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic-netdev); del_timer_sync(nic-watchdog); netif_carrier_off(nic-netdev); -- this won't help netconsole shutdown/reboot -f, probably locking it up again! NAK Also missing is the NAPI conditional, which I left out. Also missing is the same code for suspend. Here's a better approach, allowing both normal shutdown code path and reboot -f to disable polling. Cheers, Auke --- e100: disable polling only when up during suspend and shutdown Signed-off-by: Auke Kok auke-jan.h.kok Cc: Daniel Walker [EMAIL PROTECTED] Cc: Andrew Morton [EMAIL PROTECTED] --- drivers/net/e100.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) --- diff --git a/drivers/net/e100.c b/drivers/net/e100.c index d4a2572..815eb29 100644 --- a/drivers/net/e100.c +++ b/drivers/net/e100.c @@ -2719,7 +2719,10 @@ static int e100_suspend(struct pci_dev * struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic-netdev); +#ifdef CONFIG_E100_NAPI + if (netif_running(netdev)) + netif_poll_disable(nic-netdev); +#endif del_timer_sync(nic-watchdog); netif_carrier_off(nic-netdev); @@ -2763,7 +2766,10 @@ static void e100_shutdown(struct pci_dev struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic-netdev); +#ifdef CONFIG_E100_NAPI + if (netif_running(netdev)) + netif_poll_disable(nic-netdev); +#endif del_timer_sync(nic-watchdog); netif_carrier_off(nic-netdev); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e100_shutdown: netif_poll_disable hang
Auke Kok wrote: Daniel Walker wrote: My machine annoyingly hangs while rebooting. I tracked it down to e100-fix-reboot-f-with-netconsole-enabled.patch in 2.6.18-rc2-mm2 I review the changes and it seemed to be calling netif_poll_disable one too many time. Once in e100_down(), and again in e100_shutdown(). The second one in e100_shutdown() caused the hang. So this patch removes it. it doesn't even do harm to netif_poll_disable() twice as far as I can see, as it merely calls test_and_set_bit(), which will instantly succeed on the first attempt if the bit was already set. did this change actually fix it for you? I'm wondering if the netif_carrier_off might not be the culprit here... Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] e100_shutdown: netif_poll_disable hang
Damien Wyart wrote: My machine annoyingly hangs while rebooting. I tracked it down to e100-fix-reboot-f-with-netconsole-enabled.patch in 2.6.18-rc2-mm2 I review the changes and it seemed to be calling netif_poll_disable one too many time. Once in e100_down(), and again in e100_shutdown(). The second one in e100_shutdown() caused the hang. So this patch removes it. * Auke Kok [EMAIL PROTECTED] [061020 23:09]: it doesn't even do harm to netif_poll_disable() twice as far as I can see, as it merely calls test_and_set_bit(), which will instantly succeed on the first attempt if the bit was already set. did this change actually fix it for you? I'm wondering if the netif_carrier_off might not be the culprit here... I can confirm the proposed original change of D. Walker fixed the problem for me. I did not test the change you proposed as a followup. his change breaks something else (a reboot with netconsole, possibly suspend). Please give the latest version I sent a try. Daniel confirmed me that it works, but it's always nice to hear it from more people. Thanks Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] e100, e1000: Fixes for netdev-2.6#upstream-fixes
Jeff Garzik wrote: Kok, Auke wrote: Hi, The following fixes targeted to netdev-2.6#upstream-fixes are available through git: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes hrm. since another e100 fixes got applied, can you either (a) update the above URL for that change, or (b) provide separate e100 and e1000 pull urls? I dropped the e100 patch from the series, it now contains (at the above url) only the e1000 changes. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote: Hi, Thank you for your comment. This panic report falls in the category how hard can I break my system as root. Explicitly abusing the system performing restricted calls depletes resources and harasses the sw lock (in this case). The reason that the driver attempts to wait that long is that in the case of ESB2 systems, the SPI interface to the EEPROM can be slow, thus taking a long time to complete certain commands. This problem originally occurred in a very large cluster system using snmp for server management. About two servers panicked each day. The program I sent is to reproduce this problem in a very short time. It does occur under normal load when there is a lot of servers. hmm, not good - does your snmp daemon use ethtool excessively? That would certainly be painful to the driver (any driver!). Anyway as I said in the same e-mail, we're working on reducing the lock timeout to a reasonable time. This will unfortunately take some time, as we need to change some major components in the driver to make sure this doesn't happen. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
please pull from git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes
Auke Kok wrote: Jeff Garzik wrote: Kok, Auke wrote: Hi, The following fixes targeted to netdev-2.6#upstream-fixes are available through git: git pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes hrm. since another e100 fixes got applied, can you either (a) update the above URL for that change, or (b) provide separate e100 and e1000 pull urls? I dropped the e100 patch from the series, it now contains (at the above url) only the e1000 changes. okay, I've rebased the trees on the latest upstream-fixes and master from netdev-2.6, and on top of that added the latest e100 shutdown patch to it (see below). Jeff, Please pull from git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream-fixes in to your #upstream-fixes or #upstream-linus branch so that these fixes get into 2.6.19. Thanks. Auke --- e100: account for closed interface when shutting down From: Auke Kok [EMAIL PROTECTED] Account for the interface being closed before disabling polling on a device, to fix shutdown on some systems that explcitly close the netdevice before calling shutdown. Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e100.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/net/e100.c b/drivers/net/e100.c index a3a08a5..19ab344 100644 --- a/drivers/net/e100.c +++ b/drivers/net/e100.c @@ -2719,7 +2719,10 @@ static int e100_suspend(struct pci_dev * struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic-netdev); +#ifdef CONFIG_E100_NAPI + if (netif_running(netdev)) + netif_poll_disable(nic-netdev); +#endif del_timer_sync(nic-watchdog); netif_carrier_off(nic-netdev); @@ -2763,7 +2766,10 @@ static void e100_shutdown(struct pci_dev struct net_device *netdev = pci_get_drvdata(pdev); struct nic *nic = netdev_priv(netdev); - netif_poll_disable(nic-netdev); +#ifdef CONFIG_E100_NAPI + if (netif_running(netdev)) + netif_poll_disable(nic-netdev); +#endif del_timer_sync(nic-watchdog); netif_carrier_off(nic-netdev); - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100: Wait for PHY reset to complete?
Francois Romieu wrote: Anders Grafstrom [EMAIL PROTECTED] : [...] I'm thinking something like this patch. I do not have the spec for the max duration at hand but it makes sense. Can you: - decrease the duration of each sleep and increase the count of iterations - put the break on a line of its own - add a Signed-off-by: Foo Bar [EMAIL PROTECTED] line - Cc: [EMAIL PROTECTED] and Auke Kok [EMAIL PROTECTED] I'm already checking out specs, which, for 8255x devices, are available on http://e1000.sf.net/ . Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100: Wait for PHY reset to complete?
Auke Kok wrote: Francois Romieu wrote: Anders Grafstrom [EMAIL PROTECTED] : [...] I'm thinking something like this patch. I do not have the spec for the max duration at hand but it makes sense. Can you: - decrease the duration of each sleep and increase the count of iterations - put the break on a line of its own - add a Signed-off-by: Foo Bar [EMAIL PROTECTED] line - Cc: [EMAIL PROTECTED] and Auke Kok [EMAIL PROTECTED] I'm already checking out specs, which, for 8255x devices, are available on http://e1000.sf.net/ . okay, I don't think this is needed at all: Allthough the spec itself didn't talk about phy reset times, I've ran this patch with some debugging output on a few boxes and did some speed/duplex settings, and the PHY reset returned succesfull after the very first mdio_read, which is before any msleep(10) is executed. That is also expected behaviour. I think you might be confusing this with a MAC reset, which has a documented 10usec timeout (see 8255x developers manual). The driver already adheres to this by doing a 20usec delay after software/selective resets. which gets us back to the original problem: how did your driver end up in loopback mode? (and, how did you figure out that it did??). Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100: Wait for PHY reset to complete?
Anders Grafström wrote:
Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran this
patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is before
any msleep(10)
is executed. That is also expected behaviour.
I think you might be confusing this with a MAC reset, which has a
documented 10usec
timeout (see 8255x developers manual). The driver already adheres to this
by doing a
20usec delay after software/selective resets.
which gets us back to the original problem: how did your driver end up in
loopback mode?
(and, how did you figure out that it did??).
This is what the 2.4.33.3 driver does:
void
e100_phy_reset(struct e100_private *bdp)
{
u16 ctrl_reg;
ctrl_reg = BMCR_RESET;
e100_mdi_write(bdp, MII_BMCR, bdp-phy_addr, ctrl_reg);
/* ieee 802.3 : The reset process shall be completed */
/* within 0.5 seconds from the settting of PHY reset bit. */
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(HZ / 2);
}
And here
http://www.cs.helsinki.fi/linux/linux-kernel/2003-23/1245.html
I found this entry:
[EMAIL PROTECTED] (03/06/08 1.1218)
[e100] misc
...
* Add 1/2 second delay after PHY reset to allow link partner to
see and respond to reset, per IEEE 802.3.
I ran mii-diag when the LEDs went out and the register dump
said it was in loopback. It is somewhat difficult reproduce.
It seems to be timing dependent, something else has to occur
at the same time.
I must confess I have only seen it with the 2.6.13 kernel.
I have not been able to reproduce it with 2.6.18.
But I have found no change in the driver that would fix it so
I suspect the problem is still there.
I have tried adding debug output to see if I can read back the
RESET bit in set state, but then the problem refuses to show
so I don't think I can rule out an unfinished PHY reset.
theoretically, yes, the ieee spec PHY reset timeout is kind of silly: in no way do we
assume that we have re-negotiated link after 1/2 a second! Other code in the driver
should take care of that, and since it works I'll assume it does ;)
the mdio_read probably acts as a flush to the hardware too - masquerading problems, more
goodness. Perhaps we should do a single read in all cases and forget about the timeout
(is there an mdio_write_flush?)
Basically the timeout is wrong: a LINK reset is not a PHY reset. The PHY is back online
and ready to respond in (probably) a single clock cycle. The link can take up to 3
seconds in normal cases. Waiting for 1/2 a second does not fix anything there. Here's
where the 8255x (PHY part) spec abandons us: I don't read anything about PHY reset
timeouts in it.
Can you try to debug if your while () timeout loop is actually waiting for a significant
amount? something like adding a printk(KERN_ERR counted down to %d0 msec\n, counter);
after the entire while{} loop should show you if there is variation in the PHY reset
time needed for the PHY to be back online.
running mii-diag before the link comes back up might be causing the issue in the first
place, and certainly suggests a small race.
Have you tried to run the e100-sbit branch from jgarzik's netdev-2.6 tree? We're still
looking into merging this and I guess I should push it to -mm to have it receive some
testing
Cheers,
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote: Hi, Thank you for your comment. Anyway as I said in the same e-mail, we're working on reducing the lock timeout to a reasonable time. This will unfortunately take some time, as we need to change some major components in the driver to make sure this doesn't happen. How about the following approach? If acquiring semaphore fails inside the interrupt handler, acquiring semaphore is abandoned immediately without waiting for timeout. However, I don't know whether this method affects other processes. with the current hardware being accessed simultaneously from several users in the kernel, that would lead to large problems - the watchdog task accesses it every 2 seconds as it reads the PHY link status, so when one of those fails the driver would have no choice but to reset the entire device. This problem occurs because interrupt handler is executed while the interrupted code is still holding the semaphore. Acquiring the semaphore fails regardless of the timeout period. I think the watchdog task will fail trying to read the PHY link status, even if the lock timeout period has been reduced. correct, we're not looking into reducing the lock timeout but towards reducing the total lock time. Once we have reduced that to something acceptable, we can reduce the timout accordingly. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rewrite e100_phys_id
Jeff Garzik wrote: On Thu, Oct 26, 2006 at 01:11:55PM -0600, Matthew Wilcox wrote: The motivator for this was to fix the sparse warning: drivers/net/e100.c:2418:48: warning: cast truncates bits from constant value (83126e978d4fdf becomes 978d4fdf) drivers/net/e100.c:2419:37: warning: cast truncates bits from constant value (83126e978d4fdf becomes 978d4fdf) Initially, I tried a quick fix, but when it ran into difficulties, I looked at tg3.c to see how it does it. I liked their way better, so I rewrote e100.c to be similar. It shaves ~700 bytes off the size of the driver, and a few bytes off the size of struct nic, so I think it's a win all round. Tested on the internal interface of an HP Integrity rx2600. Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] Seems sane to me... I'll pick it up, if Auke doesn't... no objections, so I'll ACK it with the notion that I'm going to let our labs do some more testing on it with all the latest changes to it. Jeff, I will stack it on the patches I have for 2.6.20 and push those out before the weekend. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rewrite e100_phys_id
Matthew Wilcox wrote:
On Thu, Oct 26, 2006 at 01:04:32PM -0700, Auke Kok wrote:
no objections, so I'll ACK it with the notion that I'm going to let our
labs do some more testing on it with all the latest changes to it.
Thanks, Auke. Here's the equivalent patch for e1000. I don't have a
convenient machine to test it on, but it reduces the size of the driver
by 1.5k.
this is a bit (!) more complex than e100, so I'm going to take a bit of time to review
this patch.
thanks,
Auke
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 7ecce43..1e22da6 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -257,9 +257,6 @@ #endif
struct work_struct reset_task;
uint8_t fc_autoneg;
- struct timer_list blink_timer;
- unsigned long led_status;
-
/* TX */
struct e1000_tx_ring *tx_ring; /* One per active queue */
unsigned long tx_queue_len;
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index 773821e..620afa5 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -1819,61 +1819,15 @@ e1000_set_wol(struct net_device *netdev,
return 0;
}
-/* toggle LED 4 times per second = 2 blinks per second */
-#define E1000_ID_INTERVAL (HZ/4)
-
-/* bit defines for adapter-led_status */
-#define E1000_LED_ON 0
-
-static void
-e1000_led_blink_callback(unsigned long data)
-{
- struct e1000_adapter *adapter = (struct e1000_adapter *) data;
-
- if (test_and_change_bit(E1000_LED_ON, adapter-led_status))
- e1000_led_off(adapter-hw);
- else
- e1000_led_on(adapter-hw);
-
- mod_timer(adapter-blink_timer, jiffies + E1000_ID_INTERVAL);
-}
-
static int
e1000_phys_id(struct net_device *netdev, uint32_t data)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
- if (!data || data (uint32_t)(MAX_SCHEDULE_TIMEOUT / HZ))
- data = (uint32_t)(MAX_SCHEDULE_TIMEOUT / HZ);
-
- if (adapter-hw.mac_type e1000_82571) {
- if (!adapter-blink_timer.function) {
- init_timer(adapter-blink_timer);
- adapter-blink_timer.function =
e1000_led_blink_callback;
- adapter-blink_timer.data = (unsigned long) adapter;
- }
- e1000_setup_led(adapter-hw);
- mod_timer(adapter-blink_timer, jiffies);
- msleep_interruptible(data * 1000);
- del_timer_sync(adapter-blink_timer);
- } else if (adapter-hw.phy_type == e1000_phy_ife) {
- if (!adapter-blink_timer.function) {
- init_timer(adapter-blink_timer);
- adapter-blink_timer.function =
e1000_led_blink_callback;
- adapter-blink_timer.data = (unsigned long) adapter;
- }
- mod_timer(adapter-blink_timer, jiffies);
- msleep_interruptible(data * 1000);
- del_timer_sync(adapter-blink_timer);
- e1000_write_phy_reg((adapter-hw),
IFE_PHY_SPECIAL_CONTROL_LED, 0);
- } else {
- e1000_blink_led_start(adapter-hw);
- msleep_interruptible(data * 1000);
- }
+ if (data == 0)
+ data = 2;
- e1000_led_off(adapter-hw);
- clear_bit(E1000_LED_ON, adapter-led_status);
- e1000_cleanup_led(adapter-hw);
+ e1000_blink_led(adapter-hw, data);
return 0;
}
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index 65077f3..db5e999 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -6071,7 +6071,7 @@ e1000_id_led_init(struct e1000_hw * hw)
*
* hw - Struct containing variables accessed by shared code
*/
-int32_t
+static int32_t
e1000_setup_led(struct e1000_hw *hw)
{
uint32_t ledctl;
@@ -6123,50 +6123,11 @@ e1000_setup_led(struct e1000_hw *hw)
/**
- * Used on 82571 and later Si that has LED blink bits.
- * Callers must use their own timer and should have already called
- * e1000_id_led_init()
- * Call e1000_cleanup led() to stop blinking
- *
- * hw - Struct containing variables accessed by shared code
- */
-int32_t
-e1000_blink_led_start(struct e1000_hw *hw)
-{
-int16_t i;
-uint32_t ledctl_blink = 0;
-
-DEBUGFUNC(e1000_id_led_blink_on);
-
-if (hw-mac_type e1000_82571) {
-/* Nothing to do */
-return E1000_SUCCESS;
-}
-if (hw-media_type == e1000_media_type_fiber) {
-/* always blink LED0 for PCI-E fiber */
-ledctl_blink = E1000_LEDCTL_LED0_BLINK |
- (E1000_LEDCTL_MODE_LED_ON
E1000_LEDCTL_LED0_MODE_SHIFT);
-} else
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote: Hi, Thank you for your comment. Anyway as I said in the same e-mail, we're working on reducing the lock timeout to a reasonable time. This will unfortunately take some time, as we need to change some major components in the driver to make sure this doesn't happen. How about the following approach? If acquiring semaphore fails inside the interrupt handler, acquiring semaphore is abandoned immediately without waiting for timeout. However, I don't know whether this method affects other processes. with the current hardware being accessed simultaneously from several users in the kernel, that would lead to large problems - the watchdog task accesses it every 2 seconds as it reads the PHY link status, so when one of those fails the driver would have no choice but to reset the entire device. This problem occurs because interrupt handler is executed while the interrupted code is still holding the semaphore. Acquiring the semaphore fails regardless of the timeout period. I think the watchdog task will fail trying to read the PHY link status, even if the lock timeout period has been reduced. correct, we're not looking into reducing the lock timeout but towards reducing the total lock time. Once we have reduced that to something acceptable, we can reduce the timout accordingly. Even if the total lock time can be reduced, it's possible that interrupt handler is executed while the interrupted code is still holding the semaphore. I think your method only decrease the frequency of this problem. Why does reducing the lock time solve this problem? there are several problems here that need addressing. It's not acceptable for our driver to wait up to 15 seconds, and we can (presumably) reduce it to milliseconds, so that would help a lot. We should in no case at all hold it for any period longer than (give or take) half a second, so working towards that is a very good step in the right direction. Adding the timer task back may also help, as we are no longer trying to aqcuire the sw_fw_semaphore in interrupt context, but we removed it for a reason, and I need to dig up what reason this exactly was before we can revert it. Jesse might know, so I'll talk to him. But this will not fix the fact that the semaphore is held for a long time :) so, this needs two fixes. much to do. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100: Wait for PHY reset to complete?
Auke Kok wrote:
Anders Grafström wrote:
Auke Kok wrote:
Allthough the spec itself didn't talk about phy reset times, I've ran
this
patch with
some debugging output on a few boxes and did some speed/duplex settings,
and the PHY
reset returned succesfull after the very first mdio_read, which is
before
any msleep(10)
is executed. That is also expected behaviour.
I think you might be confusing this with a MAC reset, which has a
documented 10usec
timeout (see 8255x developers manual). The driver already adheres to
this
by doing a
20usec delay after software/selective resets.
which gets us back to the original problem: how did your driver end
up in
loopback mode?
(and, how did you figure out that it did??).
This is what the 2.4.33.3 driver does:
void
e100_phy_reset(struct e100_private *bdp)
{
u16 ctrl_reg;
ctrl_reg = BMCR_RESET;
e100_mdi_write(bdp, MII_BMCR, bdp-phy_addr, ctrl_reg);
/* ieee 802.3 : The reset process shall be completed */
/* within 0.5 seconds from the settting of PHY reset bit. */
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(HZ / 2);
}
And here
http://www.cs.helsinki.fi/linux/linux-kernel/2003-23/1245.html
I found this entry:
[EMAIL PROTECTED] (03/06/08 1.1218)
[e100] misc
...
* Add 1/2 second delay after PHY reset to allow link partner to
see and respond to reset, per IEEE 802.3.
I ran mii-diag when the LEDs went out and the register dump
said it was in loopback. It is somewhat difficult reproduce.
It seems to be timing dependent, something else has to occur
at the same time.
I must confess I have only seen it with the 2.6.13 kernel.
I have not been able to reproduce it with 2.6.18.
But I have found no change in the driver that would fix it so
I suspect the problem is still there.
I have tried adding debug output to see if I can read back the
RESET bit in set state, but then the problem refuses to show
so I don't think I can rule out an unfinished PHY reset.
theoretically, yes, the ieee spec PHY reset timeout is kind of silly: in
no way do we assume that we have re-negotiated link after 1/2 a second!
Other code in the driver should take care of that, and since it works
I'll assume it does ;)
the mdio_read probably acts as a flush to the hardware too -
masquerading problems, more goodness. Perhaps we should do a single read
in all cases and forget about the timeout (is there an mdio_write_flush?)
Anders,
It appears that there isn't such a thing as an mdio_write_flush in e100 but we can force
a flush by reading the status register. Not sure if it works 100% so please give this a
try and let me know if this fixes the problem for you.
Basically, we're preventing mdio writes that might happen after our reset write from
being reordered. This might have caused an undefined state.
Auke
---
e100: force mdio write flush after PHY reset
Make sure the PHY reset happens without delay by flushing the reset write.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 815eb29..04a52cd 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2197,6 +2197,8 @@ static int e100_set_settings(struct net_
int err;
mdio_write(netdev, nic-mii.phy_id, MII_BMCR, BMCR_RESET);
+ /* flush MDIO write */
+ mdio_read(netdev, nic-mii.phy_id, MII_BMSR);
err = mii_ethtool_sset(nic-mii, cmd);
e100_exec_cb(nic, NULL, e100_configure);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100: Wait for PHY reset to complete?
Anders Grafström wrote: Anders Grafström wrote: I ran mii-diag when the LEDs went out and the register dump said it was in loopback. It is somewhat difficult reproduce. It seems to be timing dependent, something else has to occur at the same time. I must confess I have only seen it with the 2.6.13 kernel. I have not been able to reproduce it with 2.6.18. But I have found no change in the driver that would fix it so I suspect the problem is still there. Now looking at mdio_ctrl(), which implements mdio_write() and mdio_read(), I see that this patch http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.15/2.6.15-mm3/broken-out/corruption-during-e100-mdi-register-access.patch most likely fixed the problem that I have experienced. although access to the MDI registers involves multiple steps which must not be intermixed, nothing was defending against two or more threads attempting simultaneous access. The most obvious situation where such interference could occur involves the watchdog versus ioctl paths Sorry for the noise. cool, thanks for digging that up and taking the time to report back ;) Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: [Bugme-new] [Bug 7450] New: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
Andrew Morton wrote: Begin forwarded message: Date: Thu, 2 Nov 2006 06:41:04 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bugme-new] [Bug 7450] New: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang http://bugzilla.kernel.org/show_bug.cgi?id=7450 Summary: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Kernel Version: 2.6.19-rc3 Status: NEW Severity: normal Owner: [EMAIL PROTECTED] Submitter: [EMAIL PROTECTED] Most recent kernel where this bug did not occur: not known Distribution: Gentoo Linux x86_64 Hardware Environment: lspci 00:00.0 Host bridge: Intel Corporation E7230/3000/3010 Memory Controller Hub (rev c0) 00:01.0 PCI bridge: Intel Corporation E7230/3000/3010 PCI Express Root Port (rev c0) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controller AHCI (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) 01:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09) 01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) 01:00.3 PIC: Intel Corporation 6700PXH I/OxAPIC Interrupt Controller B (rev 09) 0d:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 0e:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 0f:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02) Software Environment: Iptables/Iproute2 Problem Description: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Tx Queue 0 TDH 31 TDT 31 the hang is caused by a bad eeprom bit. A script that fixes it for 82573-series with eeproms that need this bit fixed is attached to the bugreport. It detects the proper chipset and patches if required (uses ethtool). hth, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke It seems odd because that means you can never make a device fully deaf. sure you can, just turn off WoL and e1000 will really shutdown (at least, I hope :)) Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: On Fri, 03 Nov 2006 15:44:13 -0800 Auke Kok [EMAIL PROTECTED] wrote: Stephen Hemminger wrote: It doesn't seem like a good idea for a network device to wake the system if it is down. before suspend existed this was the only useful case for WoL. Why does it not seem a good idea to wake up a machine that was shutdown (and thus the interface `downed`) ? Auke Interestingly it looks like e100 is one of the ones that only wakes from suspend (not when down). that would be a bug, I'll have to get that checked especially after the latest changes to it. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 17:36:45 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
On Fri, 03 Nov 2006 15:44:13 -0800
Auke Kok [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
It doesn't seem like a good idea for a network device to wake the system
if it is down.
before suspend existed this was the only useful case for WoL. Why does it not seem a
good idea to wake up a machine that was shutdown (and thus the interface `downed`) ?
Auke
Interestingly it looks like e100 is one of the ones that only wakes from
suspend (not when down).
that would be a bug, I'll have to get that checked especially after the latest changes
to it.
Sorry, my bad my test machine was not setup properly.
I don't blame you, WoL is one of the hardest features to get right, especially with all
the various e100{,0} hardware and options that influence it (manageability, eeproms, etc).
On top of that there's this blob called BIOS messing it all up after a
powercycle :)
Cheers,
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Wake On Lan device semantics
Stephen Hemminger wrote: On Fri, 03 Nov 2006 16:02:30 -0800 (PST) David Miller [EMAIL PROTECTED] wrote: From: Jeff Garzik [EMAIL PROTECTED] Date: Fri, 03 Nov 2006 18:51:25 -0500 The purpose of WOL is being able to turn on a system remotely, if it is in a power-off or sleep state. So, if the system is -on- and the interface is down and/or driver is unloaded, are you saying WOL is a problem somehow? Stephen is saying that if you down an interface, it should disable that WoL functionality. I guess you can argue that, like IP addresses, this WoL thing is an attribute of the system. Looking harder. The semantic needs to be WOL is okay if driver is loaded and device is up or down. But the default for WOL should be disabled until enabled by ethtool (or parameter). Since this is enabled already in the BIOSes for most systems (or disabled, and switcheable by the user), I'd say we can let the driver handle the default (on for most cards) already. The BIOS can also handle a WoL call after a (long) powerfailure, before the OS boots, so disabling it in the OS would be quite useless in that case: the BIOS would override it anyway. Doesn't sound like a problem you can solve in the driver layer... Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] e1000: features, updates, documentation
Jeff Garzik wrote: pulled. still waiting on those changes to better modularize the feature detection, etc. that will start coming in early januari I think. We're currently validating all silicon that the code supports against the old and new code, and that is going to take quite some time to finish! Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rewrite e100_phys_id
Matthew Wilcox wrote:
The motivator for this was to fix the sparse warning:
drivers/net/e100.c:2418:48: warning: cast truncates bits from constant
value (83126e978d4fdf becomes 978d4fdf)
drivers/net/e100.c:2419:37: warning: cast truncates bits from constant
value (83126e978d4fdf becomes 978d4fdf)
Initially, I tried a quick fix, but when it ran into difficulties, I
looked at tg3.c to see how it does it. I liked their way better, so I
rewrote e100.c to be similar. It shaves ~700 bytes off the size of the
driver, and a few bytes off the size of struct nic, so I think it's a
win all round. Tested on the internal interface of an HP Integrity rx2600.
bad news, it's completely hosed. The adapter does some indistinguishable blinking for a
second, then stops blinking alltogether.
I might revert the code to the old situation. I guess I should have tested it initially
right away.
I'm not even going to touch the e1000 patch for now ;)
Auke
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index a3a08a5..aade1e9 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -556,7 +556,6 @@ struct nic {
struct params params;
struct net_device_stats net_stats;
struct timer_list watchdog;
- struct timer_list blink_timer;
struct mii_if_info mii;
struct work_struct tx_timeout_task;
enum loopback loopback;
@@ -581,7 +580,6 @@ struct nic {
u32 rx_over_length_errors;
u8 rev_id;
- u16 leds;
u16 eeprom_wc;
u16 eeprom[256];
spinlock_t mdio_lock;
@@ -2168,23 +2166,6 @@ err_clean_rx:
return err;
}
-#define MII_LED_CONTROL 0x1B
-static void e100_blink_led(unsigned long data)
-{
- struct nic *nic = (struct nic *)data;
- enum led_state {
- led_on = 0x01,
- led_off= 0x04,
- led_on_559 = 0x05,
- led_on_557 = 0x07,
- };
-
- nic-leds = (nic-leds led_on) ? led_off :
- (nic-mac mac_82559_D101M) ? led_on_557 : led_on_559;
- mdio_write(nic-netdev, nic-mii.phy_id, MII_LED_CONTROL, nic-leds);
- mod_timer(nic-blink_timer, jiffies + HZ / 4);
-}
-
static int e100_get_settings(struct net_device *netdev, struct ethtool_cmd
*cmd)
{
struct nic *nic = netdev_priv(netdev);
@@ -2411,16 +2392,32 @@ static void e100_diag_test(struct net_de
msleep_interruptible(4 * 1000);
}
+#define MII_LED_CONTROL 0x1B
static int e100_phys_id(struct net_device *netdev, u32 data)
{
struct nic *nic = netdev_priv(netdev);
+ int i;
+
+ enum led_state {
+ led_off= 0x04,
+ led_on_559 = 0x05,
+ led_on_557 = 0x07,
+ };
+ u16 leds = led_off;
+
+ if (data == 0)
+ data = 2;
+
+ for (i = 0; i (data * 2); i++) {
+ leds = (leds == led_off) ?
+ (nic-mac mac_82559_D101M) ? led_on_557 : led_on_559 :
+ led_off;
+ mdio_write(nic-netdev, nic-mii.phy_id, MII_LED_CONTROL, leds);
+ if (msleep_interruptible(500))
+ break;
+ }
- if(!data || data (u32)(MAX_SCHEDULE_TIMEOUT / HZ))
- data = (u32)(MAX_SCHEDULE_TIMEOUT / HZ);
- mod_timer(nic-blink_timer, jiffies);
- msleep_interruptible(data * 1000);
- del_timer_sync(nic-blink_timer);
- mdio_write(netdev, nic-mii.phy_id, MII_LED_CONTROL, 0);
+ mdio_write(netdev, nic-mii.phy_id, MII_LED_CONTROL, led_off);
return 0;
}
@@ -2633,9 +2630,6 @@ #endif
init_timer(nic-watchdog);
nic-watchdog.function = e100_watchdog;
nic-watchdog.data = (unsigned long)nic;
- init_timer(nic-blink_timer);
- nic-blink_timer.function = e100_blink_led;
- nic-blink_timer.data = (unsigned long)nic;
INIT_WORK(nic-tx_timeout_task,
(void (*)(void *))e100_tx_timeout_task, netdev);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Rewrite e100_phys_id
Matthew Wilcox wrote: On Tue, Nov 07, 2006 at 10:33:14AM -0800, Auke Kok wrote: Matthew Wilcox wrote: Tested on the internal interface of an HP Integrity rx2600. bad news, it's completely hosed. The adapter does some indistinguishable blinking for a second, then stops blinking alltogether. Weird. I tested it on the only e100 I have access to, and it worked. I've just reviewed the patch you quoted below, and I don't see what the problem is. I don't understand it either, and will dig into this after I get more coffee. point is that `ethtool -p` now exits immediately after 500ms. it should loop until ^C is pressed. Somehow msleep_interruptable is always returning 0 on my platform? very strange. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Intel 82559 NIC corrupted EEPROM
John wrote: I have a motherboard with three on-board 82559 NICs. o eepro100.ko properly initializes all three NICs o e100.ko fails to initialize one of them NOTE: With kernel 2.6.14, e100.ko fails to initialize the NIC with MAC address 00:30:64:04:E6:E4. With kernel 2.6.18 e100.ko fails to initialize the NIC with MAC address 00:30:64:04:E6:E5. The problem is not an incorrect checksum. (Donald Becker's dump utility reports a correct checksum for all three NICs.) The problem seems to be that e100.ko fails to read the contents of one of the EEPROMs. [snip] 'insmod e100.ko eeprom_bad_csum_allow=1' reports: e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 12 PCI: setting IRQ 12 as level-triggered ACPI: PCI Interrupt :00:08.0[A] - Link [LNKA] - GSI 12 (level, low) - IRQ 12 e100: eth0: e100_probe: addr 0xe530, irq 12, MAC addr 00:30:64:04:E6:E4 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10 PCI: setting IRQ 10 as level-triggered ACPI: PCI Interrupt :00:09.0[A] - Link [LNKB] - GSI 10 (level, low) - IRQ 10 e100: :00:09.0: e100_eeprom_load: EEPROM corrupted e100: :00:09.0: e100_probe: Invalid MAC address from EEPROM, aborting. ACPI: PCI interrupt for device :00:09.0 disabled e100: probe of :00:09.0 failed with error -11 This is what I was afraid of: even though the code allows you to bypass the EEPROM checksum, the probe fails on a further check to see if the MAC address is valid. Since something with this NIC specifically made the EEPROM return all 0xff's, the MAC address is automatically invalid, and thus probe fails. It seems that the driver has more problems with this NIC than just the eeprom checksum being bad. Needless to say this might need fixing. Can you load the eepro driver and send me the full eeprom dump? Perhaps I can duplicate things over here. [snip] On a related note, I am concerned by this message: Sleep mode is enabled. This is not recommended. Under high load the card may not respond to PCI requests, and thus cause a master abort. To clear sleep mode use the '-G 0 -w -w -f' options. Intel 82559 EEPROM Map and Programming Information (AP-394) states: http://www.intel.com/design/network/applnots/ap394.htm The Standby Enable bit enables the 82559 to enter standby mode. When this bit equals 1b, the 82559 is able to recognize an idle state and can enter standby mode (some internal clocks are stopped for power saving purposes). The 82559 does not require a PCI clock signal in standby mode. If this bit equals 0b, the idle recognition circuit is disabled and the 82559 always remains in an active state. Thus, the 82559 always requests PCI CLK using the Clockrun mechanism. Auke, do you agree with Donald Becker's warning? If you are using the e100 in a performance situation, I would certainly switch it off :) If I disable STB, the NICs will waste a bit more power when idle, is that correct? Are there other implications? hm, I don't know the power specs of e100 that well, so I can't say that it saves significant amounts of power, but I suspect it would. Power management on nics is hairy business. As suggested, it can take time before the nic powers back up, performance can be impacted, and some commands might return an invalid or unknown value. OTOH our labs here test these things pretty well before they get send out to customers and resales agents, so Beckers cautious wording catches the severity pretty well (recommended). I would say that under most circumstances, it's safe to enable STB, but you might want to disable it for use in routing and other server applications, where most of the time the NIC is active anyway. hth Auke Thanks for reading this far! John - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
e1000: include net/ip6_checksum.h for IA64
Here's a slightly better patch to fix ia64 not building atm. Jeff, please apply this to netdev-2.6#upstream instead of akpm's patch that I acked earlier. Of course, someone really should come up with an asm version for ia64 of the missing function ;) Cheers, Auke --- e1000: include net/ip6_checksum.h for IA64 IA64 does not have an optimized asm version for ipv6 csum magic. Fall back to generic implementation. Signed-off-by: Auke Kok [EMAIL PROTECTED] diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h index f091042..26e7506 100644 --- a/drivers/net/e1000/e1000.h +++ b/drivers/net/e1000/e1000.h @@ -61,6 +61,7 @@ #include linux/ip.h #ifdef NETIF_F_TSO6 #include linux/ipv6.h +#include net/ip6_checksum.h #endif #include linux/tcp.h #include linux/udp.h - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000: include net/ip6_checksum.h for IA64
Chen, Kenneth W wrote: Chen, Kenneth wrote on Wednesday, November 08, 2006 4:10 PM Auke Kok wrote on Wednesday, November 08, 2006 9:49 AM Of course, someone really should come up with an asm version for ia64 of the missing function ;) Sure, absolutely. Here is an implementation for ia64. Tested heavily. Tony, please merge. Applauded-by: Auke Kok [EMAIL PROTECTED] ;) Cheers, Auke Hmm. Forgot about the signed-off line. Here it is: Signed-off-by: Ken Chen [EMAIL PROTECTED] [patch] implement csum_ipv6_magic for ia64. The asm version is 3.4 times faster than the generic version. --- ./arch/ia64/lib/ip_fast_csum.S.orig 2006-11-08 12:26:28.0 -0800 +++ ./arch/ia64/lib/ip_fast_csum.S 2006-11-08 16:39:24.0 -0800 @@ -8,8 +8,8 @@ * in0: address of buffer to checksum (char *) * in1: length of the buffer (int) * - * Copyright (C) 2002 Intel Corp. - * Copyright (C) 2002 Ken Chen [EMAIL PROTECTED] + * Copyright (C) 2002, 2006 Intel Corp. + * Copyright (C) 2002, 2006 Ken Chen [EMAIL PROTECTED] */ #include asm/asmmacro.h @@ -25,6 +25,9 @@ #define in0 r32 #define in1r33 +#define in2r34 +#define in3r35 +#define in4r36 #define ret0 r8 GLOBAL_ENTRY(ip_fast_csum) @@ -88,3 +91,51 @@ GLOBAL_ENTRY(ip_fast_csum) mov b0=r34 br.ret.sptk.many b0 END(ip_fast_csum) + +GLOBAL_ENTRY(csum_ipv6_magic) + ld4 r20=[in0],4 + ld4 r21=[in1],4 + dep r15=in2,in3,16,16 + ;; + ld4 r22=[in0],4 + ld4 r23=[in1],4 + mux1r15=r15,@rev + ;; + ld4 r24=[in0],4 + ld4 r25=[in1],4 + shr.u r15=r15,32 + add r16=r20,r21 + add r17=r22,r23 + ;; + ld4 r26=[in0],4 + ld4 r27=[in1],4 + add r18=r24,r25 + add r8=r16,r17 + ;; + add r19=r26,r27 + add r8=r8,r18 + ;; + add r8=r8,r19 + add r15=r15,in4 + ;; + add r8=r8,r15 + ;; + shr.u r10=r8,16 // now fold sum into short + zxt2r11=r8 + ;; + add r8=r10,r11 + ;; + shr.u r10=r8,16 // yeah, keep it rolling + zxt2r11=r8 + ;; + add r8=r10,r11 + ;; + shr.u r10=r8,16 // three times lucky + zxt2r11=r8 + ;; + add r8=r10,r11 + mov r9=0x + ;; + andcm r8=r9,r8 + br.ret.sptk.many b0 +END(csum_ipv6_magic) --- ./include/asm-ia64/checksum.h.orig 2006-11-08 16:52:16.0 -0800 +++ ./include/asm-ia64/checksum.h 2006-11-08 17:01:09.0 -0800 @@ -73,4 +73,10 @@ csum_fold (unsigned int sum) return ~sum; } +#define _HAVE_ARCH_IPV6_CSUM 1 +struct in6_addr; +extern unsigned short int csum_ipv6_magic(struct in6_addr *saddr, + struct in6_addr *daddr, __u32 len, unsigned short proto, + unsigned int csum); + #endif /* _ASM_IA64_CHECKSUM_H */ - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Intel 82559 NIC corrupted EEPROM
John wrote: Auke Kok wrote: This is what I was afraid of: even though the code allows you to bypass the EEPROM checksum, the probe fails on a further check to see if the MAC address is valid. Since something with this NIC specifically made the EEPROM return all 0xff's, the MAC address is automatically invalid, and thus probe fails. I don't understand why you think there is something wrong with a specific NIC? that was completely not my point - I was merely trying to point out that the original problem causes a cascade of error events later on, and bypassing the eeprom check in this case didn't help you at all. Something is wrong in the driver, but I don't understand yet why it only affects one of the 3 nics in your system. In 2.6.14.7, e100.ko fails to read the EEPROM on :00:08.0 (eth0) In 2.6.18.1, e100.ko fails to read the EEPROM on :00:09.0 (eth1) almost sounds like a bug got fixed and it introduced a regression. this wouldn't be the right time to pull out git-bisect would it? even loading 2.6.15, 2.6.16, 2.6.17 on it would give us some good information. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote:
Hi,
Even if the total lock time can be reduced, it's possible that interrupt
handler is executed while the interrupted code is still holding the
semaphore.
I think your method only decrease the frequency of this problem.
Why does reducing the lock time solve this problem?
there are several problems here that need addressing. It's not acceptable
for our driver to wait up to 15 seconds, and we can (presumably) reduce it
to milliseconds, so that would help a lot. We should in no case at all hold
it for any period longer than (give or take) half a second, so working
towards that is a very good step in the right direction.
Adding the timer task back may also help, as we are no longer trying to
aqcuire the sw_fw_semaphore in interrupt context, but we removed it for a
reason, and I need to dig up what reason this exactly was before we can
revert it. Jesse might know, so I'll talk to him. But this will not fix the
fact that the semaphore is held for a long time :)
[...]
I think this problem occurs because interrupt handler is executed in same
CPU as process that acquires semaphore.
How about disabling interrupt while the process is holding the semaphore?
I think this is possible, if the total lock time has been reduced.
I created the attached patch based on the method described above.
This patch disables interrupt while the process is holding the semaphore.
I measured how long interrupts are being disabled 10,000 times using the
following method. TSC was read by rdtscll when interrupt was disabled
and interrupt was enabled again, then I subtract these two value.
The longest period interrupt was disabled is under 10usec, which seems
acceptable. The evaluation environment is;
CPU: Intel Xeon CPU 3.73GHz
kernel : 2.6.19-rc5
I also ran the reproduction TP I sent previously and confirmed that the
system didn't panic.
http://marc.theaimsgroup.com/?l=linux-netdevm=116125332319850w=2
How about this method?
I'm not sure why you would have to disable interrupts when freeing the semaphore, but
more importantly I don't want to introduce irq code in the swfw handling functions.
Since the major (only) user running this piece of code in intterupt context is the
watchdog, we might as well see if we can only disable interrupts for that code path,
which would only be once per 2 seconds. We don't need to protect the ethtool path into
this code as it doesn't run in irq context.
Would you mind giving attached patch a try and let me know if it works for you? It will
disable irqs for a bit longer time than your patch, and it begs for a special
check-link-in-watchdog function that doesn't take so damn long :(
Thanks,
Auke
Signed-off-by: Auke Kok [EMAIL PROTECTED]
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index a2f1464..0b52ded 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2430,8 +2430,12 @@ e1000_watchdog(unsigned long data)
struct e1000_tx_ring *txdr = adapter-tx_ring;
uint32_t link, tctl;
int32_t ret_val;
+ unsigned long flags;
+ local_irq_save(flags);
ret_val = e1000_check_for_link(adapter-hw);
+ local_irq_restore(flags);
+
if ((ret_val == E1000_ERR_PHY)
(adapter-hw.phy_type == e1000_phy_igp_3)
(E1000_READ_REG(adapter-hw, CTRL) E1000_PHY_CTRL_GBE_DISABLE)) {
Re: e100: inappropriate handling of shared interrupt ?
Shaw Vrana wrote: Hello All, I'm seeing some odd behavior using the e100 driver for an intel ethernet controller 82557/8/9 (revv 10). It appears as if the e100 driver is handling interrupts generated by another device, though I am not certain of this.. Using some printks, I see some odd packets received that are eventually dropped somewhere up the stack. The packets usually look something like this: SrcAddr: 8.0.69.0 (bogus source ip) DstAddr: 0.40.226.169 (bogus dest ip) Protocol: 6 InputInt: 2 SrcPort: 20 DstPort: 8793 The src address and dest. address are entirely bogus, the protocol is not always TCP, but I've seen it be icmp or udp. In addition, I see _nothing_ using tcpdump, which I also do not understand as I didn't think packets were dropped before tcpdump. I've seen this behavior on multiple machines using the same hardware, but haven't been able to make much sense of it. These packets do not seem to affect the normal operation of the device, i.e. it services correct ips/ports just as one would expect. B/c I haven't been able to see the packets using tcpdump, I have been thinking that the packets were generated by the box itself. The packets appear to be constantly arriving, though it does not appear as if a packet with the same src ip/dst ip arrives more than once, though I could be wrong about this. From dmesg I see that the e100 is sharing irq 12. e100: Intel(R) PRO/100 Network Driver, 3.4.8-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation PCI: Found IRQ 12 for device :01:04.0 PCI: Sharing IRQ 12 with :00:02.0 PCI: Sharing IRQ 12 with :00:1d.0 divert: allocating divert_blk for eth0 e100: eth0: e100_probe: addr 0xe8083000, irq 12, MAC addr 00:0E:B6:26:95:05 (This is the only other message I see mentioning irq 12) what does /proc/interrupts say after the box is fully booted? serio: i8042 AUX port at 0x60,0x64 irq 12 so, proc/interrupts should show 2 devices using the same interrupt. (output of ethtool -e) Offset Values -- -- 0x 00 0e b6 26 95 05 1b 0d ff ff 01 02 01 47 ff ff 0x0010 ff ff ff ff 00 5f 70 00 86 80 7f 00 ff ff ff ff 0x0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0040 ff ff ff ff ff ff 29 12 ff ff ff ff ff ff ff ff 0x0050 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0x0060 2c 01 00 40 06 41 ff ff ff ff ff ff ff ff ff ff 0x0070 ff ff ff ff ff ff ff ff ff ff ff ff ff ff b3 b5 eth1Link encap:Ethernet HWaddr 00:0E:B6:26:95:05 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3959305 errors:0 dropped:0 overruns:0 frame:0 TX packets:5337629 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:801040171 (763.9 MiB) TX bytes:797939498 (760.9 MiB) Interrupt:12 Base address:0xd000 Memory:e8083000-e8084000 Notice that 0 errors are reported.. How could this be? use ethtool -S eth1 to get more information on errors etc. It's unlikely that an irq problem shows up in the ifconfig error stats. Those are completely different counters that don't interact. ethtool eth1 Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: No Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: off Supports Wake-on: g Wake-on: d Current message level: 0x0007 (7) Link detected: yes Any ideas? can you try with the latest e100 driver from e1000.sf.net ? I don't think it solves it but it might help to try (doesn't hurt). Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-2.4] e100: incorrect use of instead of
Willy Tarreau wrote: Hi Auke, On Mon, Nov 27, 2006 at 09:31:34AM -0800, Auke Kok wrote: Willy Tarreau wrote: Hi guys, I'm about to apply this fix to 2.4. 2.6 is not affected. Do you have any objection ? Willy, you didn't CC netdev. linux-net is a users list, you didn't CC the maintainers of the driver. Please do this. We're more than happy to help, even for 2.4 kernels. I'm really sorry, as I usually use netdev and not linux-net. I don't know why I used this one in the first step. There might have been some fog inside my head. BTW, there's no clear maintainer identified for e100. At best I can find [EMAIL PROTECTED] in the file, without any freshness info. Is that still OK or do you want to update the MAINTAINERS file ? I'll post a patch for it, it's definately out of date :( Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote: Hi, Doesn't this just mean that we need a spinlock or some other kind of semaphore around acquiring, using, and releasing this resource? We keep going around and around about this but I'm pretty sure spinlocks are meant to be able to solve exactly this issue. The problem is going to get considerably more nasty if we need to hold a spinlock with interrupts disabled for a significant amount of time, at which point a semaphore of some kind with a spinlock around it would seem to be more useful. Even if spin_lock() was used to protect this resource, it is still possible for an interrupt to kick in and call e1000_watchdog. In this case, e1000_get_software_semaphore() will be called from within the interrupt handler and the problem will still occur. In order to solve this problem, interrupt should be disabled (for example, spin_lock_irqsave). The interrupt handler can't run while the process is holding this resource, and this problem doesn't occur. I'll work with Auke to see if we can come up with another try. Do you have any updates about your test code? Does the fix I previously proposed have problems? If it does, I'd like to help find investigate another fix to solve this problem. There are several issues that are conflicting and mixing that make it less than intuitive to decide what the better fix is. Most of all, we discussed that adding a spinlock is not going to fix the underlying problem of contention, as the code that would need to be spinlocked can sleep. Not a good thing. Adding state tracking code in the form of atomics might solve the issue too, but then we need to do this in quite a few locations. And it comes down to the fact that we really want all users of the semaphore to halt in case it is in use. Reducing the swfw semaphore time is a usefull exercise, but requires an amazing amount of changes to all of the phy code to make sure we're not locking it too long, and even then I doubt that we will reduce the maximum lock time to acceptable levels. The watchdog then, appears to needlessly lock the semaphore every two seconds. this is because even though the link is up and we're already setup, we go through the trouble of doing all the PHY reads, which are protected by the semaphores. I'm currently testing a watchdog version which completely bypasses these checks in case the MAC didn't detect a link change, and we already are setup completely. In that case, all we need to do is update stats and reschedule the timer. I'll keep you posted on progress. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.19-rc6-mm2: Network device naming starts at 1 instead of 0
[resend] Quick note: I loaded up 2.6.19-rc6-mm2 on a platform here and noticed that the onboard e1000 NIC was enumerated to eth1 instead of eth0. on 2.6.18.5 and any other kernel I used before, it was properly named eth0 after startup. eth0 itself is completely missing (-ENODEV). I'll try to see if I can point out the culprit, but perhaps this rings a bell to anyone. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/19] e1000: introduce new driver internal hardware API
From: Jeb Cramer [EMAIL PROTECTED]
This introduces the new internal API for hardware-specific code. The
code is split up per chipset and allows future chipset support to be
added without touching the run-time codepatch of old hardware, greatly
reducing the risk of introducing regressions, and making debugging far
easier due to greater codepath separation.
The API code sets up function pointers for the main hardware specific
routines for each family and initializes the MAC type at load time. From
there on the driver initializes each subcomponent (PHY, NVM, etc.) through
it's function pointer call.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_api.c | 1174 +
drivers/net/e1000/e1000_api.h | 160 ++
2 files changed, 1334 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_api.c b/drivers/net/e1000/e1000_api.c
new file mode 100644
index 000..ea4dd64
--- /dev/null
+++ b/drivers/net/e1000/e1000_api.c
@@ -0,0 +1,1174 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+#include e1000_mac.h
+#include e1000_nvm.h
+#include e1000_phy.h
+
+static s32 e1000_set_mac_type(struct e1000_hw *hw);
+
+#ifndef NO_82542_SUPPORT
+extern voide1000_init_function_pointers_82542(struct e1000_hw *hw);
+#endif
+#ifndef NO_82543_SUPPORT
+extern voide1000_init_function_pointers_82543(struct e1000_hw *hw);
+#endif
+#ifndef NO_82540_SUPPORT
+extern voide1000_init_function_pointers_82540(struct e1000_hw *hw);
+#endif
+#ifndef NO_82571_SUPPORT
+extern voide1000_init_function_pointers_82571(struct e1000_hw *hw);
+#endif
+#ifndef NO_82541_SUPPORT
+extern voide1000_init_function_pointers_82541(struct e1000_hw *hw);
+#endif
+#ifndef NO_80003ES2LAN_SUPPORT
+extern voide1000_init_function_pointers_80003es2lan(struct e1000_hw *hw);
+#endif
+#ifndef NO_ICH8LAN_SUPPORT
+extern voide1000_init_function_pointers_ich8lan(struct e1000_hw *hw);
+#endif
+
+/**
+ * e1000_init_mac_params - Initialize MAC function pointers
+ * @hw: pointer to the HW structure
+ *
+ * This function initializes the function pointers for the MAC
+ * set of functions. Called by drivers or by e1000_setup_init_funcs.
+ **/
+s32
+e1000_init_mac_params(struct e1000_hw *hw)
+{
+ s32 ret_val = E1000_SUCCESS;
+
+ if (hw-func.init_mac_params != NULL) {
+ ret_val = hw-func.init_mac_params(hw);
+ if (ret_val) {
+ DEBUGOUT(MAC Initialization Error\n);
+ goto out;
+ }
+ } else {
+ DEBUGOUT(mac.init_mac_params was NULL\n);
+ ret_val = -E1000_ERR_CONFIG;
+ }
+
+out:
+ return ret_val;
+}
+
+/**
+ * e1000_init_nvm_params - Initialize NVM function pointers
+ * @hw: pointer to the HW structure
+ *
+ * This function initializes the function pointers for the NVM
+ * set of functions. Called by drivers or by e1000_setup_init_funcs.
+ **/
+s32
+e1000_init_nvm_params(struct e1000_hw *hw)
+{
+ s32 ret_val = E1000_SUCCESS;
+
+ if (hw-func.init_nvm_params != NULL) {
+ ret_val = hw-func.init_nvm_params(hw);
+ if (ret_val) {
+ DEBUGOUT(NVM Initialization Error\n);
+ goto out;
+ }
+ } else {
+ DEBUGOUT(nvm.init_nvm_params was NULL\n);
+ ret_val = -E1000_ERR_CONFIG;
+ }
+
+out:
+ return ret_val;
+}
+
+/**
+ * e1000_init_phy_params - Initialize PHY function pointers
+ * @hw: pointer to the HW structure
+ *
+ * This function initializes the function pointers for the PHY
+ * set of functions. Called by drivers or by e1000_setup_init_funcs.
+ **/
+s32
+e1000_init_phy_params(struct e1000_hw *hw)
+{
+ s32 ret_val
[PATCH 05/19] e1000: Add manageability specific hardware initialization code
From: Jeb Cramer [EMAIL PROTECTED]
This adds a device-generic layer for intializing manageability parts
of e1000 hardware, such as packet filtering, dhcp setup, enable passthru
mode.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_manage.c | 384 ++
drivers/net/e1000/e1000_manage.h | 83
2 files changed, 467 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_manage.c b/drivers/net/e1000/e1000_manage.c
new file mode 100644
index 000..36bc082
--- /dev/null
+++ b/drivers/net/e1000/e1000_manage.c
@@ -0,0 +1,384 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+#include e1000_manage.h
+
+static u8 e1000_calculate_checksum(u8 *buffer, u32 length);
+
+/**
+ * e1000_calculate_checksum - Calculate checksum for buffer
+ * @buffer: pointer to EEPROM
+ * @length: size of EEPROM to calculate a checksum for
+ *
+ * Calculates the checksum for some buffer on a specified length. The
+ * checksum calculated is returned.
+ **/
+static u8
+e1000_calculate_checksum(u8 *buffer, u32 length)
+{
+ u32 i;
+ u8 sum = 0;
+
+ DEBUGFUNC(e1000_calculate_checksum);
+
+ if (!buffer)
+ return 0;
+
+ for (i = 0; i length; i++)
+ sum += buffer[i];
+
+ return (u8) (0 - sum);
+}
+
+/**
+ * e1000_mng_enable_host_if_generic - Checks host interface is enabled
+ * @hw: pointer to the HW structure
+ *
+ * Returns E1000_success upon success, else E1000_ERR_HOST_INTERFACE_COMMAND
+ *
+ * This function checks whether the HOST IF is enabled for command operaton
+ * and also checks whether the previous command is completed. It busy waits
+ * in case of previous command is not completed.
+ **/
+s32
+e1000_mng_enable_host_if_generic(struct e1000_hw * hw)
+{
+ u32 hicr;
+ s32 ret_val = E1000_SUCCESS;
+ u8 i;
+
+ DEBUGFUNC(e1000_mng_enable_host_if_generic);
+
+ /* Check that the host interface is enabled. */
+ hicr = E1000_READ_REG(hw, E1000_HICR);
+ if ((hicr E1000_HICR_EN) == 0) {
+ DEBUGOUT(E1000_HOST_EN bit disabled.\n);
+ ret_val = -E1000_ERR_HOST_INTERFACE_COMMAND;
+ goto out;
+ }
+ /* check the previous command is completed */
+ for (i = 0; i E1000_MNG_DHCP_COMMAND_TIMEOUT; i++) {
+ hicr = E1000_READ_REG(hw, E1000_HICR);
+ if (!(hicr E1000_HICR_C))
+ break;
+ mdelay(1);
+ }
+
+ if (i == E1000_MNG_DHCP_COMMAND_TIMEOUT) {
+ DEBUGOUT(Previous command timeout failed .\n);
+ ret_val = -E1000_ERR_HOST_INTERFACE_COMMAND;
+ goto out;
+ }
+
+out:
+ return ret_val;
+}
+
+/**
+ * e1000_check_mng_mode_generic - Generic check managament mode
+ * @hw: pointer to the HW structure
+ *
+ * Reads the firmware semaphore register and returns true (0) if
+ * manageability is enabled, else false (0).
+ **/
+boolean_t
+e1000_check_mng_mode_generic(struct e1000_hw *hw)
+{
+ u32 fwsm;
+
+ DEBUGFUNC(e1000_check_mng_mode_generic);
+
+ fwsm = E1000_READ_REG(hw, E1000_FWSM);
+
+ return ((fwsm E1000_FWSM_MODE_MASK) ==
+ (E1000_MNG_IAMT_MODE E1000_FWSM_MODE_SHIFT));
+}
+
+/**
+ * e1000_enable_tx_pkt_filtering_generic - Enable packet filtering on TX
+ * @hw: pointer to the HW structure
+ *
+ * Enables packet filtering on transmit packets if manageability is enabled
+ * and host interface is enabled.
+ **/
+boolean_t
+e1000_enable_tx_pkt_filtering_generic(struct e1000_hw *hw)
+{
+ struct e1000_host_mng_dhcp_cookie *hdr = hw-mng_cookie;
+ u32 *buffer = (u32 *)hw-mng_cookie;
+ u32 offset;
+ s32 ret_val, hdr_csum, csum;
+ u8 i, len
[PATCH 06/19] e1000: Add new register set code
From: Jeb Cramer [EMAIL PROTECTED] Add e1000_registers.h which contains all supported register sets by e1000 devices in a single file. Signed-off-by: Jeb Cramer [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/e1000_regs.h | 261 1 files changed, 261 insertions(+), 0 deletions(-) diff --git a/drivers/net/e1000/e1000_regs.h b/drivers/net/e1000/e1000_regs.h new file mode 100644 index 000..ce6175b --- /dev/null +++ b/drivers/net/e1000/e1000_regs.h @@ -0,0 +1,261 @@ +/*** + + Intel PRO/1000 Linux driver + Copyright(c) 1999 - 2007 Intel Corporation. + + This program is free software; you can redistribute it and/or modify it + under the terms and conditions of the GNU General Public License, + version 2, as published by the Free Software Foundation. + + This program is distributed in the hope it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., + 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. + + The full GNU General Public License is included in this distribution in + the file called COPYING. + + Contact Information: + Linux NICS [EMAIL PROTECTED] + e1000-devel Mailing List [EMAIL PROTECTED] + Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497 + +***/ + +#ifndef _E1000_REGS_H_ +#define _E1000_REGS_H_ + +#define E1000_CTRL 0x0 /* Device Control - RW */ +#define E1000_CTRL_DUP 0x4 /* Device Control Duplicate (Shadow) - RW */ +#define E1000_STATUS 0x8 /* Device Status - RO */ +#define E1000_EECD 0x00010 /* EEPROM/Flash Control - RW */ +#define E1000_EERD 0x00014 /* EEPROM Read - RW */ +#define E1000_CTRL_EXT 0x00018 /* Extended Device Control - RW */ +#define E1000_FLA 0x0001C /* Flash Access - RW */ +#define E1000_MDIC 0x00020 /* MDI Control - RW */ +#define E1000_SCTL 0x00024 /* SerDes Control - RW */ +#define E1000_FCAL 0x00028 /* Flow Control Address Low - RW */ +#define E1000_FCAH 0x0002C /* Flow Control Address High -RW */ +#define E1000_FEXTNVM 0x00028 /* Future Extended NVM - RW */ +#define E1000_FCT 0x00030 /* Flow Control Type - RW */ +#define E1000_VET 0x00038 /* VLAN Ether Type - RW */ +#define E1000_ICR 0x000C0 /* Interrupt Cause Read - R/clr */ +#define E1000_ITR 0x000C4 /* Interrupt Throttling Rate - RW */ +#define E1000_ICS 0x000C8 /* Interrupt Cause Set - WO */ +#define E1000_IMS 0x000D0 /* Interrupt Mask Set - RW */ +#define E1000_IMC 0x000D8 /* Interrupt Mask Clear - WO */ +#define E1000_IAM 0x000E0 /* Interrupt Acknowledge Auto Mask */ +#define E1000_RCTL 0x00100 /* RX Control - RW */ +#define E1000_RDTR10x02820 /* RX Delay Timer (1) - RW */ +#define E1000_RDBAL1 0x02900 /* RX Descriptor Base Address Low (1) - RW */ +#define E1000_RDBAH1 0x02904 /* RX Descriptor Base Address High (1) - RW */ +#define E1000_RDLEN1 0x02908 /* RX Descriptor Length (1) - RW */ +#define E1000_RDH1 0x02910 /* RX Descriptor Head (1) - RW */ +#define E1000_RDT1 0x02918 /* RX Descriptor Tail (1) - RW */ +#define E1000_FCTTV0x00170 /* Flow Control Transmit Timer Value - RW */ +#define E1000_TXCW 0x00178 /* TX Configuration Word - RW */ +#define E1000_RXCW 0x00180 /* RX Configuration Word - RO */ +#define E1000_TCTL 0x00400 /* TX Control - RW */ +#define E1000_TCTL_EXT 0x00404 /* Extended TX Control - RW */ +#define E1000_TIPG 0x00410 /* TX Inter-packet gap -RW */ +#define E1000_TBT 0x00448 /* TX Burst Timer - RW */ +#define E1000_AIT 0x00458 /* Adaptive Interframe Spacing Throttle - RW */ +#define E1000_LEDCTL 0x00E00 /* LED Control - RW */ +#define E1000_EXTCNF_CTRL 0x00F00 /* Extended Configuration Control */ +#define E1000_EXTCNF_SIZE 0x00F08 /* Extended Configuration Size */ +#define E1000_PHY_CTRL 0x00F10 /* PHY Control Register in CSR */ +#define E1000_PBA 0x01000 /* Packet Buffer Allocation - RW */ +#define E1000_PBS 0x01008 /* Packet Buffer Size */ +#define E1000_EEMNGCTL 0x01010 /* MNG EEprom Control */ +#define E1000_EEARBC 0x01024 /* EEPROM Auto Read Bus Control */ +#define E1000_FLASHT 0x01028 /* FLASH Timer Register */ +#define E1000_EEWR 0x0102C /* EEPROM Write Register - RW */ +#define E1000_FLSWCTL 0x01030 /* FLASH control register */ +#define E1000_FLSWDATA 0x01034 /* FLASH data register */ +#define E1000_FLSWCNT 0x01038 /* FLASH Access Counter */ +#define E1000_FLOP 0x0103C /* FLASH Opcode Register */ +#define
[PATCH 04/19] e1000: NVM specific hardware initialization code
From: Jeb Cramer [EMAIL PROTECTED]
This adds NVM-generic layer code to the e1000 driver, allowing generic
access to the EEPROM/NVM and abstracts much of the driver interaction
with the NVM data.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_nvm.c | 859 +
drivers/net/e1000/e1000_nvm.h | 60 +++
2 files changed, 919 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_nvm.c b/drivers/net/e1000/e1000_nvm.c
new file mode 100644
index 000..46544df
--- /dev/null
+++ b/drivers/net/e1000/e1000_nvm.c
@@ -0,0 +1,859 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+#include e1000_nvm.h
+
+/**
+ * e1000_raise_eec_clk - Raise EEPROM clock
+ * @hw: pointer to the HW structure
+ * @eecd: pointer to the EEPROM
+ *
+ * Enable/Raise the EEPROM clock bit.
+ **/
+static void
+e1000_raise_eec_clk(struct e1000_hw *hw, u32 *eecd)
+{
+ *eecd = *eecd | E1000_EECD_SK;
+ E1000_WRITE_REG(hw, E1000_EECD, *eecd);
+ E1000_WRITE_FLUSH(hw);
+ udelay(hw-nvm.delay_usec);
+}
+
+/**
+ * e1000_lower_eec_clk - Lower EEPROM clock
+ * @hw: pointer to the HW structure
+ * @eecd: pointer to the EEPROM
+ *
+ * Clear/Lower the EEPROM clock bit.
+ **/
+static void
+e1000_lower_eec_clk(struct e1000_hw *hw, u32 *eecd)
+{
+ *eecd = *eecd ~E1000_EECD_SK;
+ E1000_WRITE_REG(hw, E1000_EECD, *eecd);
+ E1000_WRITE_FLUSH(hw);
+ udelay(hw-nvm.delay_usec);
+}
+
+/**
+ * e1000_shift_out_eec_bits - Shift data bits our to the EEPROM
+ * @hw: pointer to the HW structure
+ * @data: data to send to the EEPROM
+ * @count: number of bits to shift out
+ *
+ * We need to shift 'count' bits out to the EEPROM. So, the value in the
+ * data parameter will be shifted out to the EEPROM one bit at a time.
+ * In order to do this, data must be broken down into bits.
+ **/
+static void
+e1000_shift_out_eec_bits(struct e1000_hw *hw, u16 data, u16 count)
+{
+ struct e1000_nvm_info *nvm = hw-nvm;
+ u32 eecd = E1000_READ_REG(hw, E1000_EECD);
+ u32 mask;
+
+ DEBUGFUNC(e1000_shift_out_eec_bits);
+
+ mask = 0x01 (count - 1);
+ if (nvm-type == e1000_nvm_eeprom_microwire)
+ eecd = ~E1000_EECD_DO;
+ else if (nvm-type == e1000_nvm_eeprom_spi)
+ eecd |= E1000_EECD_DO;
+
+ do {
+ eecd = ~E1000_EECD_DI;
+
+ if (data mask)
+ eecd |= E1000_EECD_DI;
+
+ E1000_WRITE_REG(hw, E1000_EECD, eecd);
+ E1000_WRITE_FLUSH(hw);
+
+ udelay(nvm-delay_usec);
+
+ e1000_raise_eec_clk(hw, eecd);
+ e1000_lower_eec_clk(hw, eecd);
+
+ mask = 1;
+ } while (mask);
+
+ eecd = ~E1000_EECD_DI;
+ E1000_WRITE_REG(hw, E1000_EECD, eecd);
+}
+
+/**
+ * e1000_shift_in_eec_bits - Shift data bits in from the EEPROM
+ * @hw: pointer to the HW structure
+ * @count: number of bits to shift in
+ *
+ * In order to read a register from the EEPROM, we need to shift 'count' bits
+ * in from the EEPROM. Bits are shifted in by raising the clock input to
+ * the EEPROM (setting the SK bit), and then reading the value of the data out
+ * DO bit. During this shifting in process the data in DI bit should
+ * always be clear.
+ **/
+static u16
+e1000_shift_in_eec_bits(struct e1000_hw *hw, u16 count)
+{
+ u32 eecd;
+ u32 i;
+ u16 data;
+
+ DEBUGFUNC(e1000_shift_in_eec_bits);
+
+ eecd = E1000_READ_REG(hw, E1000_EECD);
+
+ eecd = ~(E1000_EECD_DO | E1000_EECD_DI);
+ data = 0;
+
+ for (i = 0; i count; i++) {
+ data = 1;
+ e1000_raise_eec_clk(hw, eecd);
+
+ eecd = E1000_READ_REG(hw, E1000_EECD
[PATCH 09/19] e1000: Add 82542 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82542.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82542.c | 551 +++
1 files changed, 551 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82542.c b/drivers/net/e1000/e1000_82542.c
new file mode 100644
index 000..adca182
--- /dev/null
+++ b/drivers/net/e1000/e1000_82542.c
@@ -0,0 +1,551 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82542 (rev 1 2)
+ */
+
+#include e1000_api.h
+
+void e1000_init_function_pointers_82542(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82542(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82542(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82542(struct e1000_hw *hw);
+static s32 e1000_get_bus_info_82542(struct e1000_hw *hw);
+static s32 e1000_reset_hw_82542(struct e1000_hw *hw);
+static s32 e1000_init_hw_82542(struct e1000_hw *hw);
+static s32 e1000_setup_link_82542(struct e1000_hw *hw);
+static s32 e1000_led_on_82542(struct e1000_hw *hw);
+static s32 e1000_led_off_82542(struct e1000_hw *hw);
+static void e1000_clear_hw_cntrs_82542(struct e1000_hw *hw);
+
+struct e1000_dev_spec_82542 {
+ boolean_t dma_fairness;
+};
+
+/**
+ * e1000_init_phy_params_82542 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82542(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_phy_params_82542);
+
+ phy-type = e1000_phy_none;
+
+ return ret_val;
+}
+
+/**
+ * e1000_init_nvm_params_82542 - Init NVM func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_nvm_params_82542(struct e1000_hw *hw)
+{
+ struct e1000_nvm_info *nvm = hw-nvm;
+ struct e1000_functions *func = hw-func;
+
+ DEBUGFUNC(e1000_init_nvm_params_82542);
+
+ nvm-address_bits = 6;
+ nvm-delay_usec = 50;
+ nvm-opcode_bits= 3;
+ nvm-type = e1000_nvm_eeprom_microwire;
+ nvm-word_size = 64;
+
+ /* Function Pointers */
+ func-read_nvm = e1000_read_nvm_microwire;
+ func-release_nvm = e1000_stop_nvm;
+ func-write_nvm = e1000_write_nvm_microwire;
+ func-update_nvm= e1000_update_nvm_checksum_generic;
+ func-validate_nvm = e1000_validate_nvm_checksum_generic;
+
+ return E1000_SUCCESS;
+}
+
+/**
+ * e1000_init_mac_params_82542 - Init MAC func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_mac_params_82542(struct e1000_hw *hw)
+{
+ struct e1000_mac_info *mac = hw-mac;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_mac_params_82542);
+
+ /* Set media type */
+ hw-media_type = e1000_media_type_fiber;
+
+ /* Set mta register count */
+ mac-mta_reg_count = 128;
+ /* Set rar entry count */
+ mac-rar_entry_count = E1000_RAR_ENTRIES;
+
+ /* Function pointers */
+
+ /* bus type/speed/width */
+ func-get_bus_info = e1000_get_bus_info_82542;
+ /* reset */
+ func-reset_hw = e1000_reset_hw_82542;
+ /* hw initialization */
+ func-init_hw = e1000_init_hw_82542;
+ /* link setup */
+ func-setup_link = e1000_setup_link_82542;
+ /* phy/fiber/serdes setup */
+ func-setup_physical_interface
[PATCH 10/19] e1000: Add 82543 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82543.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82543.c | 1643 +++
drivers/net/e1000/e1000_82543.h | 45 +
2 files changed, 1688 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82543.c b/drivers/net/e1000/e1000_82543.c
new file mode 100644
index 000..e61e34a
--- /dev/null
+++ b/drivers/net/e1000/e1000_82543.c
@@ -0,0 +1,1643 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82543
+ * e1000_82544
+ */
+
+#include e1000_82543.h
+
+void e1000_init_function_pointers_82543(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82543(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82543(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82543(struct e1000_hw *hw);
+static s32 e1000_read_phy_reg_82543(struct e1000_hw *hw, u32 offset,
+ u16 *data);
+static s32 e1000_write_phy_reg_82543(struct e1000_hw *hw, u32 offset,
+ u16 data);
+static s32 e1000_phy_force_speed_duplex_82543(struct e1000_hw *hw);
+static s32 e1000_phy_hw_reset_82543(struct e1000_hw *hw);
+static s32 e1000_reset_hw_82543(struct e1000_hw *hw);
+static s32 e1000_init_hw_82543(struct e1000_hw *hw);
+static s32 e1000_setup_link_82543(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_82543(struct e1000_hw *hw);
+static s32 e1000_setup_fiber_link_82543(struct e1000_hw *hw);
+static s32 e1000_check_for_copper_link_82543(struct e1000_hw *hw);
+static s32 e1000_check_for_fiber_link_82543(struct e1000_hw *hw);
+static s32 e1000_led_on_82543(struct e1000_hw *hw);
+static s32 e1000_led_off_82543(struct e1000_hw *hw);
+static void e1000_write_vfta_82543(struct e1000_hw *hw, u32 offset,
+u32 value);
+static void e1000_mta_set_82543(struct e1000_hw *hw, u32 hash_value);
+static void e1000_clear_hw_cntrs_82543(struct e1000_hw *hw);
+static s32 e1000_config_mac_to_phy_82543(struct e1000_hw *hw);
+static boolean_t e1000_init_phy_disabled_82543(struct e1000_hw *hw);
+static void e1000_lower_mdi_clk_82543(struct e1000_hw *hw, u32 *ctrl);
+static s32 e1000_polarity_reversal_workaround_82543(struct e1000_hw *hw);
+static void e1000_raise_mdi_clk_82543(struct e1000_hw *hw, u32 *ctrl);
+static u16 e1000_shift_in_mdi_bits_82543(struct e1000_hw *hw);
+static void e1000_shift_out_mdi_bits_82543(struct e1000_hw *hw, u32 data,
+u16 count);
+static boolean_t e1000_tbi_compatibility_enabled_82543(struct e1000_hw *hw);
+static void e1000_set_tbi_sbp_82543(struct e1000_hw *hw, boolean_t state);
+
+struct e1000_dev_spec_82543 {
+ u32 tbi_compatibility;
+ boolean_t dma_fairness;
+ boolean_t init_phy_disabled;
+};
+
+/**
+ * e1000_init_phy_params_82543 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82543(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_phy_params_82543);
+
+ if (hw-media_type != e1000_media_type_copper) {
+ phy-type = e1000_phy_none;
+ goto out;
+ }
+
+ phy-addr = 1;
+ phy-autoneg_mask = AUTONEG_ADVERTISE_SPEED_DEFAULT;
+ phy-reset_delay_us = 1;
+ phy-type
[PATCH 14/19] e1000: Add 80003es2lan (ESB2) specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 80003es2lan (ESB2).
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_80003es2lan.c | 1377 +
drivers/net/e1000/e1000_80003es2lan.h | 89 ++
2 files changed, 1466 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_80003es2lan.c
b/drivers/net/e1000/e1000_80003es2lan.c
new file mode 100644
index 000..ab9631c
--- /dev/null
+++ b/drivers/net/e1000/e1000_80003es2lan.c
@@ -0,0 +1,1377 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_80003es2lan
+ */
+
+#include e1000_80003es2lan.h
+
+void e1000_init_function_pointers_80003es2lan(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_acquire_phy_80003es2lan(struct e1000_hw *hw);
+static void e1000_release_phy_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_acquire_nvm_80003es2lan(struct e1000_hw *hw);
+static void e1000_release_nvm_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_read_phy_reg_gg82563_80003es2lan(struct e1000_hw *hw,
+ u32 offset,
+ u16 *data);
+static s32 e1000_write_phy_reg_gg82563_80003es2lan(struct e1000_hw *hw,
+u32 offset,
+u16 data);
+static s32 e1000_write_nvm_80003es2lan(struct e1000_hw *hw, u16 offset,
+u16 words, u16 *data);
+static s32 e1000_get_cfg_done_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_phy_force_speed_duplex_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_get_cable_length_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_get_link_up_info_80003es2lan(struct e1000_hw *hw, u16 *speed,
+ u16 *duplex);
+static s32 e1000_reset_hw_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_init_hw_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_80003es2lan(struct e1000_hw *hw);
+static void e1000_clear_hw_cntrs_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_acquire_swfw_sync_80003es2lan(struct e1000_hw *hw, u16 mask);
+static s32 e1000_cfg_kmrn_10_100_80003es2lan(struct e1000_hw *hw, u16 duplex);
+static s32 e1000_cfg_kmrn_1000_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_copper_link_setup_gg82563_80003es2lan(struct e1000_hw *hw);
+static s32 e1000_get_hw_semaphore_80003es2lan(struct e1000_hw *hw);
+static void e1000_initialize_hw_bits_80003es2lan(struct e1000_hw *hw);
+static void e1000_put_hw_semaphore_80003es2lan(struct e1000_hw *hw);
+static void e1000_release_swfw_sync_80003es2lan(struct e1000_hw *hw, u16 mask);
+
+/* A table for the GG82563 cable length where the range is defined
+ * with a lower bound at index and the upper bound at
+ * index + 5.
+ */
+static const
+u16 e1000_gg82563_cable_length_table[] =
+ { 0, 60, 115, 150, 150, 60, 115, 150, 180, 180, 0xFF };
+#define GG82563_CABLE_LENGTH_TABLE_SIZE \
+(sizeof(e1000_gg82563_cable_length_table) / \
+ sizeof(e1000_gg82563_cable_length_table[0]))
+
+/**
+ * e1000_init_phy_params_80003es2lan - Init ESB2 PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_80003es2lan(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC
[PATCH 16/19] e1000: add new chipset-specific files and api files to the Makefile
From: Jeb Cramer [EMAIL PROTECTED] Signed-off-by: Jeb Cramer [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/Makefile | 18 -- 1 files changed, 16 insertions(+), 2 deletions(-) diff --git a/drivers/net/e1000/Makefile b/drivers/net/e1000/Makefile index 4a6ab15..1086807 100644 --- a/drivers/net/e1000/Makefile +++ b/drivers/net/e1000/Makefile @@ -1,7 +1,7 @@ # # Intel PRO/1000 Linux driver -# Copyright(c) 1999 - 2006 Intel Corporation. +# Copyright(c) 1999 - 2007 Intel Corporation. # # This program is free software; you can redistribute it and/or modify it # under the terms and conditions of the GNU General Public License, @@ -32,4 +32,18 @@ obj-$(CONFIG_E1000) += e1000.o -e1000-objs := e1000_main.o e1000_hw.o e1000_ethtool.o e1000_param.o +e1000-objs := e1000_api.o \ + e1000_82540.o \ + e1000_82541.o \ + e1000_82543.o \ + e1000_82542.o \ + e1000_82571.o \ + e1000_ich8lan.o \ + e1000_80003es2lan.o \ + e1000_mac.o \ + e1000_phy.o \ + e1000_nvm.o \ + e1000_manage.o \ + e1000_param.o \ + e1000_ethtool.o \ + e1000_main.o - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/19] e1000: Add 82540 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82540.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82540.c | 670 +++
1 files changed, 670 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82540.c b/drivers/net/e1000/e1000_82540.c
new file mode 100644
index 000..41549b8
--- /dev/null
+++ b/drivers/net/e1000/e1000_82540.c
@@ -0,0 +1,670 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82540
+ * e1000_82545
+ * e1000_82546
+ * e1000_82545_rev_3
+ * e1000_82546_rev_3
+ */
+
+#include e1000_api.h
+
+void e1000_init_function_pointers_82540(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82540(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82540(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82540(struct e1000_hw *hw);
+static s32 e1000_adjust_serdes_amplitude_82540(struct e1000_hw *hw);
+static void e1000_clear_hw_cntrs_82540(struct e1000_hw *hw);
+static s32 e1000_init_hw_82540(struct e1000_hw *hw);
+static s32 e1000_reset_hw_82540(struct e1000_hw *hw);
+static s32 e1000_set_phy_mode_82540(struct e1000_hw *hw);
+static s32 e1000_set_vco_speed_82540(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_82540(struct e1000_hw *hw);
+static s32 e1000_setup_fiber_serdes_link_82540(struct e1000_hw *hw);
+
+/**
+ * e1000_init_phy_params_82540 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82540(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ phy-addr = 1;
+ phy-autoneg_mask = AUTONEG_ADVERTISE_SPEED_DEFAULT;
+ phy-reset_delay_us = 1;
+ phy-type = e1000_phy_m88;
+
+ /* Function Pointers */
+ func-check_polarity= e1000_check_polarity_m88;
+ func-commit_phy= e1000_phy_sw_reset_generic;
+ func-force_speed_duplex= e1000_phy_force_speed_duplex_m88;
+ func-get_cable_length = e1000_get_cable_length_m88;
+ func-get_cfg_done = e1000_get_cfg_done_generic;
+ func-read_phy_reg = e1000_read_phy_reg_m88;
+ func-reset_phy = e1000_phy_hw_reset_generic;
+ func-write_phy_reg = e1000_write_phy_reg_m88;
+ func-get_phy_info = e1000_get_phy_info_m88;
+
+ ret_val = e1000_get_phy_id(hw);
+ if (ret_val)
+ goto out;
+
+ /* Verify phy id */
+ switch (hw-mac.type) {
+ case e1000_82540:
+ case e1000_82545:
+ case e1000_82545_rev_3:
+ case e1000_82546:
+ case e1000_82546_rev_3:
+ if (phy-id == M88E1011_I_PHY_ID)
+ break;
+ /* Fall Through */
+ default:
+ ret_val = -E1000_ERR_PHY;
+ goto out;
+ break;
+ }
+
+out:
+ return ret_val;
+}
+
+/**
+ * e1000_init_nvm_params_82540 - Init NVM func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_nvm_params_82540(struct e1000_hw *hw)
+{
+ struct e1000_nvm_info *nvm = hw-nvm;
+ struct e1000_functions *func = hw-func;
+ u32 eecd = E1000_READ_REG(hw, E1000_EECD);
+
+ DEBUGFUNC(e1000_init_nvm_params_82540);
+
+ nvm-type = e1000_nvm_eeprom_microwire;
+ nvm-delay_usec = 50;
+ nvm-opcode_bits= 3;
+ switch (nvm-override) {
+ case
[PATCH 13/19] e1000: Add 82571 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82571.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82571.c | 1333 +++
drivers/net/e1000/e1000_82571.h | 42 +
2 files changed, 1375 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82571.c b/drivers/net/e1000/e1000_82571.c
new file mode 100644
index 000..32e11a5
--- /dev/null
+++ b/drivers/net/e1000/e1000_82571.c
@@ -0,0 +1,1333 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82571
+ * e1000_82572
+ * e1000_82573
+ */
+
+#include e1000_82571.h
+
+void e1000_init_function_pointers_82571(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82571(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82571(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82571(struct e1000_hw *hw);
+static s32 e1000_acquire_nvm_82571(struct e1000_hw *hw);
+static void e1000_release_nvm_82571(struct e1000_hw *hw);
+static s32 e1000_write_nvm_82571(struct e1000_hw *hw, u16 offset,
+ u16 words, u16 *data);
+static s32 e1000_update_nvm_checksum_82571(struct e1000_hw *hw);
+static s32 e1000_validate_nvm_checksum_82571(struct e1000_hw *hw);
+static s32 e1000_get_cfg_done_82571(struct e1000_hw *hw);
+static s32 e1000_set_d0_lplu_state_82571(struct e1000_hw *hw,
+ boolean_t active);
+static s32 e1000_reset_hw_82571(struct e1000_hw *hw);
+static s32 e1000_init_hw_82571(struct e1000_hw *hw);
+static void e1000_clear_vfta_82571(struct e1000_hw *hw);
+static void e1000_mc_addr_list_update_82571(struct e1000_hw *hw,
+u8 *mc_addr_list, u32
mc_addr_count,
+u32 rar_used_count, u32 rar_count);
+static s32 e1000_setup_link_82571(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_82571(struct e1000_hw *hw);
+static s32 e1000_setup_fiber_serdes_link_82571(struct e1000_hw *hw);
+static s32 e1000_valid_led_default_82571(struct e1000_hw *hw, u16 *data);
+static void e1000_clear_hw_cntrs_82571(struct e1000_hw *hw);
+static s32 e1000_fix_nvm_checksum_82571(struct e1000_hw *hw);
+static s32 e1000_get_phy_id_82571(struct e1000_hw *hw);
+static void e1000_initialize_hw_bits_82571(struct e1000_hw *hw);
+static s32 e1000_write_nvm_eewr_82571(struct e1000_hw *hw, u16 offset,
+ u16 words, u16 *data);
+
+struct e1000_dev_spec_82571 {
+ boolean_t laa_is_present;
+};
+
+/**
+ * e1000_init_phy_params_82571 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82571(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_phy_params_82571);
+
+ if (hw-media_type != e1000_media_type_copper) {
+ phy-type= e1000_phy_none;
+ goto out;
+ }
+
+ phy-addr= 1;
+ phy-autoneg_mask= AUTONEG_ADVERTISE_SPEED_DEFAULT;
+ phy-reset_delay_us = 100;
+
+ func-acquire_phy= e1000_get_hw_semaphore_generic;
+ func-check_polarity = e1000_check_polarity_igp;
+ func-check_reset_block = e1000_check_reset_block_generic;
+ func-release_phy= e1000_put_hw_semaphore_generic;
+ func-reset_phy = e1000_phy_hw_reset_generic;
+ func-set_d0_lplu_state = e1000_set_d0_lplu_state_82571;
+ func-set_d3_lplu_state
[PATCH 12/19] e1000: Add 82541 specific hardware code.
From: Jeb Cramer [EMAIL PROTECTED]
Adapter-specific code for the 82541.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_82541.c | 1305 +++
drivers/net/e1000/e1000_82541.h | 86 +++
2 files changed, 1391 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_82541.c b/drivers/net/e1000/e1000_82541.c
new file mode 100644
index 000..c1e74a3
--- /dev/null
+++ b/drivers/net/e1000/e1000_82541.c
@@ -0,0 +1,1305 @@
+/***
+
+ Intel PRO/1000 Linux driver
+ Copyright(c) 1999 - 2007 Intel Corporation.
+
+ This program is free software; you can redistribute it and/or modify it
+ under the terms and conditions of the GNU General Public License,
+ version 2, as published by the Free Software Foundation.
+
+ This program is distributed in the hope it will be useful, but WITHOUT
+ ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ more details.
+
+ You should have received a copy of the GNU General Public License along with
+ this program; if not, write to the Free Software Foundation, Inc.,
+ 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+
+ The full GNU General Public License is included in this distribution in
+ the file called COPYING.
+
+ Contact Information:
+ Linux NICS [EMAIL PROTECTED]
+ e1000-devel Mailing List [EMAIL PROTECTED]
+ Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497
+
+***/
+
+/* e1000_82541
+ * e1000_82547
+ * e1000_82541_rev_2
+ * e1000_82547_rev_2
+ */
+
+#include e1000_82541.h
+
+void e1000_init_function_pointers_82541(struct e1000_hw *hw);
+
+static s32 e1000_init_phy_params_82541(struct e1000_hw *hw);
+static s32 e1000_init_nvm_params_82541(struct e1000_hw *hw);
+static s32 e1000_init_mac_params_82541(struct e1000_hw *hw);
+static s32 e1000_reset_hw_82541(struct e1000_hw *hw);
+static s32 e1000_init_hw_82541(struct e1000_hw *hw);
+static s32 e1000_get_link_up_info_82541(struct e1000_hw *hw, u16 *speed,
+ u16 *duplex);
+static s32 e1000_phy_hw_reset_82541(struct e1000_hw *hw);
+static s32 e1000_setup_copper_link_82541(struct e1000_hw *hw);
+static s32 e1000_check_for_link_82541(struct e1000_hw *hw);
+static s32 e1000_get_cable_length_igp_82541(struct e1000_hw *hw);
+static s32 e1000_set_d3_lplu_state_82541(struct e1000_hw *hw,
+ boolean_t active);
+static s32 e1000_setup_led_82541(struct e1000_hw *hw);
+static s32 e1000_cleanup_led_82541(struct e1000_hw *hw);
+static void e1000_clear_hw_cntrs_82541(struct e1000_hw *hw);
+static s32 e1000_config_dsp_after_link_change_82541(struct e1000_hw *hw,
+ boolean_t link_up);
+static s32 e1000_phy_init_script_82541(struct e1000_hw *hw);
+
+static const
+u16 e1000_igp_cable_length_table[] =
+{ 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
+ 5, 10, 10, 10, 10, 10, 10, 10, 20, 20, 20, 20, 20, 25, 25, 25,
+ 25, 25, 25, 25, 30, 30, 30, 30, 40, 40, 40, 40, 40, 40, 40, 40,
+ 40, 50, 50, 50, 50, 50, 50, 50, 60, 60, 60, 60, 60, 60, 60, 60,
+ 60, 70, 70, 70, 70, 70, 70, 80, 80, 80, 80, 80, 80, 90, 90, 90,
+ 90, 90, 90, 90, 90, 90, 100, 100, 100, 100, 100, 100, 100, 100, 100, 100,
+ 100, 100, 100, 100, 110, 110, 110, 110, 110, 110, 110, 110, 110, 110,
110, 110,
+ 110, 110, 110, 110, 110, 110, 120, 120, 120, 120, 120, 120, 120, 120,
120, 120};
+#define IGP01E1000_AGC_LENGTH_TABLE_SIZE \
+(sizeof(e1000_igp_cable_length_table) / \
+ sizeof(e1000_igp_cable_length_table[0]))
+
+struct e1000_dev_spec_82541 {
+ e1000_dsp_config dsp_config;
+ e1000_ffe_config ffe_config;
+ u16 spd_default;
+ boolean_t phy_init_script;
+};
+
+/**
+ * e1000_init_phy_params_82541 - Init PHY func ptrs.
+ * @hw: pointer to the HW structure
+ *
+ * This is a function pointer entry point called by the api module.
+ **/
+static s32
+e1000_init_phy_params_82541(struct e1000_hw *hw)
+{
+ struct e1000_phy_info *phy = hw-phy;
+ struct e1000_functions *func = hw-func;
+ s32 ret_val = E1000_SUCCESS;
+
+ DEBUGFUNC(e1000_init_phy_params_82541);
+
+ phy-addr = 1;
+ phy-autoneg_mask = AUTONEG_ADVERTISE_SPEED_DEFAULT;
+ phy-reset_delay_us = 1;
+ phy-type = e1000_phy_igp;
+
+ /* Function Pointers */
+ func-check_polarity= e1000_check_polarity_igp;
+ func-force_speed_duplex= e1000_phy_force_speed_duplex_igp;
+ func-get_cable_length = e1000_get_cable_length_igp_82541
[PATCH 19/19] e1000: major part of the new API changes
From: Jeb Cramer [EMAIL PROTECTED]
The new hardware initialization code requires us to follow a slightly
different approach to setup the device. First the function pointers
have to be initialized for the proper hardware type, after which the
general initialization calls those in turn to do per-device specific
initialization.
Signed-off-by: Jeb Cramer [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_ethtool.c | 97 ++-
drivers/net/e1000/e1000_main.c| 155 -
2 files changed, 160 insertions(+), 92 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index 033cdb6..c26fdac 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -29,6 +29,7 @@
/* ethtool support for e1000 */
#include e1000.h
+#include e1000_82541.h
#include asm/uaccess.h
@@ -1334,6 +1335,43 @@ e1000_integrated_phy_loopback(struct e1000_adapter
*adapter)
}
static int
+e1000_set_82571_fiber_loopback(struct e1000_adapter *adapter)
+{
+ struct e1000_hw *hw = adapter-hw;
+ u32 ctrl = E1000_READ_REG(hw, E1000_CTRL);
+ int link = 0;
+
+ /* special requirements for 82571/82572 fiber adapters */
+
+ /* jump through hoops to make sure link is up because serdes
+* link is hardwired up */
+ ctrl |= E1000_CTRL_SLU;
+ E1000_WRITE_REG(hw, E1000_CTRL, ctrl);
+
+ /* disable autoneg */
+ ctrl = E1000_READ_REG(hw, E1000_TXCW);
+ ctrl = ~(1 31);
+ E1000_WRITE_REG(hw, E1000_TXCW, ctrl);
+
+ link = (E1000_READ_REG(hw, E1000_STATUS) E1000_STATUS_LU);
+
+ if (!link) {
+ /* set invert loss of signal */
+ ctrl = E1000_READ_REG(hw, E1000_CTRL);
+ ctrl |= E1000_CTRL_ILOS;
+ E1000_WRITE_REG(hw, E1000_CTRL, ctrl);
+ }
+
+ /* special write to serdes control register to enable SerDes analog
+* loopback */
+#define E1000_SERDES_LB_ON 0x410
+ E1000_WRITE_REG(hw, E1000_SCTL, E1000_SERDES_LB_ON);
+ msleep(10);
+
+ return 0;
+}
+
+static int
e1000_set_phy_loopback(struct e1000_adapter *adapter)
{
uint16_t phy_reg = 0;
@@ -1385,6 +1423,42 @@ e1000_set_phy_loopback(struct e1000_adapter *adapter)
return 8;
}
+/* only call this for fiber/serdes connections to es2lan */
+static int
+e1000_set_es2lan_mac_loopback(struct e1000_adapter *adapter)
+{
+ struct e1000_hw *hw = adapter-hw;
+ u32 ctrlext = E1000_READ_REG(hw, E1000_CTRL_EXT);
+ u32 ctrl = E1000_READ_REG(hw, E1000_CTRL);
+
+ /* save CTRL_EXT to restore later, reuse an empty variable (unused
+ on mac_type 80003es2lan) */
+ adapter-tx_fifo_head = ctrlext;
+
+ /* clear the serdes mode bits, putting the device into mac loopback */
+ ctrlext = ~E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES;
+ E1000_WRITE_REG(hw, E1000_CTRL_EXT, ctrlext);
+
+ /* force speed to 1000/FD, link up */
+ ctrl = ~(E1000_CTRL_SPD_1000 | E1000_CTRL_SPD_100);
+ ctrl |= (E1000_CTRL_SLU | E1000_CTRL_FRCSPD | E1000_CTRL_FRCDPX |
+E1000_CTRL_SPD_1000 | E1000_CTRL_FD);
+ E1000_WRITE_REG(hw, E1000_CTRL, ctrl);
+
+ /* set mac loopback */
+ ctrl = E1000_READ_REG(hw, E1000_RCTL);
+ ctrl |= E1000_RCTL_LBM_MAC;
+ E1000_WRITE_REG(hw, E1000_RCTL, ctrl);
+
+ /* set testing mode parameters (no need to reset later) */
+#define KMRNCTRLSTA_OPMODE (0x1F 16)
+#define KMRNCTRLSTA_OPMODE_1GB_FD_GMII 0x0582
+ E1000_WRITE_REG(hw, E1000_KMRNCTRLSTA,
+ (KMRNCTRLSTA_OPMODE | KMRNCTRLSTA_OPMODE_1GB_FD_GMII));
+
+ return 0;
+}
+
static int
e1000_setup_loopback_test(struct e1000_adapter *adapter)
{
@@ -1394,6 +1468,9 @@ e1000_setup_loopback_test(struct e1000_adapter *adapter)
if (hw-media_type == e1000_media_type_fiber ||
hw-media_type == e1000_media_type_internal_serdes) {
switch (hw-mac.type) {
+ case e1000_80003es2lan:
+ return e1000_set_es2lan_mac_loopback(adapter);
+ break;
case e1000_82545:
case e1000_82546:
case e1000_82545_rev_3:
@@ -1402,11 +1479,7 @@ e1000_setup_loopback_test(struct e1000_adapter *adapter)
break;
case e1000_82571:
case e1000_82572:
-#define E1000_SERDES_LB_ON 0x410
- e1000_set_phy_loopback(adapter);
- E1000_WRITE_REG(hw, E1000_SCTL, E1000_SERDES_LB_ON);
- msleep(10);
- return 0;
+ return e1000_set_82571_fiber_loopback(adapter);
break;
default:
rctl = E1000_READ_REG(hw, E1000_RCTL);
@@ -1432,6 +1505,14 @@ e1000_loopback_cleanup(struct e1000_adapter *adapter
[-MM GIT PULL] e1000: fixes, API rewrite, cleanups
Andrew, Please consider pulling from my git tree: git-pull git://lost.foo-projects.org/~ahkok/git/netdev-2.6 mm To get a copy of my current e1000 queue. This tree consists of a recent 'master' branch from linus, and the following patches: 1) 3 patches from jgarzik's e1000-fixes tree 2) 3 patches from jgarzik's upstream branch 3) the hardware initialization API rewrite (as a single commit) patch posted on netdev yesterday 4) 15 other fixes and cleanups currently in my e1000 queue All patches from 3) onwards are also available to view over here: http://foo-projects.org/~sofar/patches-20070327/ Cheers, Auke --- commit a6f63e313c5a26340f52884c52492668a555c38b Author: Auke Kok [EMAIL PROTECTED] Date: Thu Mar 29 14:59:38 2007 -0700 e1000: Update version, typo fixes, date Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 18a6e4b... 3fc332a... M drivers/net/e1000/e1000.h :100644 100644 8a412c5... 05a0573... M drivers/net/e1000/e1000_ethtool.c :100644 100644 4d8443a... b157359... M drivers/net/e1000/e1000_main.c :100644 100644 3dc17ed... bd2d28a... M drivers/net/e1000/e1000_osdep.h :100644 100644 8bcb377... 95a39c0... M drivers/net/e1000/e1000_param.c commit 67de893160519308ca33248fb4b8e30f7cc1cf8f Author: Bruce Allan [EMAIL PROTECTED] Date: Thu Mar 29 14:59:26 2007 -0700 e1000: insufficient use of DRV_LOAD bit causing firmware to take control The CTRL_EXT.DRV_LOAD bit was being cleared in the driver on every MAC reset (e.g. when the interface was down'ed) and not being properly set again (e.g. when the interface was re-up'ed). This caused AMT to think it was the sole owner of the h/w which consequently forced the PHY to 100Mbps since the f/w folks chose not to support 1000Mbps in order to not have to implement the Nineveh PHY powerdown workaround. Signed-off-by: Bruce Allan [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 e3b2e52... 4d8443a... M drivers/net/e1000/e1000_main.c commit 8d4d8333b64c6251ccb6eae56ea49efc6fc49f95 Author: Auke Kok [EMAIL PROTECTED] Date: Thu Mar 29 14:59:18 2007 -0700 e1000: Free interrupts symmetrically with resume Free interrupts symmetrically with resume allocation to prevent pci save/restore state from possibly failing or warning. Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 07f7e98... e3b2e52... M drivers/net/e1000/e1000_main.c commit 91f0e3ed1deef5183fc7a5ce9a424b01f79d4810 Author: Jesse Brandeburg [EMAIL PROTECTED] Date: Thu Mar 29 14:59:06 2007 -0700 e1000: fix empty frame only containing a crc from being dumped A cornercase fragment could contain only the CRC but considered empty after crc stripping. Make sure we account for that. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 69a204b... 07f7e98... M drivers/net/e1000/e1000_main.c commit 4d4b5ac4ab84de1f693c976764eb33b6aa1585c3 Author: Bruce Allan [EMAIL PROTECTED] Date: Thu Mar 29 14:58:57 2007 -0700 e1000: Fix some stats being collected on adapters that don't have them Several stats were being collected on ich8 that don't exist there. Signed-off-by: Bruce Allan [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 6037e78... 69a204b... M drivers/net/e1000/e1000_main.c commit 39db87a668ed8aac1dd75befd5f6f48dda0e3db7 Author: Bruce Allan [EMAIL PROTECTED] Date: Thu Mar 29 14:58:38 2007 -0700 e1000: fix two ich8 errata: tx timeouot factor and cable unplug issue for 10/100 modes, a simple incoming ping-flood could cause TX to delay long enough to scream 'TX hung' which was false. Extend the timeout factor for 10/100 speed. On a rare occasion, an ich8 device may lose link after a cable unplug event with the PHY. Downshifting the link prevents us from reading garbage from the PHY and makes sure that the PHY is accessible. Signed-off-by: Bruce Allan [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 90cffc4... 6037e78... M drivers/net/e1000/e1000_main.c commit 38fe2f8adb14761600d571f3ec269c55060e0da3 Author: Auke Kok [EMAIL PROTECTED] Date: Thu Mar 29 14:58:30 2007 -0700 e1000: skip unneeded PHY reads in watchdog when link is OK Several PHY reads that are costly can be omitted if the link is up and netdev as well. Signed-off-by: Auke Kok [EMAIL PROTECTED] :100644 100644 4a322ae... 90cffc4... M drivers/net/e1000/e1000_main.c commit 95a01c8a78bc2e51dad8c0e667141023cb323e51 Author: Jesse Brandeburg [EMAIL PROTECTED] Date: Thu Mar 29 14:58:23 2007 -0700 e1000: set timestamps before dma unmapping on the off chance that the check of buffer_info-dma returns true when buffer_info-time_stamp hasn't been filled in yet, reverse the order
[PATCH] Seved Torstendahl [EMAIL PROTECTED] suggested to
From: Jesse Brandeburg [EMAIL PROTECTED]
let the module parameter for invalid eeprom checksum control the valid
mac address test.
If this bypass happens we should print a different message,
or at least one that is correct, maybe something like below
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e100.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 1dd1a22..7d9984a 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -2597,11 +2597,16 @@ static int __devinit e100_probe(struct pci_dev *pdev,
memcpy(netdev-dev_addr, nic-eeprom, ETH_ALEN);
memcpy(netdev-perm_addr, nic-eeprom, ETH_ALEN);
- if(!is_valid_ether_addr(netdev-perm_addr)) {
- DPRINTK(PROBE, ERR, Invalid MAC address from
- EEPROM, aborting.\n);
- err = -EAGAIN;
- goto err_out_free;
+ if (!is_valid_ether_addr(netdev-perm_addr)) {
+ if (!eeprom_bad_csum_allow) {
+ DPRINTK(PROBE, ERR, Invalid MAC address from
+ EEPROM, aborting.\n);
+ err = -EAGAIN;
+ goto err_out_free;
+ } else {
+ DPRINTK(PROBE, ERR, Invalid MAC address from EEPROM,
+ you MUST configure one.\n);
+ }
}
/* Wol magic packet can be enabled from eeprom */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] It appears that some systems still like e100 better if it uses
From: Jesse Brandeburg [EMAIL PROTECTED]
I/O access mode. Setting the new parameter use_io=1 will cause
all driver instances to use io mapping to access the register
space on the e100 device.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e100.c | 72
1 files changed, 39 insertions(+), 33 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 7d9984a..7ca207c 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -159,7 +159,7 @@
#define DRV_NAME e100
#define DRV_EXT-NAPI
-#define DRV_VERSION3.5.17-k2DRV_EXT
+#define DRV_VERSION3.5.17-k4DRV_EXT
#define DRV_DESCRIPTIONIntel(R) PRO/100 Network Driver
#define DRV_COPYRIGHT Copyright(c) 1999-2006 Intel Corporation
#define PFXDRV_NAME :
@@ -174,10 +174,13 @@ MODULE_VERSION(DRV_VERSION);
static int debug = 3;
static int eeprom_bad_csum_allow = 0;
+static int use_io = 0;
module_param(debug, int, 0);
module_param(eeprom_bad_csum_allow, int, 0);
+module_param(use_io, int, 0);
MODULE_PARM_DESC(debug, Debug level (0=none,...,16=all));
MODULE_PARM_DESC(eeprom_bad_csum_allow, Allow bad eeprom checksums);
+MODULE_PARM_DESC(use_io, Force use of i/o access mode);
#define DPRINTK(nlevel, klevel, fmt, args...) \
(void)((NETIF_MSG_##nlevel nic-msg_enable) \
printk(KERN_##klevel PFX %s: %s: fmt, nic-netdev-name, \
@@ -584,7 +587,7 @@ static inline void e100_write_flush(struct nic *nic)
{
/* Flush previous PCI writes through intermediate bridges
* by doing a benign read */
- (void)readb(nic-csr-scb.status);
+ (void)ioread8(nic-csr-scb.status);
}
static void e100_enable_irq(struct nic *nic)
@@ -592,7 +595,7 @@ static void e100_enable_irq(struct nic *nic)
unsigned long flags;
spin_lock_irqsave(nic-cmd_lock, flags);
- writeb(irq_mask_none, nic-csr-scb.cmd_hi);
+ iowrite8(irq_mask_none, nic-csr-scb.cmd_hi);
e100_write_flush(nic);
spin_unlock_irqrestore(nic-cmd_lock, flags);
}
@@ -602,7 +605,7 @@ static void e100_disable_irq(struct nic *nic)
unsigned long flags;
spin_lock_irqsave(nic-cmd_lock, flags);
- writeb(irq_mask_all, nic-csr-scb.cmd_hi);
+ iowrite8(irq_mask_all, nic-csr-scb.cmd_hi);
e100_write_flush(nic);
spin_unlock_irqrestore(nic-cmd_lock, flags);
}
@@ -611,11 +614,11 @@ static void e100_hw_reset(struct nic *nic)
{
/* Put CU and RU into idle with a selective reset to get
* device off of PCI bus */
- writel(selective_reset, nic-csr-port);
+ iowrite32(selective_reset, nic-csr-port);
e100_write_flush(nic); udelay(20);
/* Now fully reset device */
- writel(software_reset, nic-csr-port);
+ iowrite32(software_reset, nic-csr-port);
e100_write_flush(nic); udelay(20);
/* Mask off our interrupt line - it's unmasked after reset */
@@ -632,7 +635,7 @@ static int e100_self_test(struct nic *nic)
nic-mem-selftest.signature = 0;
nic-mem-selftest.result = 0x;
- writel(selftest | dma_addr, nic-csr-port);
+ iowrite32(selftest | dma_addr, nic-csr-port);
e100_write_flush(nic);
/* Wait 10 msec for self-test to complete */
msleep(10);
@@ -670,23 +673,23 @@ static void e100_eeprom_write(struct nic *nic, u16
addr_len, u16 addr, u16 data)
for(j = 0; j 3; j++) {
/* Chip select */
- writeb(eecs | eesk, nic-csr-eeprom_ctrl_lo);
+ iowrite8(eecs | eesk, nic-csr-eeprom_ctrl_lo);
e100_write_flush(nic); udelay(4);
for(i = 31; i = 0; i--) {
ctrl = (cmd_addr_data[j] (1 i)) ?
eecs | eedi : eecs;
- writeb(ctrl, nic-csr-eeprom_ctrl_lo);
+ iowrite8(ctrl, nic-csr-eeprom_ctrl_lo);
e100_write_flush(nic); udelay(4);
- writeb(ctrl | eesk, nic-csr-eeprom_ctrl_lo);
+ iowrite8(ctrl | eesk, nic-csr-eeprom_ctrl_lo);
e100_write_flush(nic); udelay(4);
}
/* Wait 10 msec for cmd to complete */
msleep(10);
/* Chip deselect */
- writeb(0, nic-csr-eeprom_ctrl_lo);
+ iowrite8(0, nic-csr-eeprom_ctrl_lo);
e100_write_flush(nic); udelay(4);
}
};
@@ -702,21 +705,21 @@ static u16 e100_eeprom_read(struct nic *nic, u16
*addr_len, u16 addr)
cmd_addr_data = ((op_read *addr_len) | addr) 16;
/* Chip select */
- writeb(eecs | eesk, nic-csr-eeprom_ctrl_lo);
+ iowrite8(eecs | eesk, nic-csr-eeprom_ctrl_lo);
e100_write_flush(nic); udelay(4);
/* Bit-bang
[PATCH 1/2] e1000: ROUND_UP macro cleanup in drivers/net/e1000
From: Milind Arun Choudhary [EMAIL PROTECTED]
E1000_ROUNDUP macro cleanup, use ALIGN
Signed-off-by: Milind Arun Choudhary [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000.h |3 ---
drivers/net/e1000/e1000_ethtool.c |6 +++---
drivers/net/e1000/e1000_main.c| 10 +-
drivers/net/e1000/e1000_param.c |4 ++--
4 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index dd4b728..a9ea67e 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -155,9 +155,6 @@ struct e1000_adapter;
/* Number of packet split data buffers (not including the header buffer) */
#define PS_PAGE_BUFFERS MAX_PS_BUFFERS-1
-/* only works for sizes that are powers of 2 */
-#define E1000_ROUNDUP(i, size) ((i) = (((i) + (size) - 1) ~((size) - 1)))
-
/* wrapper around a pointer to a socket buffer,
* so a DMA handle can be stored along with the buffer */
struct e1000_buffer {
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index 6777887..0fbd873 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -686,12 +686,12 @@ e1000_set_ringparam(struct net_device *netdev,
rxdr-count = max(ring-rx_pending,(uint32_t)E1000_MIN_RXD);
rxdr-count = min(rxdr-count,(uint32_t)(mac_type e1000_82544 ?
E1000_MAX_RXD : E1000_MAX_82544_RXD));
- E1000_ROUNDUP(rxdr-count, REQ_RX_DESCRIPTOR_MULTIPLE);
+ rxdr-count = ALIGN(rxdr-count, REQ_RX_DESCRIPTOR_MULTIPLE);
txdr-count = max(ring-tx_pending,(uint32_t)E1000_MIN_TXD);
txdr-count = min(txdr-count,(uint32_t)(mac_type e1000_82544 ?
E1000_MAX_TXD : E1000_MAX_82544_TXD));
- E1000_ROUNDUP(txdr-count, REQ_TX_DESCRIPTOR_MULTIPLE);
+ txdr-count = ALIGN(txdr-count, REQ_TX_DESCRIPTOR_MULTIPLE);
for (i = 0; i adapter-num_tx_queues; i++)
txdr[i].count = txdr-count;
@@ -1068,7 +1068,7 @@ e1000_setup_desc_rings(struct e1000_adapter *adapter)
memset(txdr-buffer_info, 0, size);
txdr-size = txdr-count * sizeof(struct e1000_tx_desc);
- E1000_ROUNDUP(txdr-size, 4096);
+ txdr-size = ALIGN(txdr-size, 4096);
if (!(txdr-desc = pci_alloc_consistent(pdev, txdr-size, txdr-dma)))
{
ret_val = 2;
goto err_nomem;
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 9267f16..b9ff21f 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -748,9 +748,9 @@ e1000_reset(struct e1000_adapter *adapter)
VLAN_TAG_SIZE;
min_tx_space = min_rx_space;
min_tx_space *= 2;
- E1000_ROUNDUP(min_tx_space, 1024);
+ min_tx_space = ALIGN(min_tx_space, 1024);
min_tx_space = 10;
- E1000_ROUNDUP(min_rx_space, 1024);
+ min_rx_space = ALIGN(min_rx_space, 1024);
min_rx_space = 10;
/* If current Tx allocation is less than the min Tx FIFO size,
@@ -1560,7 +1560,7 @@ e1000_setup_tx_resources(struct e1000_adapter *adapter,
/* round up to nearest 4K */
txdr-size = txdr-count * sizeof(struct e1000_tx_desc);
- E1000_ROUNDUP(txdr-size, 4096);
+ txdr-size = ALIGN(txdr-size, 4096);
txdr-desc = pci_alloc_consistent(pdev, txdr-size, txdr-dma);
if (!txdr-desc) {
@@ -1803,7 +1803,7 @@ e1000_setup_rx_resources(struct e1000_adapter *adapter,
/* Round up to nearest 4K */
rxdr-size = rxdr-count * desc_len;
- E1000_ROUNDUP(rxdr-size, 4096);
+ rxdr-size = ALIGN(rxdr-size, 4096);
rxdr-desc = pci_alloc_consistent(pdev, rxdr-size, rxdr-dma);
@@ -3175,7 +3175,7 @@ e1000_82547_fifo_workaround(struct e1000_adapter
*adapter, struct sk_buff *skb)
uint32_t fifo_space = adapter-tx_fifo_size - adapter-tx_fifo_head;
uint32_t skb_fifo_len = skb-len + E1000_FIFO_HDR;
- E1000_ROUNDUP(skb_fifo_len, E1000_FIFO_HDR);
+ skb_fifo_len = ALIGN(skb_fifo_len, E1000_FIFO_HDR);
if (adapter-link_duplex != HALF_DUPLEX)
goto no_fifo_stall_required;
diff --git a/drivers/net/e1000/e1000_param.c b/drivers/net/e1000/e1000_param.c
index f8862e2..f485874 100644
--- a/drivers/net/e1000/e1000_param.c
+++ b/drivers/net/e1000/e1000_param.c
@@ -305,7 +305,7 @@ e1000_check_options(struct e1000_adapter *adapter)
if (num_TxDescriptors bd) {
tx_ring-count = TxDescriptors[bd];
e1000_validate_option(tx_ring-count, opt, adapter);
- E1000_ROUNDUP(tx_ring-count,
+ tx_ring-count = ALIGN(tx_ring-count,
REQ_TX_DESCRIPTOR_MULTIPLE);
} else {
tx_ring-count
[PATCH 2/2] ixgb: ROUND_UP macro cleanup in drivers/net/ixgb
From: Milind Arun Choudhary [EMAIL PROTECTED]
IXGB_ROUNDUP macro cleanup ,use ALIGN
Signed-off-by: Milind Arun Choudhary [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/ixgb/ixgb.h |3 ---
drivers/net/ixgb/ixgb_ethtool.c |4 ++--
drivers/net/ixgb/ixgb_main.c|4 ++--
drivers/net/ixgb/ixgb_param.c |4 ++--
4 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
index cf30a10..c8e9086 100644
--- a/drivers/net/ixgb/ixgb.h
+++ b/drivers/net/ixgb/ixgb.h
@@ -111,9 +111,6 @@ struct ixgb_adapter;
/* How many Rx Buffers do we bundle into one write to the hardware ? */
#define IXGB_RX_BUFFER_WRITE 8 /* Must be power of 2 */
-/* only works for sizes that are powers of 2 */
-#define IXGB_ROUNDUP(i, size) ((i) = (((i) + (size) - 1) ~((size) - 1)))
-
/* wrapper around a pointer to a socket buffer,
* so a DMA handle can be stored along with the buffer */
struct ixgb_buffer {
diff --git a/drivers/net/ixgb/ixgb_ethtool.c b/drivers/net/ixgb/ixgb_ethtool.c
index d6628bd..afde848 100644
--- a/drivers/net/ixgb/ixgb_ethtool.c
+++ b/drivers/net/ixgb/ixgb_ethtool.c
@@ -577,11 +577,11 @@ ixgb_set_ringparam(struct net_device *netdev,
rxdr-count = max(ring-rx_pending,(uint32_t)MIN_RXD);
rxdr-count = min(rxdr-count,(uint32_t)MAX_RXD);
- IXGB_ROUNDUP(rxdr-count, IXGB_REQ_RX_DESCRIPTOR_MULTIPLE);
+ rxdr-count = ALIGN(rxdr-count, IXGB_REQ_RX_DESCRIPTOR_MULTIPLE);
txdr-count = max(ring-tx_pending,(uint32_t)MIN_TXD);
txdr-count = min(txdr-count,(uint32_t)MAX_TXD);
- IXGB_ROUNDUP(txdr-count, IXGB_REQ_TX_DESCRIPTOR_MULTIPLE);
+ txdr-count = ALIGN(txdr-count, IXGB_REQ_TX_DESCRIPTOR_MULTIPLE);
if(netif_running(adapter-netdev)) {
/* Try to get new resources before deleting old */
diff --git a/drivers/net/ixgb/ixgb_main.c b/drivers/net/ixgb/ixgb_main.c
index dfde80e..6d2b059 100644
--- a/drivers/net/ixgb/ixgb_main.c
+++ b/drivers/net/ixgb/ixgb_main.c
@@ -685,7 +685,7 @@ ixgb_setup_tx_resources(struct ixgb_adapter *adapter)
/* round up to nearest 4K */
txdr-size = txdr-count * sizeof(struct ixgb_tx_desc);
- IXGB_ROUNDUP(txdr-size, 4096);
+ txdr-size = ALIGN(txdr-size, 4096);
txdr-desc = pci_alloc_consistent(pdev, txdr-size, txdr-dma);
if(!txdr-desc) {
@@ -774,7 +774,7 @@ ixgb_setup_rx_resources(struct ixgb_adapter *adapter)
/* Round up to nearest 4K */
rxdr-size = rxdr-count * sizeof(struct ixgb_rx_desc);
- IXGB_ROUNDUP(rxdr-size, 4096);
+ rxdr-size = ALIGN(rxdr-size, 4096);
rxdr-desc = pci_alloc_consistent(pdev, rxdr-size, rxdr-dma);
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index b27442a..ee8cc67 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -284,7 +284,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
} else {
tx_ring-count = opt.def;
}
- IXGB_ROUNDUP(tx_ring-count, IXGB_REQ_TX_DESCRIPTOR_MULTIPLE);
+ tx_ring-count = ALIGN(tx_ring-count,
IXGB_REQ_TX_DESCRIPTOR_MULTIPLE);
}
{ /* Receive Descriptor Count */
struct ixgb_option opt = {
@@ -303,7 +303,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
} else {
rx_ring-count = opt.def;
}
- IXGB_ROUNDUP(rx_ring-count, IXGB_REQ_RX_DESCRIPTOR_MULTIPLE);
+ rx_ring-count = ALIGN(rx_ring-count,
IXGB_REQ_RX_DESCRIPTOR_MULTIPLE);
}
{ /* Receive Checksum Offload Enable */
struct ixgb_option opt = {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e100: disable interrupts at boot
Roland Dreier wrote: + case 0x1030 ... 0x1034: Do we use the gcc case range extension in the kernel? (This is an honest question -- I don't think I've seen it used anywhere, and I'd be curious to know what the taste arbiters think of it) I'm not a fan of it either but it is used already in plenty locations. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] 2.6.16 -- redundant inclusion of header file in kernel/profile.c
S P wrote: signed off by: S. P. [EMAIL PROTECTED] without a real name this shouldn't be accepted. Also try not to send base-64 encoded, it really looks like spam to me. Even no-brainers should include a decent signed-off line. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] e1000: Driver fixes and update to 7.0.38-k2
Jeff Garzik wrote:
Kok, Auke wrote:
01/10: [FIX] Remove PM warning DPRINTKs breaking 2.4.x kernels
02/10: [FIX] Esb2 wol link cycle bug and uninitialized registers
03/10: [PATCH] De-inline functions to benefit from compiler smartness
04/10: [PATCH] Made an adapter struct variable into a local (txb2b)
05/10: [PATCH] Update truesize with the length of the packet for
packet split
06/10: [PATCH] Dead variable cleanup
07/10: [PATCH] Buffer optimizations for small MTU
08/10: [PATCH] implement more efficient tx queue locking
09/10: [DOC] Version bump, contact fix, year string change
10/10: [MAINTAINERS] {e100{,0},ixgb}: Add Auke Kok as new patch
maintainer
These 10 patches look OK, but since the current kernel version is
2.6.17-rc1, that means we are in bug fix only mode right now.
Should I (a) apply these all to netdev2-.6.git#upstream, queueing them
for 2.6.18, or (b) let you split the submission into two parts, bug
fixes only and everything else?
jeff,
The two fixes are for low-impact bugs with workarounds, not justifying
applying them to 2.6.17-rc1 or [EMAIL PROTECTED]
Please apply to netdev-2.6.git#upstream and queue them for 2.6.18. (a).
Cheers,
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
Alexey Dobriyan wrote:
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Remove it and use ARRAY_SIZE instead.
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
+#define LIST_LEN(l) ARRAY_SIZE(l)
yes, well spotted. Please change line 338 in this file to read:
.arg = { .l = { .nr = ARRAY_SIZE(fc_list),
instead, so you can remove the LIST_LEN macro completely.
Thanks,
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 01/11] user of the jiffies rounding code: Networking
David Miller wrote: From: [EMAIL PROTECTED] Date: Mon, 05 Feb 2007 16:30:52 -0800 From: Arjan van de Ven [EMAIL PROTECTED] This patch introduces users of the round_jiffies() function in the networking code. These timers all were of the about once a second or about once every X seconds variety and several showed up in the what wakes the cpu up profiles that the tickless patches provide. Some timers are highly dynamic based on network load; but even on low activity systems they still show up so the rounding is done only in cases of low activity, allowing higher frequency timers in the high activity case. The various hardware watchdogs are an obvious case; they run every 2 seconds but aren't otherwise specific of exactly when they need to run. Signed-off-by: Arjan van de Ven [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] I pulled in everything except the e1000 driver change, Jeff please suck that in, thanks. Jeff, And add my: Acked-by: Auke Kok [EMAIL PROTECTED] Thanks Auke Arjan, btw: + if (dst_gc_timer_expires 4*HZ) + mod_timer(dst_gc_timer, + round_jiffies(jiffies + dst_gc_timer_expires)); + else + mod_timer(dst_gc_timer, jiffies + dst_gc_timer_expires); ^ That line begins TAB SPACE TAB, and lo' and behold GIT catch this when I applied it :-) I fixed it up by hand and reapplied, so don't worry about this instance. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20] ixgb: Use ARRAY_SIZE macro when appropriate
Ahmed S. Darwish wrote:
On Mon, Feb 05, 2007 at 12:31:26PM -0800, Auke Kok wrote:
Alexey Dobriyan wrote:
On Mon, Feb 05, 2007 at 06:59:33PM +0200, Ahmed S. Darwish wrote:
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Remove it and use ARRAY_SIZE instead.
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,7 +245,7 @@ ixgb_validate_option(int *value, struct ixgb_option
*opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
+#define LIST_LEN(l) ARRAY_SIZE(l)
yes, well spotted. Please change line 338 in this file to read:
.arg = { .l = { .nr = ARRAY_SIZE(fc_list),
instead, so you can remove the LIST_LEN macro completely.
Thanks, Here's the new patch.
Use ARRAY_SIZE macro when appropriate.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
Acked-by: Auke Kok [EMAIL PROTECTED]
Cheers,
Auke
---
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index b27442a..c38ce73 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,8 +245,6 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
-
/**
* ixgb_check_options - Range Checking for Command Line Parameters
* @adapter: board private structure
@@ -335,7 +333,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
.name = Flow Control,
.err = reading default settings from EEPROM,
.def = ixgb_fc_tx_pause,
- .arg = { .l = { .nr = LIST_LEN(fc_list),
+ .arg = { .l = { .nr = ARRAY_SIZE(fc_list),
.p = fc_list }}
};
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.20] e1000: Use ARRAY_SIZE macro when appropriate
Ahmed S. Darwish wrote:
Hi,
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
Acked-by: Auke Kok [EMAIL PROTECTED]
Cheers,
Auke
---
Patch is compile tested.
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index fb96c87..d21706e 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -746,7 +746,7 @@ err_setup:
uint32_t pat, value; \
uint32_t test[] = \
{0x5A5A5A5A, 0xA5A5A5A5, 0x, 0x}; \
- for (pat = 0; pat sizeof(test)/sizeof(test[0]); pat++) {
\
+ for (pat = 0; pat ARRAY_SIZE(test); pat++) { \
E1000_WRITE_REG(adapter-hw, R, (test[pat] W)); \
value = E1000_READ_REG(adapter-hw, R); \
if (value != (test[pat] W M)) {
\
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] e1000: fix shared interrupt warning message
Jeff Garzik wrote: Kok, Auke wrote: Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) applied 1-3, though patch #1 had a noticable lack of description. you should describe your change, not just the condition that prompted it. operation reordering is something that people shouldn't have to /try/ to understand. Things should just be obvious, and if not, document why. For the record then: It is suspected that workarounds in the _up() routine of e1000 can cause the receive unit to be enabled before we're all done initializing the adapter data. An interrupt arriving before we're all done setting up obviously causes problems. To fix, we postpone enabling interrupts completely until the software intialization is finished. Thanks, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] e1000: fix shared interrupt warning message
Francois Romieu wrote: Auke Kok [EMAIL PROTECTED] : [...] It is suspected that workarounds in the _up() routine of e1000 can cause ^ the receive unit to be enabled before we're all done initializing the adapter data. An interrupt arriving before we're all done setting up obviously causes problems. To fix, we postpone enabling interrupts completely until the software intialization is finished. Call me dense but is there a chance that the same receive unit that should not be enabled now emits interrupts between e1000_up() and request_irq() ? turning on the receive unit starts the rx logic on the mac, but doesn't make the mac generate interrupts as far as I know. The fix was verified and even suggested earlier by some people as well. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] remove irq_sem cruft from e1000 and derivatives
Chris Snook wrote: Hey folks -- While digging through the atl1 source, I was troubled by the code using irq_sem. I did some digging and found the same code in e1000 and ixgb. I'm not entirely sure what it was originally intended to do, but it doesn't seem to be doing anything useful now, except possibly locking interrupts off if NAPI is flipped on and off enough times to cause an integer overflow. The following patches completely remove irq_sem from each of the drivers. This has been tested successfully on atl1 and e1000. If someone would like to send me ixgb hardware I'd be glad to test that, otherwise you'll have to test it yourself. :) -- Chris I'm not yet seeing patches 1/3 appear, but I'll certainly take a look at them and have them tested in our labs once they appear for e1000 and ixgb. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: watchdog timeout panic in e1000 driver
Kenzo Iwami wrote:
Hi,
I created a patch that uses watchdog_task but fixes the race condition
that occurred in old the e1000 driver.
I've obtained information about the panic caused by the old e1000 driver
using e1000_watchdog_task. According to the crash dump, the panic was
caused by a timer_list whose contents were NULLs. Further trace
information revealed that the function in the timer list was
e1000_watchdog().
This function is registered in timer_list during e1000_watchdog_task.
It seems that e1000_watchdog_task could be called after the adapter is
removed, and freed memory is registered to timer_list.
By looking at the source code, e1000_watchdog_task will be scheduled if
e1000_watchdog is invoked during e1000_remove, after flush_scheduled_work()
is called, but before del_timer_sync() is called in e1000_down().
The attached patch adds back the e1000_watchdog_task(), but it will
prevent the old race condition from happening by deleting e1000_watchdog
from timer_list before flush_scheduled_work() is called.
Kenzo,
this looks a lot better than the previous patch!! However, we already have a
state marker for _down_ that we should probably reuse. Can you try the attached
patch and see if it works for you? It's basically your patch without the added
remove flag and instead using the already available atomic state trackers.
If this works for you then that is great news and I'll push this patch to the
upstream kernel maintainers after testing.
Cheers,
Auke
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 689f158..bd4026d 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -264,6 +264,7 @@ struct e1000_adapter {
uint16_t rx_itr;
struct work_struct reset_task;
+ struct work_struct watchdog_task;
uint8_t fc_autoneg;
struct timer_list blink_timer;
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 619c892..0548e65 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -152,6 +152,7 @@ static void e1000_clean_rx_ring(struct e1000_adapter *adapter,
static void e1000_set_multi(struct net_device *netdev);
static void e1000_update_phy_info(unsigned long data);
static void e1000_watchdog(unsigned long data);
+static void e1000_watchdog_task(struct work_struct *work);
static void e1000_82547_tx_fifo_stall(unsigned long data);
static int e1000_xmit_frame(struct sk_buff *skb, struct net_device *netdev);
static struct net_device_stats * e1000_get_stats(struct net_device *netdev);
@@ -1049,6 +1050,7 @@ e1000_probe(struct pci_dev *pdev,
adapter-phy_info_timer.data = (unsigned long) adapter;
INIT_WORK(adapter-reset_task, e1000_reset_task);
+ INIT_WORK(adapter-watchdog_task, e1000_watchdog_task);
e1000_check_options(adapter);
@@ -1216,6 +1218,11 @@ e1000_remove(struct pci_dev *pdev)
int i;
#endif
+ /* flush_scheduled work may reschedule our watchdog task, so
+ * explicitly disable watchdog tasks from being rescheduled */
+ set_bit(__E1000_DOWN, adapter-flags);
+ del_timer_sync(adapter-watchdog_timer);
+
flush_scheduled_work();
e1000_release_manageability(adapter);
@@ -2551,6 +2558,17 @@ static void
e1000_watchdog(unsigned long data)
{
struct e1000_adapter *adapter = (struct e1000_adapter *) data;
+
+ /* Do the rest outside of interrupt context */
+ schedule_work(adapter-watchdog_task);
+}
+
+static void
+e1000_watchdog_task(struct work_struct *work)
+{
+ struct e1000_adapter *adapter = container_of(work,
+ struct e1000_adapter, watchdog_task);
+
struct net_device *netdev = adapter-netdev;
struct e1000_tx_ring *txdr = adapter-tx_ring;
uint32_t link, tctl;
@@ -2721,7 +2739,8 @@ e1000_watchdog(unsigned long data)
e1000_rar_set(adapter-hw, adapter-hw.mac_addr, 0);
/* Reset the timer */
- mod_timer(adapter-watchdog_timer, jiffies + 2 * HZ);
+ if (!test_bit(__E1000_DOWN, adapter-flags))
+ mod_timer(adapter-watchdog_timer, jiffies + 2 * HZ);
}
enum latency_range {
[PATCH 3/3] e1000: list e1000-devel mailing list in MAINTAINERS
From: Auke Kok [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- MAINTAINERS |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1dfba85..51efc71 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1797,6 +1797,7 @@ P:Jeff Kirsher M: [EMAIL PROTECTED] P: Auke Kok M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ S: Supported @@ -1811,6 +1812,7 @@ P:Jeff Kirsher M: [EMAIL PROTECTED] P: Auke Kok M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ S: Supported @@ -1825,6 +1827,7 @@ P:Jesse Brandeburg M: [EMAIL PROTECTED] P: Auke Kok M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] W: http://sourceforge.net/projects/e1000/ S: Supported - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] e1000: Use ARRAY_SIZE macro when appropriate
From: Ahmed S. Darwish [EMAIL PROTECTED]
A patch to use ARRAY_SIZE macro already defined in kernel.h.
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_ethtool.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index 6777887..a094288 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -742,7 +742,7 @@ err_setup:
uint32_t pat, value; \
uint32_t test[] = \
{0x5A5A5A5A, 0xA5A5A5A5, 0x, 0x}; \
- for (pat = 0; pat sizeof(test)/sizeof(test[0]); pat++) {
\
+ for (pat = 0; pat ARRAY_SIZE(test); pat++) { \
E1000_WRITE_REG(adapter-hw, R, (test[pat] W)); \
value = E1000_READ_REG(adapter-hw, R); \
if (value != (test[pat] W M)) {
\
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] e1000: Use kcalloc()
From: Yan Burman [EMAIL PROTECTED]
Replace kmalloc+memsetout the driver. Slightly modified by Auke Kok.
Signed-off-by: Yan Burman [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_ethtool.c | 26 --
drivers/net/e1000/e1000_main.c| 29 -
2 files changed, 24 insertions(+), 31 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index a094288..2881da1 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -654,14 +654,11 @@ e1000_set_ringparam(struct net_device *netdev,
e1000_mac_type mac_type = adapter-hw.mac_type;
struct e1000_tx_ring *txdr, *tx_old;
struct e1000_rx_ring *rxdr, *rx_old;
- int i, err, tx_ring_size, rx_ring_size;
+ int i, err;
if ((ring-rx_mini_pending) || (ring-rx_jumbo_pending))
return -EINVAL;
- tx_ring_size = sizeof(struct e1000_tx_ring) * adapter-num_tx_queues;
- rx_ring_size = sizeof(struct e1000_rx_ring) * adapter-num_rx_queues;
-
while (test_and_set_bit(__E1000_RESETTING, adapter-flags))
msleep(1);
@@ -672,11 +669,11 @@ e1000_set_ringparam(struct net_device *netdev,
rx_old = adapter-rx_ring;
err = -ENOMEM;
- txdr = kzalloc(tx_ring_size, GFP_KERNEL);
+ txdr = kcalloc(adapter-num_tx_queues, sizeof(struct e1000_tx_ring),
GFP_KERNEL);
if (!txdr)
goto err_alloc_tx;
- rxdr = kzalloc(rx_ring_size, GFP_KERNEL);
+ rxdr = kcalloc(adapter-num_rx_queues, sizeof(struct e1000_rx_ring),
GFP_KERNEL);
if (!rxdr)
goto err_alloc_rx;
@@ -1053,23 +1050,24 @@ e1000_setup_desc_rings(struct e1000_adapter *adapter)
struct e1000_rx_ring *rxdr = adapter-test_rx_ring;
struct pci_dev *pdev = adapter-pdev;
uint32_t rctl;
- int size, i, ret_val;
+ int i, ret_val;
/* Setup Tx descriptor ring and Tx buffers */
if (!txdr-count)
txdr-count = E1000_DEFAULT_TXD;
- size = txdr-count * sizeof(struct e1000_buffer);
- if (!(txdr-buffer_info = kmalloc(size, GFP_KERNEL))) {
+ if (!(txdr-buffer_info = kcalloc(txdr-count,
+ sizeof(struct e1000_buffer),
+ GFP_KERNEL))) {
ret_val = 1;
goto err_nomem;
}
- memset(txdr-buffer_info, 0, size);
txdr-size = txdr-count * sizeof(struct e1000_tx_desc);
E1000_ROUNDUP(txdr-size, 4096);
- if (!(txdr-desc = pci_alloc_consistent(pdev, txdr-size, txdr-dma)))
{
+ if (!(txdr-desc = pci_alloc_consistent(pdev, txdr-size,
+ txdr-dma))) {
ret_val = 2;
goto err_nomem;
}
@@ -1116,12 +1114,12 @@ e1000_setup_desc_rings(struct e1000_adapter *adapter)
if (!rxdr-count)
rxdr-count = E1000_DEFAULT_RXD;
- size = rxdr-count * sizeof(struct e1000_buffer);
- if (!(rxdr-buffer_info = kmalloc(size, GFP_KERNEL))) {
+ if (!(rxdr-buffer_info = kcalloc(rxdr-count,
+ sizeof(struct e1000_buffer),
+ GFP_KERNEL))) {
ret_val = 4;
goto err_nomem;
}
- memset(rxdr-buffer_info, 0, size);
rxdr-size = rxdr-count * sizeof(struct e1000_rx_desc);
if (!(rxdr-desc = pci_alloc_consistent(pdev, rxdr-size, rxdr-dma)))
{
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 7bbefca..530d5d7 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1354,31 +1354,27 @@ e1000_sw_init(struct e1000_adapter *adapter)
static int __devinit
e1000_alloc_queues(struct e1000_adapter *adapter)
{
- int size;
-
- size = sizeof(struct e1000_tx_ring) * adapter-num_tx_queues;
- adapter-tx_ring = kmalloc(size, GFP_KERNEL);
+ adapter-tx_ring = kcalloc(adapter-num_tx_queues,
+ sizeof(struct e1000_tx_ring), GFP_KERNEL);
if (!adapter-tx_ring)
return -ENOMEM;
- memset(adapter-tx_ring, 0, size);
- size = sizeof(struct e1000_rx_ring) * adapter-num_rx_queues;
- adapter-rx_ring = kmalloc(size, GFP_KERNEL);
+ adapter-rx_ring = kcalloc(adapter-num_rx_queues,
+ sizeof(struct e1000_rx_ring), GFP_KERNEL);
if (!adapter-rx_ring) {
kfree(adapter-tx_ring);
return -ENOMEM;
}
- memset(adapter-rx_ring, 0, size);
#ifdef CONFIG_E1000_NAPI
- size = sizeof(struct net_device) * adapter-num_rx_queues;
- adapter-polling_netdev = kmalloc(size, GFP_KERNEL);
+ adapter-polling_netdev = kcalloc(adapter-num_rx_queues
[PATCH] ixgb: Use ARRAY_SIZE macro when appropriate.
From: Ahmed S. Darwish [EMAIL PROTECTED]
Signed-off-by: Ahmed S. Darwish [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/ixgb/ixgb_param.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgb/ixgb_param.c b/drivers/net/ixgb/ixgb_param.c
index b27442a..c38ce73 100644
--- a/drivers/net/ixgb/ixgb_param.c
+++ b/drivers/net/ixgb/ixgb_param.c
@@ -245,8 +245,6 @@ ixgb_validate_option(int *value, struct ixgb_option *opt)
return -1;
}
-#define LIST_LEN(l) (sizeof(l) / sizeof(l[0]))
-
/**
* ixgb_check_options - Range Checking for Command Line Parameters
* @adapter: board private structure
@@ -335,7 +333,7 @@ ixgb_check_options(struct ixgb_adapter *adapter)
.name = Flow Control,
.err = reading default settings from EEPROM,
.def = ixgb_fc_tx_pause,
- .arg = { .l = { .nr = LIST_LEN(fc_list),
+ .arg = { .l = { .nr = ARRAY_SIZE(fc_list),
.p = fc_list }}
};
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] e1000: FIX: be ready for incoming irq at pci_request_irq
From: Auke Kok [EMAIL PROTECTED]
DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts
after having called pci_request_irq. This obviously requires us to finish
our software setup which assigns the irq handler before we request the
irq.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c | 66 +++-
1 files changed, 45 insertions(+), 21 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 98215fd..fff3bc0 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -522,14 +522,15 @@ e1000_release_manageability(struct e1000_adapter *adapter)
}
}
-int
-e1000_up(struct e1000_adapter *adapter)
+/**
+ * e1000_configure - configure the hardware for RX and TX
+ * @adapter = private board structure
+ **/
+static void e1000_configure(struct e1000_adapter *adapter)
{
struct net_device *netdev = adapter-netdev;
int i;
- /* hardware has been reset, we need to reload some things */
-
e1000_set_multi(netdev);
e1000_restore_vlan(adapter);
@@ -548,14 +549,20 @@ e1000_up(struct e1000_adapter *adapter)
}
adapter-tx_queue_len = netdev-tx_queue_len;
+}
+
+int e1000_up(struct e1000_adapter *adapter)
+{
+ /* hardware has been reset, we need to reload some things */
+ e1000_configure(adapter);
+
+ clear_bit(__E1000_DOWN, adapter-flags);
#ifdef CONFIG_E1000_NAPI
- netif_poll_enable(netdev);
+ netif_poll_enable(adapter-netdev);
#endif
e1000_irq_enable(adapter);
- clear_bit(__E1000_DOWN, adapter-flags);
-
/* fire a link change interrupt to start the watchdog */
E1000_WRITE_REG(adapter-hw, ICS, E1000_ICS_LSC);
return 0;
@@ -640,15 +647,15 @@ e1000_down(struct e1000_adapter *adapter)
* reschedule our watchdog timer */
set_bit(__E1000_DOWN, adapter-flags);
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_disable(netdev);
+#endif
e1000_irq_disable(adapter);
del_timer_sync(adapter-tx_fifo_stall_timer);
del_timer_sync(adapter-watchdog_timer);
del_timer_sync(adapter-phy_info_timer);
-#ifdef CONFIG_E1000_NAPI
- netif_poll_disable(netdev);
-#endif
netdev-tx_queue_len = adapter-tx_queue_len;
adapter-link_speed = 0;
adapter-link_duplex = 0;
@@ -1410,21 +1417,17 @@ e1000_open(struct net_device *netdev)
return -EBUSY;
/* allocate transmit descriptors */
- if ((err = e1000_setup_all_tx_resources(adapter)))
+ err = e1000_setup_all_tx_resources(adapter);
+ if (err)
goto err_setup_tx;
/* allocate receive descriptors */
- if ((err = e1000_setup_all_rx_resources(adapter)))
- goto err_setup_rx;
-
- err = e1000_request_irq(adapter);
+ err = e1000_setup_all_rx_resources(adapter);
if (err)
- goto err_req_irq;
+ goto err_setup_rx;
e1000_power_up_phy(adapter);
- if ((err = e1000_up(adapter)))
- goto err_up;
adapter-mng_vlan_id = E1000_MNG_VLAN_NONE;
if ((adapter-hw.mng_cookie.status
E1000_MNG_DHCP_COOKIE_STATUS_VLAN_SUPPORT)) {
@@ -1437,12 +1440,33 @@ e1000_open(struct net_device *netdev)
e1000_check_mng_mode(adapter-hw))
e1000_get_hw_control(adapter);
+ /* before we allocate an interrupt, we must be ready to handle it.
+* Setting DEBUG_SHIRQ in the kernel makes it fire an interrupt
+* as soon as we call pci_request_irq, so we have to setup our
+* clean_rx handler before we do so. */
+ e1000_configure(adapter);
+
+ err = e1000_request_irq(adapter);
+ if (err)
+ goto err_req_irq;
+
+ /* From here on the code is the same as e1000_up() */
+ clear_bit(__E1000_DOWN, adapter-flags);
+
+#ifdef CONFIG_E1000_NAPI
+ netif_poll_enable(netdev);
+#endif
+
+ e1000_irq_enable(adapter);
+
+ /* fire a link status change interrupt to start the watchdog */
+ E1000_WRITE_REG(adapter-hw, ICS, E1000_ICS_LSC);
+
return E1000_SUCCESS;
-err_up:
- e1000_power_down_phy(adapter);
- e1000_free_irq(adapter);
err_req_irq:
+ e1000_release_hw_control(adapter);
+ e1000_power_down_phy(adapter);
e1000_free_all_rx_resources(adapter);
err_setup_rx:
e1000_free_all_tx_resources(adapter);
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] e1000: FIX: Stop raw interrupts disabled nag from RT
From: Mark Huth [EMAIL PROTECTED]
Current e1000_xmit_frame spews raw interrupt disabled nag messages when
used with RT kernel patches. This patch uses spin_trylock_irqsave,
which allows RT patches to properly manage the irq semantics.
Signed-off-by: Mark Huth [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 3492f0b..7bbefca 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -3378,12 +3378,9 @@ e1000_xmit_frame(struct sk_buff *skb, struct net_device
*netdev)
(adapter-hw.mac_type == e1000_82573))
e1000_transfer_dhcp_info(adapter, skb);
- local_irq_save(flags);
- if (!spin_trylock(tx_ring-tx_lock)) {
+ if (!spin_trylock_irqsave(tx_ring-tx_lock, flags))
/* Collision - tell upper layer to requeue */
- local_irq_restore(flags);
return NETDEV_TX_LOCKED;
- }
/* need: count + 2 desc gap to keep tail from touching
* head, otherwise try next time */
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] e1000: FIX: firmware handover bits
From: Bruce Allan [EMAIL PROTECTED]
Upon code inspection it was spotted that the firmware handover bit get/set
mismatched, which may have resulted in management issues on PCI-E
adapters. Setting them correctly may fix some management issues such
as arp routing etc.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Signed-off-by: Bruce Allan [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_main.c | 33 -
1 files changed, 12 insertions(+), 21 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index fff3bc0..3492f0b 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -409,25 +409,21 @@ e1000_release_hw_control(struct e1000_adapter *adapter)
{
uint32_t ctrl_ext;
uint32_t swsm;
- uint32_t extcnf;
/* Let firmware taken over control of h/w */
switch (adapter-hw.mac_type) {
- case e1000_82571:
- case e1000_82572:
- case e1000_80003es2lan:
- ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
- E1000_WRITE_REG(adapter-hw, CTRL_EXT,
- ctrl_ext ~E1000_CTRL_EXT_DRV_LOAD);
- break;
case e1000_82573:
swsm = E1000_READ_REG(adapter-hw, SWSM);
E1000_WRITE_REG(adapter-hw, SWSM,
swsm ~E1000_SWSM_DRV_LOAD);
+ break;
+ case e1000_82571:
+ case e1000_82572:
+ case e1000_80003es2lan:
case e1000_ich8lan:
- extcnf = E1000_READ_REG(adapter-hw, CTRL_EXT);
+ ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
E1000_WRITE_REG(adapter-hw, CTRL_EXT,
- extcnf ~E1000_CTRL_EXT_DRV_LOAD);
+ ctrl_ext ~E1000_CTRL_EXT_DRV_LOAD);
break;
default:
break;
@@ -450,26 +446,21 @@ e1000_get_hw_control(struct e1000_adapter *adapter)
{
uint32_t ctrl_ext;
uint32_t swsm;
- uint32_t extcnf;
/* Let firmware know the driver has taken over */
switch (adapter-hw.mac_type) {
- case e1000_82571:
- case e1000_82572:
- case e1000_80003es2lan:
- ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
- E1000_WRITE_REG(adapter-hw, CTRL_EXT,
- ctrl_ext | E1000_CTRL_EXT_DRV_LOAD);
- break;
case e1000_82573:
swsm = E1000_READ_REG(adapter-hw, SWSM);
E1000_WRITE_REG(adapter-hw, SWSM,
swsm | E1000_SWSM_DRV_LOAD);
break;
+ case e1000_82571:
+ case e1000_82572:
+ case e1000_80003es2lan:
case e1000_ich8lan:
- extcnf = E1000_READ_REG(adapter-hw, EXTCNF_CTRL);
- E1000_WRITE_REG(adapter-hw, EXTCNF_CTRL,
- extcnf | E1000_EXTCNF_CTRL_SWFLAG);
+ ctrl_ext = E1000_READ_REG(adapter-hw, CTRL_EXT);
+ E1000_WRITE_REG(adapter-hw, CTRL_EXT,
+ ctrl_ext | E1000_CTRL_EXT_DRV_LOAD);
break;
default:
break;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/21] e1000: disable CRC stripping workaround
Ben Greear wrote: Kok, Auke wrote: CRC stripping is breaking SMBUS-connected BMC's. We disable this feature to make it work. This fixes related bugs regarding SOL. Shouldn't you also have to subtract 4 bytes when setting the skb len in the receive logic? Perhaps when setting the rx-bytes counter as well? the hardware corrects for the size properly when we disable CRC stripping. The end result is the same. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: e1000: Janitor: Use #defined values for literals
Linas Vepstas wrote: Minor janitorial patch: use #defines for literal values. Signed-off-by: Linas Vepstas [EMAIL PROTECTED] Ack! I thought we had gotten these out already. Cheers, Auke drivers/net/e1000/e1000_main.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6.17-rc6-mm2/drivers/net/e1000/e1000_main.c === --- linux-2.6.17-rc6-mm2.orig/drivers/net/e1000/e1000_main.c2006-06-13 18:13:30.0 -0500 +++ linux-2.6.17-rc6-mm2/drivers/net/e1000/e1000_main.c 2006-06-23 11:27:47.0 -0500 @@ -4663,8 +4663,8 @@ static pci_ers_result_t e1000_io_slot_re } pci_set_master(pdev); - pci_enable_wake(pdev, 3, 0); - pci_enable_wake(pdev, 4, 0); /* 4 == D3 cold */ + pci_enable_wake(pdev, PCI_D3hot, 0); + pci_enable_wake(pdev, PCI_D3cold, 0); /* Perform card reset only on one instance of the card */ if (PCI_FUNC (pdev-devfn) != 0) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/21] e1000: allow user to disable ich8 lock loss workaround
Jeff Garzik wrote: Kok, Auke wrote: The workaround for the ich8 lock loss problem is only needed for a very small amount of systems. This adds an option for the user to disable the workaround. Does very small amount equate to never in real production machines? Unfortunately not. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/21] e1000: add E1000_BIG_ENDIAN symbol
Jeff Garzik wrote:
Kok, Auke wrote:
This adds a private symbol to signify endianess in our driver.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.h|2 +-
drivers/net/e1000/e1000_osdep.h |3 +++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
index 941b47d..376a2ef 100644
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -351,7 +351,7 @@ struct e1000_host_mng_command_info {
struct e1000_host_mng_command_header command_header; /* Command
Head/Command Result Head has 4 bytes */
uint8_t command_data[E1000_HI_MAX_MNG_DATA_LENGTH]; /* Command
data can length 0..0x658*/
};
-#ifdef __BIG_ENDIAN
+#ifdef E1000_BIG_ENDIAN
struct e1000_host_mng_dhcp_cookie{
uint32_t signature;
uint16_t vlan_id;
diff --git a/drivers/net/e1000/e1000_osdep.h
b/drivers/net/e1000/e1000_osdep.h
index 048d052..6130a42 100644
--- a/drivers/net/e1000/e1000_osdep.h
+++ b/drivers/net/e1000/e1000_osdep.h
@@ -83,6 +83,9 @@ typedef enum {
#define DEBUGOUT3 DEBUGOUT2
#define DEBUGOUT7 DEBUGOUT3
+#ifdef __BIG_ENDIAN
+#define E1000_BIG_ENDIAN __BIG_ENDIAN
+#endif
NAK. This is backwards: We don't need wrappers for symbols that the
kernel already provides.
Agreed, I deleted it from our git server.
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/21] e1000: disable CRC stripping workaround
Jeff Garzik wrote: Kok, Auke wrote: CRC stripping is breaking SMBUS-connected BMC's. We disable this feature to make it work. This fixes related bugs regarding SOL. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/e1000_main.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index c44ed6f..7787299 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -1628,8 +1628,11 @@ e1000_setup_rctl(struct e1000_adapter *a E1000_RCTL_LBM_NO | E1000_RCTL_RDMTS_HALF | (adapter-hw.mc_filter_type E1000_RCTL_MO_SHIFT); +/* disable hardware stripping of CRC because it breaks + * BMC firmware connected over SMBUS if (adapter-hw.mac_type e1000_82543) rctl |= E1000_RCTL_SECRC; + */ if (adapter-hw.tbi_compatibility_on == 1) rctl |= E1000_RCTL_SBP; @@ -1696,7 +1699,9 @@ e1000_setup_rctl(struct e1000_adapter *a rfctl |= E1000_RFCTL_IPV6_DIS; E1000_WRITE_REG(adapter-hw, RFCTL, rfctl); -rctl |= E1000_RCTL_DTYP_PS | E1000_RCTL_SECRC; +/* disable the stripping of CRC because it breaks + * BMC firmware connected over SMBUS */ +rctl |= E1000_RCTL_DTYP_PS /* | E1000_RCTL_SECRC */; This is quite ugly. You are basically bloating the code with historic, dead code, no different than filling the e1000/*.c with '#if 0' regions. Just delete it, and explain why in the patch description. Adjusted the patch on our git server to this: diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c index c44ed6f..a9e55dc 100644 --- a/drivers/net/e1000/e1000_main.c +++ b/drivers/net/e1000/e1000_main.c @@ -1628,9 +1628,6 @@ e1000_setup_rctl(struct e1000_adapter *a E1000_RCTL_LBM_NO | E1000_RCTL_RDMTS_HALF | (adapter-hw.mc_filter_type E1000_RCTL_MO_SHIFT); - if (adapter-hw.mac_type e1000_82543) - rctl |= E1000_RCTL_SECRC; - if (adapter-hw.tbi_compatibility_on == 1) rctl |= E1000_RCTL_SBP; else @@ -1696,7 +1693,7 @@ e1000_setup_rctl(struct e1000_adapter *a rfctl |= E1000_RFCTL_IPV6_DIS; E1000_WRITE_REG(adapter-hw, RFCTL, rfctl); - rctl |= E1000_RCTL_DTYP_PS | E1000_RCTL_SECRC; + rctl |= E1000_RCTL_DTYP_PS; psrctl |= adapter-rx_ps_bsize0 E1000_PSRCTL_BSIZE0_SHIFT; Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/21] e1000: force register write flushes to circumvent broken platforms
Jeff Garzik wrote:
Kok, Auke wrote:
A certain AMD64 bridge (8132) has an option to turn on write combining
which breaks our adapter. To circumvent this we need to flush every
write.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.c | 24 ++--
drivers/net/e1000/e1000_main.c | 18 +++---
2 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index 3959039..749d621 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -705,8 +705,12 @@ e1000_init_hw(struct e1000_hw *hw)
/* Zero out the Multicast HASH table */
DEBUGOUT(Zeroing the MTA\n);
mta_size = E1000_MC_TBL_SIZE;
-for(i = 0; i mta_size; i++)
+for(i = 0; i mta_size; i++) {
E1000_WRITE_REG_ARRAY(hw, MTA, i, 0);
+/* use write flush to prevent Memory Write Block (MWB) from
+ * occuring when accessing our register space */
+E1000_WRITE_FLUSH(hw);
+}
NAK. We can't crap up every driver just for one weird piece of hardware.
If this problem falls outside the grounds of mmiowb() [see
Documentation/memory-barriers.txt], then other solutions need to be
looked into... ioremap_nocache() ? Tweaking the MTRR for this region?
Chipset quirk? ...
If there is an in-kernel fix for this that would make these flushes obsolete I
would certainly prefer it too, unfortunately we can't fix already released
kernels and our driver still needs to work there too, so that's why I queued
it. It can be dropped from this series if that's preferred.
Cheers,
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/21] e1000: add smart power down code
Jeff Garzik wrote: Kok, Auke wrote: Smart Power Down is a power saving feature in newer e1000 hardware. We disable it because it causes time to link to be long, but make it a user choice. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/e1000.h |1 + drivers/net/e1000/e1000_main.c | 15 +++ drivers/net/e1000/e1000_param.c | 25 + 3 files changed, 41 insertions(+), 0 deletions(-) Since it's not default, who will actually use this? Particularly since it is only a module option, and not supported through ethtool (frown). laptop users that frequently re-connect their cables might enable this function since it saves battery life. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/21] e1000: rework driver hardware reset locking
Jeff Garzik wrote: Kok, Auke wrote: @@ -631,6 +627,9 @@ e1000_set_ringparam(struct net_device *n tx_ring_size = sizeof(struct e1000_tx_ring) * adapter-num_tx_queues; rx_ring_size = sizeof(struct e1000_rx_ring) * adapter-num_rx_queues; +while (test_and_set_bit(__E1000_RESETTING, adapter-flags)) +msleep(1); This is a bit worrying, but no outright objection. We don't want to see these accumulate. Agreed but at least we removed the opportunity to panic the driver as easy as with 2 commandline commands (in several ways) - we're still looking into improving this - any comments would be appreciated. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/21] e1000: force register write flushes to circumvent broken platforms
Auke Kok wrote:
Jeff Garzik wrote:
Kok, Auke wrote:
A certain AMD64 bridge (8132) has an option to turn on write combining
which breaks our adapter. To circumvent this we need to flush every
write.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
drivers/net/e1000/e1000_hw.c | 24 ++--
drivers/net/e1000/e1000_main.c | 18 +++---
2 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index 3959039..749d621 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -705,8 +705,12 @@ e1000_init_hw(struct e1000_hw *hw)
/* Zero out the Multicast HASH table */
DEBUGOUT(Zeroing the MTA\n);
mta_size = E1000_MC_TBL_SIZE;
-for(i = 0; i mta_size; i++)
+for(i = 0; i mta_size; i++) {
E1000_WRITE_REG_ARRAY(hw, MTA, i, 0);
+/* use write flush to prevent Memory Write Block (MWB) from
+ * occuring when accessing our register space */
+E1000_WRITE_FLUSH(hw);
+}
NAK. We can't crap up every driver just for one weird piece of hardware.
If this problem falls outside the grounds of mmiowb() [see
Documentation/memory-barriers.txt], then other solutions need to be
looked into... ioremap_nocache() ? Tweaking the MTRR for this region?
Chipset quirk? ...
If there is an in-kernel fix for this that would make these flushes
obsolete I would certainly prefer it too, unfortunately we can't fix
already released kernels and our driver still needs to work there too,
so that's why I queued it. It can be dropped from this series if that's
preferred.
I have to get back on that - it's not as simple as the platform is broken.
e1000's don't support write-combining in hardware but the problem only shows
itself during initialization. This patch makes it work on AMD platforms with
write-combining enabled, the platform itself isn't broken - technically the
NIC is (ixgb doesn't have this problem for instance).
The added write flushes are at initialization only, and fix the problem for
any other case. I don't see much harm in that.
Auke
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/21] e1000: add ich8lan core functions
Jeff Garzik wrote: Kok, Auke wrote: This implements the core new functions needed for ich8's internal NIC. This includes: * ich8 specific read/write code * flash/nvm access code * software semaphore flag functions * 10/100 PHY (fe - no gigabit speed) support for low-end versions * A workaround for a powerdown sequence problem discovered that affects a small number of motherboard. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/e1000/e1000_hw.c| 1000 +++ drivers/net/e1000/e1000_hw.h| 386 +++ drivers/net/e1000/e1000_osdep.h | 13 + 3 files changed, 1392 insertions(+), 7 deletions(-) If it takes this much code to support ICH8, it seems like a e1000-ich8.c would be warranted... that's work in progress - Jeb Cramer has been working on this for a while now but unfortunately it's not ready, and getting ich8 supported in a way that we know that doesn't introduce new bugs is more important. This patch adds tested and validated support for these chipsets that has been hammered by our test team. We are planning (working) on cleaning it all up (including whitespace!) - but getting the ich8 support out is more important - people can buy the hardware today. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: e1000: Janitor: Use #defined values for literals
Linas Vepstas wrote: On Fri, Jun 23, 2006 at 01:07:21PM -0700, Auke Kok wrote: Linas Vepstas wrote: Minor janitorial patch: use #defines for literal values. + pci_enable_wake(pdev, PCI_D3hot, 0); + pci_enable_wake(pdev, PCI_D3cold, 0); I Acked this but that's silly - the patches sent yesterday already change the code above and this patch is no longer needed (thanks Jesse for spotting this). This patch would conflict with them so please don't apply. Maybe there's a backlog in the queue, but I not this is not yet in 2.6.17-mm3 It's part of the submission for 2.6.18 I sent to jgarzik on friday, which cleans up this section in the way. Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] e1000: driver update to 7.1.9-k2
Jeff, after comments I've made some adjustments. I'll list them below against the old summary. The changes are available from our git-server: Please pull from: git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream These patches are against netdev-2.6#upstream 612eff0e3715a6faff5ba1b74873b99e036c59fe (Brian Haley [EMAIL PROTECTED] / [PATCH] s2io: netpoll support) Summary of patches: [01]: fix loopback ethtool test [02]: rework driver hardware reset locking [03]: Make PHY powerup/down a function [04]: fix CONFIG_PM blocks [05]: small performance tweak by removing double code [06]: add smart power down code [07]: change printk into DPRINTK [08]: recycle skb [09]: rework module param code with uninitialized values [10]: force register write flushes to circumvent broken platforms Unmodified. See comments here: http://marc.theaimsgroup.com/?l=linux-netdevm=115142459725123w=2 [1] [11]: disable CRC stripping workaround Removed all references to SECRC (crc stripping) instead of leaving it commented. [12]: fix adapter led blinking inconsistency [13]: add E1000_BIG_ENDIAN symbol Dropped this patch entirely [14]: M88 PHY workaround [15]: check return value of _get_speed_and_duplex [16]: disable ERT [17]: add ich8lan core functions [18]: integrate ich8 support into driver [19]: allow user to disable ich8 lock loss workaround [20]: add ich8lan device ID's [21]: increase version to 7.1.9-k2 [1] I can drop #11 in case someone throws a fit ;) - as everyone I'd really like to see patches 17-20 queued for 2.6.18 for obvious reasons - this is the most important section of these patches! Cheers, Auke --- drivers/net/e1000/e1000.h | 10 drivers/net/e1000/e1000_ethtool.c | 143 +-- drivers/net/e1000/e1000_hw.c | 1770 +++--- drivers/net/e1000/e1000_hw.h | 398 drivers/net/e1000/e1000_main.c| 384 +--- drivers/net/e1000/e1000_osdep.h | 13 drivers/net/e1000/e1000_param.c | 213 ++-- 7 files changed, 2530 insertions(+), 401 deletions(-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 1/2]: e100 disable device on PCI error
Linas Vepstas wrote: A recent patch in -mm3 titled gregkh-pci-pci-don-t-enable-device-if-already-enabled.patch causes pci_enable_device() to be a no-op if the kernel thinks that the device is already enabled. This change breaks the PCI error recovery mechanism in the e100 device driver, since, after PCI slot reset, the card is no longer enabled. This is a trivial fix for this problem. Tested. Please submit uptream. Ack! I'm preparing a set of e100 patches at the moment, and will include this one with them. Cheers, Auke Signed-off-by: Linas Vepstas [EMAIL PROTECTED] drivers/net/e100.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.17-mm3/drivers/net/e100.c === --- linux-2.6.17-mm3.orig/drivers/net/e100.c2006-06-27 11:39:08.0 -0500 +++ linux-2.6.17-mm3/drivers/net/e100.c 2006-06-29 14:18:40.0 -0500 @@ -2742,6 +2742,7 @@ static pci_ers_result_t e100_io_error_de /* Detach; put netif into state similar to hotplug unplug. */ netif_poll_enable(netdev); netif_device_detach(netdev); + pci_disable_device(pdev); /* Request a slot reset. */ return PCI_ERS_RESULT_NEED_RESET; - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND] please pull from git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream
Jeff, Since my pull request from thursday I haven't heard anything anymore, so I assume that the changes we made were sufficient. Needless to say that I would love to see ich8 support make it into 2.6.18rc, considering that the hardware already is out there and the code has been tested and validated extensively over the last period. I hope that can still be accomodated. In that light, please pull: git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream Cheers, Auke --- Original message: --- Jeff, after comments I've made some adjustments. I'll list them below against the old summary. The changes are available from our git-server: Please pull from: git://lost.foo-projects.org/~ahkok/git/netdev-2.6 upstream These patches are against netdev-2.6#upstream 612eff0e3715a6faff5ba1b74873b99e036c59fe (Brian Haley [EMAIL PROTECTED] / [PATCH] s2io: netpoll support) Summary of patches: [01]: fix loopback ethtool test [02]: rework driver hardware reset locking [03]: Make PHY powerup/down a function [04]: fix CONFIG_PM blocks [05]: small performance tweak by removing double code [06]: add smart power down code [07]: change printk into DPRINTK [08]: recycle skb [09]: rework module param code with uninitialized values [10]: force register write flushes to circumvent broken platforms Unmodified. See comments here: http://marc.theaimsgroup.com/?l=linux-netdevm=115142459725123w=2 [1] [11]: disable CRC stripping workaround Removed all references to SECRC (crc stripping) instead of leaving it commented. [12]: fix adapter led blinking inconsistency [13]: add E1000_BIG_ENDIAN symbol Dropped this patch entirely [14]: M88 PHY workaround [15]: check return value of _get_speed_and_duplex [16]: disable ERT [17]: add ich8lan core functions [18]: integrate ich8 support into driver [19]: allow user to disable ich8 lock loss workaround [20]: add ich8lan device ID's [21]: increase version to 7.1.9-k2 [1] I can drop #11 in case someone throws a fit ;) - as everyone I'd really like to see patches 17-20 queued for 2.6.18 for obvious reasons - this is the most important section of these patches! Cheers, Auke --- drivers/net/e1000/e1000.h | 10 drivers/net/e1000/e1000_ethtool.c | 143 +-- drivers/net/e1000/e1000_hw.c | 1770 +++--- drivers/net/e1000/e1000_hw.h | 398 drivers/net/e1000/e1000_main.c| 384 +--- drivers/net/e1000/e1000_osdep.h | 13 drivers/net/e1000/e1000_param.c | 213 ++-- 7 files changed, 2530 insertions(+), 401 deletions(-) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ixgb: add PCI Error recovery callbacks
Zhang, Yanmin wrote: On Fri, 2006-06-30 at 00:26, Linas Vepstas wrote: Adds PCI Error recovery callbacks to the Intel 10-gigabit ethernet ixgb device driver. Lightly tested, works. Both pci_disable_device and ixgb_down would access the device. It doesn't follow Documentation/pci-error-recovery.txt that error_detected shouldn't do any access to the device. Moreover, it was Linas who wrote this documentation in the first place :) Linas, have you tried moving the e1000_down() call into the _reset part? I suspect that the e1000_reset() in there however may already be sufficient. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [e1000]: flow control on by default - good idea really?
jamal wrote: On Tue, 2006-04-07 at 13:11 -0400, jamal wrote: I have a device connected to a e1000 that was erroneously advertising both tx/rx flow control but wasnt properly reacting to it. The default setup on the e1000 has rx flow control turned on. I was sending at wire rate gige from the device - which is about 1.48Mpps. The e1000 was in turn sending me flow control packets as per default/expected behavior. Unfortunately, it was sending a very large amount of packets. At one point i was seeing upto 1Mpps and on average, the flow control packets were consuming 60-70% of the bandwidth. Even when i fixed this behavior to act properly, allowing flow control on consumed up to 15% of the bandwidth. Clearly, this is a bad thing. Yes, the device in the first instance was at fault. But i have argued in the past that NAPI does just fine without flow control being turned on, so even chewing 5% of bandwidth on flow control is a bad thing.. As a compromise, can we declare flow control as an advanced feature and turn it off by default? People who feel it is valuable and know what they are doing can turn it off. I meant turn it on. BTW, As an addendum this default behavior changed around 2.6.16 it seems. Flow Control is using the EEPROM provided value, the module driver itself does not choose a default: e1000_param.c: /* User Specified Flow Control Override * * Valid Range: 0-3 * - 0 - No Flow Control * - 1 - Rx only, respond to PAUSE frames but do not generate them * - 2 - Tx only, generate PAUSE frames but ignore them on receive * - 3 - Full Flow Control Support * * Default Value: Read flow control settings from the EEPROM */ Turning flow control off usually (i.e. almost always) causes (significantly) _degraded_ performance. We should really leave it the way it is (as per eeprom setting), and this is best for most if not all people. The card itself has this value programmed, which makes it possible for the user to turn on/off flowcontrol per card consistently, which makes much more sense to me. Also considering e1000 hardware varies significantly. Moreover, most support calls here where people complain about degraded performance are about users who turned flow control _off_. :) Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: e1000 TX unit hang
Phil Oester wrote: I saw this error (once) in 2.6.13 a few weeks ago: Jun 23 15:19:01 X kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang Jun 23 15:19:01 X kernel: TDH 7e Jun 23 15:19:01 X kernel: TDT 7f Jun 23 15:19:01 X kernel: next_to_use 7f Jun 23 15:19:01 X kernel: next_to_clean7e Jun 23 15:19:01 X kernel: buffer_info[next_to_clean] Jun 23 15:19:01 X kernel: dma 16ef9012 Jun 23 15:19:01 X kernel: time_stamp 423845db Jun 23 15:19:01 X kernel: next_to_watch7e Jun 23 15:19:01 X kernel: jiffies 423845db Jun 23 15:19:01 X kernel: next_to_watch.status 0 so upgraded to 2.6.17 and got a slew of them today - shown below. E1000 maintainers: any ideas? The issue is known and worked on, unfortunately no more information yet. We're tracking the issue and stuff (debug patches, etc) over here (at e1000.sf.net): http://sourceforge.net/tracker/index.php?func=detailaid=1463045group_id=42302atid=447449 For now, try to see if turning off tso using ethtool helps. Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [e1000]: flow control on by default - good idea really?
David Miller wrote: From: jamal [EMAIL PROTECTED] Date: Tue, 04 Jul 2006 15:20:39 -0400 BTW, As an addendum this default behavior changed around 2.6.16 it seems. Flow control has been on by default in the tg3 driver since the beginning, maybe e1000 only recently started to behave that way but it's the right thing to do IMHO. As said earlier, e1000 always honors the EEPROM setting for this, which has been _on_ by default for all cards (AFAIK, that is). Cheers, Auke - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
