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
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
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
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!
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
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
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
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
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
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
]
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
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
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
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
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
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
().
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
-
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
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
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
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
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
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
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
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
/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
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
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
,
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
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
-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
/~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
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
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
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
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
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
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
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
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 @@
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
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
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
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
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
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,
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
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
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
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
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
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
-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
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
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
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(-)
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,
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
101 - 200 of 358 matches
Mail list logo
