Wolfgang Walter wrote:
Hello,
it seems that e1000 enables flow-control (rx pause frames) even if the switch
does not advertise flow control. This seems to get a problem as (at least
some) switches then forward pause frames directed to the card from other
hosts. We think there are hosts
Brandeburg, Jesse wrote:
Wolfgang Walter wrote:
it seems that e1000 enables flow-control (rx pause frames) even if
the switch does not advertise flow control. This seems to get a
problem as (at least some) switches then forward pause frames
directed to the card from other hosts. We think
Kok, Auke wrote:
Kok, Auke wrote:
Andrew Morton wrote:
On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov [EMAIL PROTECTED]
wrote:
... and possibly reboot/poweroff (it flows by too fast to be legible).
[ 8803.850634] ACPI: Preparing to enter system sleep state S3
[ 8803.853141
Kok, Auke wrote:
Andrew Morton wrote:
On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov [EMAIL PROTECTED]
wrote:
... and possibly reboot/poweroff (it flows by too fast to be legible).
[ 8803.850634] ACPI: Preparing to enter system sleep state S3
[ 8803.853141] Suspending console(s
Andrew Morton wrote:
On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov [EMAIL PROTECTED] wrote:
... and possibly reboot/poweroff (it flows by too fast to be legible).
[ 8803.850634] ACPI: Preparing to enter system sleep state S3
[ 8803.853141] Suspending console(s)
[ 8805.287505] serial
Andrew Morton wrote:
On Sun, 17 Feb 2008 13:20:59 + Daniel J Blueman [EMAIL PROTECTED]
wrote:
I'm still hitting this with e1000e on 2.6.25-rc2, 10 times again.
are you sure? I don't think that's the case and you're seeing e1000 dumps
here...
It's clearly non-fatal, but then do we
Bernd Schubert wrote:
On Saturday 16 February 2008, Kok, Auke wrote:
Bernd Schubert wrote:
Hello,
I can't login to one of our servers and just got this in an ipmi sol
session:
[18169.209181] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[18169.209183] Tx Queue 0
Jeff Garzik wrote:
Andy Gospodarek wrote:
I booted an igb kernel with the option pci=nomsi and instantly noticed
that interrupts no longer worked on my igb device. I took a look at the
interrupt initialization and quickly discovered a comment stating:
DO NOT USE EIAME or IAME in legacy mode
Bernd Schubert wrote:
Hello,
I can't login to one of our servers and just got this in an ipmi sol
session:
[18169.209181] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[18169.209183] Tx Queue 0
[18169.209184] TDH e3
[18169.209185] TDT
Andy Gospodarek wrote:
I booted an igb kernel with the option pci=nomsi and instantly noticed
that interrupts no longer worked on my igb device. I took a look at the
interrupt initialization and quickly discovered a comment stating:
DO NOT USE EIAME or IAME in legacy mode
It seemed a bit
Prakash Punnoor wrote:
On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
Hi,
Is it a known problem?
Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
e1000e).
your card will work with
Daniel Drake wrote:
Johan Andersson reported on the Gentoo bugzilla that the hardware CRC
stripping enabled by e1000e breaks bridging because sometimes the CRC is
not stripped:
https://bugs.gentoo.org/show_bug.cgi?id=209235
Apparently upstream are aware but I couldn't find any mails or bug
Johan Andersson wrote:
Hi,
In commit 140a74802894e9db57e5cd77ccff77e590ece5f3 a workaround for crc
stripping was removed.
However, the hardware supported crc stripping now in use doesn't seem to
work with the following chip:
Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)
[Added Ingo, Thomas, Justin who signed off on the patch/tested it]
Pavel Emelyanov wrote:
The commit
093af8d7f0ba3c6be1485973508584ef081e9f93
x86_32: trim memory by updating e820
broke my e1000 card: on loading driver says that
e1000: probe of :04:03.0 failed
Carsten Aulbert wrote:
Hi Andi,
Andi Kleen wrote:
Another issue with full duplex TCP not mentioned yet is that if TSO is
used the output will be somewhat bursty and might cause problems with
the TCP ACK clock of the other direction because the ACKs would need
to squeeze in between full
Bruce Allen wrote:
Hi Auke,
Important note: we ARE able to get full duplex wire speed (over 900
Mb/s simulaneously in both directions) using UDP. The problems occur
only with TCP connections.
That eliminates bus bandwidth issues, probably, but small packets take
up a lot of extra
Andy Gospodarek wrote:
(Reposted with the version I intended -- added ',' so it compiles!)
There's too much noise on systems that don't support MSI. Let's get rid
of a few and make the real error message more specific.
Signed-off-by: Andy Gospodarek [EMAIL PROTECTED]
thanks Andy, I'll
Jeff Garzik wrote:
Linus Torvalds wrote:
On Tue, 29 Jan 2008, Randy Dunlap wrote:
Andrew was concerned about this when the driver was in -mm.
He asked for a patch that would set E1000E to same value as E1000
and I supplied that. Auke acked it IIRC. Other people vetoed it. :(
Yeah, I've
Andreas Mohr wrote:
Hi,
On Tue, Jan 29, 2008 at 03:09:25PM -0800, Kok, Auke wrote:
Andreas Mohr wrote:
Perhaps it's useful to file a bug/patch
on http://sourceforge.net/projects/e1000/ ? Perhaps -mm testing?
I wanted to push this though our testing labs first which has not happened
due
Denys Fedoryshchenko wrote:
Sorry. that i interfere in this subject.
Do you recommend CONFIG_IRQBALANCE to be enabled?
I certainly do not. Manual tweaking and pinning the irq's to the correct CPU
will
give the best performance (for specific loads).
The userspace irqbalance daemon tries very
Adrian Bunk wrote:
This patch makes the needlessly global reg_pattern_test_array() static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
stephen hemminger already pointed this out to me... I'll certainly push this
upstream, thanks Adrian!
Auke
---
Adrian Bunk wrote:
This patch makes the needlessly global e1000_dump_eeprom() static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
yes, thanks, I'll push it to Jeff.
Auke
---
b5fd924a1388d4aaa94cf05e42e317c2b1fb5748
diff --git a/drivers/net/e1000/e1000_main.c
Andreas Mohr wrote:
Hi,
On Tue, Jan 01, 2008 at 09:09:08PM +0100, Andreas Mohr wrote:
Thanks for your quick reply!
OK, here's part 1, the MII-less support stuff.
(preliminary posting, for review only)
Note that these diffs apply to 2.6.24-rc6-mm1 without much trouble,
thus might want to
Jeff Garzik wrote:
Auke Kok wrote:
From: Jesse Brandeburg [EMAIL PROTECTED]
fix the typo in speed 1 setting.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
ethtool.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Matheos Worku wrote:
Jeff Garzik wrote:
Auke Kok wrote:
From: Matheos Worku [EMAIL PROTECTED]
Implement support for a SUN-specific PHY.
SUN provides a modified 82597-based board with their own
PHY that works with very little modification to the code. This
patch implements this new PHY
Jeba Anandhan wrote:
Hi all,
i have doubt in e1000_io_write().
void
e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value)
{
outl(value, port);
}
kernel version: 2.6.12.3
Even hw structure has not been used, why it has been passed into
e1000_io_write
Chris Friesen wrote:
Hi all,
I've got an issue that's popped up with a deployed system running
2.6.10. I'm looking for some help figuring out why incoming network
packets aren't being processed fast enough.
After a recent userspace app change, we've started seeing packets being
dropped
Arnaldo Carvalho de Melo wrote:
Em Thu, Jan 10, 2008 at 03:26:59PM +, Jeba Anandhan escreveu:
Hi Eric,
Thanks for the reply. I have one more doubt. For example, if we have 2
processor and 4 ethernet cards. Only CPU0 does all work through 8 cards.
If we set the affinity to each ethernet
Breno Leitao wrote:
On Thu, 2008-01-10 at 16:36 +, Ben Hutchings wrote:
When I run netperf in just one interface, I get 940.95 * 10^6 bits/sec
of transfer rate. If I run 4 netperf against 4 different interfaces, I
get around 720 * 10^6 bits/sec.
snip
I take it that's the average for
Chris Friesen wrote:
Kok, Auke wrote:
You're using 2.6.10... you can always replace the e1000 module with the
out-of-tree version from e1000.sf.net, this might help a bit - the
version in the
2.6.10 kernel is very very old.
Do you have any reason to believe this would improve things
Rick Jones wrote:
1) Interrupts are being processed on both cpus:
[EMAIL PROTECTED]:/root cat /proc/interrupts
CPU0 CPU1
30:17037564530785 U3-MPIC Level eth0
IIRC none of the e1000 driven cards are multi-queue
the pci-express variants are, but the
Jeff Garzik wrote:
Looks pretty decent. Main comments (style mostly, driver operation path
seems sound):
thanks again for the comments. I am about to send an updated patch just before
my
vacation and before I do let me just quickly touch on your comments below:
* kill the bitfields and
Jeff Garzik wrote:
Kok, Auke wrote:
All,
here is the third version of the igb (82575) ethernet controller
driver. This
driver was previously posted 2007-07-13 and 2007-12-11. Many comments
received
were addressed:
- removed indirection wrappers in the same way as e1000e and ixgbe
David Miller wrote:
[NET]: Make -poll() breakout consistent in Intel ethernet drivers.
This makes the -poll() routines of the E100, E1000, E1000E, IXGB, and
IXGBE drivers complete -poll() consistently.
Now they will all break out when the amount of RX work done is less
than 'budget'.
[EMAIL PROTECTED] wrote:
I am running 2.6.23 kernel on a DUAL core and QUAD core i386 boxes and
after everyboot, when the ethernet traffic starts i get this warning.
All the ports in the system are e1000 and i am using the kernel e1000
driver.
[added netdev to the Cc:]
can you repro this
Badalian Vyacheslav wrote:
Hello all.
Some time in dmesg i see this:
[16121.400422] e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang
[16121.400426] Tx Queue 0
[16121.400427] TDH 28
[16121.400429] TDT 28
[16121.400430] next_to_use
Parag Warudkar wrote:
Reduce wakeups from idle per second.
Signed-off-by: Parag Warudkar [EMAIL PROTECTED]
--- linux-2.6/drivers/net/e1000e/netdev.c2007-12-07
10:04:39.0 -0500
+++ linux-2.6-work/drivers/net/e1000e/netdev.c2007-12-18
20:45:59.0 -0500
@@ -3899,7
Stephen Hemminger wrote:
On Thu, 20 Dec 2007 17:29:23 +
-Original Message-
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Thu, 20 Dec 2007 09:16:03
To:[EMAIL PROTECTED]
Cc:netdev@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [PATCH] sky2: Use
Parag Warudkar wrote:
On Dec 20, 2007 12:05 PM, Kok, Auke [EMAIL PROTECTED] wrote:
I can't even apply this patch and the e1000 one... not only is it whitespace
damaged it is also not properly formatted as patch at all. If you want me to
take
these patches seriously, then please fix
Arjan van de Ven wrote:
My interpretation of the api is:
* round_jiffies() - timer wants to wakeup but isn't precise
about when so schedule
on next second when system will wake up anyway;
e.g why meetings are usually scheduled on
the hour
Stephen Hemminger wrote:
On Thu, 20 Dec 2007 15:36:13 -0500
Parag Warudkar [EMAIL PROTECTED] wrote:
On Dec 20, 2007 3:04 PM, Arjan van de Ven [EMAIL PROTECTED] wrote:
I think it is reasonable for Network driver watchdogs to use a
deferrable timer - if the machine is 100% IDLE there is no
Auke Kok wrote:
From: Parag Warudkar [EMAIL PROTECTED]
Reduce wakeups from idle per second.
Signed-off-by: Parag Warudkar [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
---
Jeff,
given the discussion with Stephen I'd like to skip merging this patch and the
e1000 one for
Parag Warudkar wrote:
Reduce wakeups from idle per second.
Signed-off-by: Parag Warudkar [EMAIL PROTECTED]
--- linux-2.6/drivers/net/e1000e/netdev.c2007-12-07
10:04:39.0 -0500
+++ linux-2.6-work/drivers/net/e1000e/netdev.c2007-12-18
20:45:59.0 -0500
@@ -3899,7
Parag Warudkar wrote:
Use deferrable timer for watchdog. Reduces wakeups from idle per second.
no, we don't want this. We already allow the re-scheduling of the watchdog to be
round_jiffies() modified so that it coincides with other interrupts.
but at load time we don't want the timer to be
Parag Warudkar wrote:
On 12/19/07, Kok, Auke [EMAIL PROTECTED] wrote:
[snip]
I can't possibly see any benefit from this other than that you just add up
to a
whole second to the initialization cycle, which is bad.
Well, Ok but it can't be bad - I've been using this patch sometime
Parag Warudkar wrote:
On Dec 19, 2007 4:38 PM, Kok, Auke [EMAIL PROTECTED] wrote:
Parag Warudkar wrote:
On 12/19/07, Kok, Auke [EMAIL PROTECTED] wrote:
why would this patch reduce wakeups even more than round_jiffies()? Does it
make
our ~2 second update interval not reliable? can you
Denys Fedoryshchenko wrote:
At the beginning - kernel is with gentoo patched, but i checked, there is
nothing major and almost none from patched code used on this router (there is
almost no networking patches, except e1000e support, small GRE fix and few
wireless things, which is not used).
Joe Perches wrote:
On Fri, 2007-12-14 at 15:35 -0800, Auke Kok wrote:
+printk(KERN_ERR /*/\n);
+printk(KERN_ERR Current EEPROM: 0x%04x\nCalculated: 0x%04x\n,
+ csum_old, csum_new);
Multiline printks need a KERN_level after every newline. Perhaps:
David Miller wrote:
From: Andrew Gallatin [EMAIL PROTECTED]
Date: Thu, 13 Dec 2007 09:13:54 -0500
If the netif_running() check is indeed required to make a device break
out of napi polling and respond to an ifconfig down, then I think the
netif_running() check should be moved up into
Kok, Auke wrote:
All,
here is the second version of the igb (82575) ethernet controller driver. This
driver was previously posted 2007-07-13. Many comments received were
addressed:
- removed indirection wrappers in the same way as e1000e and ixgbe.
- cleaned up largely against sparse
David Miller wrote:
From: Andrew Gallatin [EMAIL PROTECTED]
Date: Wed, 12 Dec 2007 12:29:23 -0500
Is the netif_running() check even required?
No, it is not.
When a device is brought down, one of the first things
that happens is that we wait for all pending NAPI polls
to complete, then
Andrew Morton wrote:
On Tue, 11 Dec 2007 08:13:52 -0800 Martin Bligh [EMAIL PROTECTED] wrote:
- Lots of device IDs have been removed from the e1000 driver and moved
over
to e1000e. So if your e1000 stops working, you forgot to set
CONFIG_E1000E.
Wouldn't it make sense to just default
David Miller wrote:
From: Joe Perches [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 13:04:59 -0800
On Tue, 2007-12-11 at 11:56 -0800, David Miller wrote:
The rebase of net-2.6.25 is complete
I have an earlier unmodified git repository of net-2.6.25.
Does anyone know the appropriate git commands
Kok, Auke wrote:
Andrew Morton wrote:
On Tue, 11 Dec 2007 08:13:52 -0800 Martin Bligh [EMAIL PROTECTED] wrote:
- Lots of device IDs have been removed from the e1000 driver and moved
over
to e1000e. So if your e1000 stops working, you forgot to set
CONFIG_E1000E.
Wouldn't it make sense
Andrew Morton wrote:
On Tue, 11 Dec 2007 13:26:58 -0800
Kok, Auke [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Tue, 11 Dec 2007 08:13:52 -0800 Martin Bligh [EMAIL PROTECTED] wrote:
- Lots of device IDs have been removed from the e1000 driver and moved
over
to e1000e. So if your
Tomohiro Kusumi wrote:
Dear Auke and e1000 maintainers
Hi, this is the patch which makes the e1000 driver legacy I/O port free.
I've received some advice from Auke quite long time ago, and submitted
a patch (http://lkml.org/lkml/2007/8/10/11) which I think meets what Auke
had told me.
Lukas Hejtmanek wrote:
On Tue, Dec 04, 2007 at 11:02:23AM -0500, Matt Mathis wrote:
This is probably not an e1000 problem, but a general Ethernet feature.
If you defeat auto-negotiation to force the data rate, you implicitly
defeat duplex negotiation as well. You need to explicitly set the
Lukas Hejtmanek wrote:
On Tue, Dec 04, 2007 at 09:19:11AM -0800, Kok, Auke wrote:
if you just want to disable gigabit speed, get the latest ethtool and run:
ethtool -s eth0 advertise 0x0f
thanks. You may then let know people behind http://www.lesswatts.org/ to
change tipstricks related
Lukas Hejtmanek wrote:
On Tue, Nov 27, 2007 at 10:23:00AM -0800, Kok, Auke wrote:
can you see if your problem goes away with this patch?
I cannot test it right now but friend of mine has the same card with 2.6.23.1
kernel. it does not. he also tried module 7.6.12 from source fourge, your
Robert Olsson wrote:
Hello!
After further investigations. The bug was just in front of us...
ifconfig down in combination with the test for || !netif_running() can
return a full quota and netif_rx_complete() done which causes the oops
in net_rx_action. Of course the load must be
David Acker wrote:
What is the status of this patch? Is there anything folks would like me
to do in order to move it forward? As an FYI, my company has been using
this patch since I posted it and so far we have not had any problems
with it.
-Ack
Jeff merged it in netdev-2.6#upstream so it
[moving this discussion to netdev, dropping lkml]
Lukas Hejtmanek wrote:
On Tue, Nov 27, 2007 at 08:48:52AM -0800, Kok, Auke wrote:
unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2
kernel due to compilation errors.
but the in-kernel version of e1000 supports the ich8
Lukas Hejtmanek wrote:
On Tue, Nov 27, 2007 at 09:40:08AM -0800, Kok, Auke wrote:
I'm afraid, I'm missing the point as you have stated that in-kernel drivers
have problem with suspicious board hang...
my mistake, sorry for that confusion.
the fake hangs on 82562/6 devices occur on 10mbit
Stephen Hemminger wrote:
On Tue, 27 Nov 2007 19:52:24 +0100
Robert Olsson [EMAIL PROTECTED] wrote:
Hello!
I've discovered a bug while testing the new multiQ NAPI code. In hi-load
situations when we take down an interface we get a kernel panic. The
oops is below.
From what I see this
Stephen Hemminger wrote:
On Tue, 27 Nov 2007 14:34:44 -0800
Kok, Auke [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
On Tue, 27 Nov 2007 19:52:24 +0100
Robert Olsson [EMAIL PROTECTED] wrote:
Hello!
I've discovered a bug while testing the new multiQ NAPI code. In hi-load
situations
Jeff Garzik wrote:
Benjamin Herrenschmidt wrote:
The e1000 driver stores the content of the PCI resources into
unsigned long's before ioremapping. This breaks on 32 bits
platforms that support 64 bits MMIO resources such as ppc 44x.
This fixes it by removing those temporary variables and
Joe Perches wrote:
Signed-off-by: Joe Perches [EMAIL PROTECTED]
---
drivers/net/ixgbe/ixgbe_common.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_common.c
b/drivers/net/ixgbe/ixgbe_common.c
index 512e3b2..b7e50bc 100644
---
Denys Vlasenko wrote:
On Wednesday 14 November 2007 00:27, Adrian Bunk wrote:
You missed the following in my email:
we slowly scare them away due to the many bug reports without any
reaction.
The problem is that bug reports take time. If you go away from easy
things like compile errors
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend
Patrick McHardy wrote:
Herbert Xu wrote:
On Tue, Nov 13, 2007 at 04:06:24AM -0800, David Miller wrote:
In other words we can make it so that nobody is in promiscuous
mode and therefore have to disable VLAN acceleration *unless*
they really want to be in that state. In which case it would
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for
e1000e as well?
Patch
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care to resend it and send me one for
e1000e as well?
Patch
Krishna Kumar wrote:
E1000: Implement batching capability (ported thanks to changes taken from
Jamal).
Signed-off-by: Krishna Kumar [EMAIL PROTECTED]
this doesn't apply anymore and it would help if you could re-spin this for
e1000e.
I don't know what the status for merging of the
Joonwoo Park wrote:
2007/11/14, Kok, Auke [EMAIL PROTECTED]:
Patrick McHardy wrote:
Kok, Auke wrote:
Patrick McHardy wrote:
I already posted a patch for this, not sure what happened to it.
Auke, any news on merging the secondary unicast address support?
I dropped the ball on that one. Care
Joonwoo Park wrote:
IMHO even though netdevice is in the promiscuous mode, we should receive all
of ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000
device goes into promiscuous mode.
This make packets visible to sniffers though it's not vlan id
Patrick McHardy wrote:
Kok, Auke wrote:
Joonwoo Park wrote:
IMHO even though netdevice is in the promiscuous mode, we should receive
all of ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured
e1000 device goes into promiscuous mode.
This make packets
Chris Friesen wrote:
David Miller wrote:
When you select VLAN, you by definition are asking for non-VLAN
traffic to be elided. It is like plugging the ethernet cable
into one switch or another.
For max functionality it seems like the raw eth device should show
everything on the wire in
Willy Tarreau wrote:
On Mon, Nov 12, 2007 at 03:19:23PM -0800, David Miller wrote:
From: Willy Tarreau [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 00:15:16 +0100
I can say that sometimes you'd like to be aware that one of your
VLANs is wrong and you'd simply like to sniff the wire to guess the
Ben Hutchings wrote:
Auke Kok wrote:
From: Jesse Brandeburg [EMAIL PROTECTED]
there is missing support in ethtool for reporting 1baseT
as SUPPORTED_1baseT_Full. The code seems to be half
implemented because the advertising field has the implementation.
I reported this lack on
[adding netdev, jeff G to the Cc]
Linas Vepstas wrote:
On Wed, Nov 07, 2007 at 01:50:17PM -0800, Kok, Auke wrote:
Linas Vepstas wrote:
If a PCI bus error is encountered during device open, the
error recovery routines will attempt to close the device.
If napi has not yet been enabled
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next
Joe Perches wrote:
Add functions for reg_pattern_test and reg_set_and check
Changed macros to use these functions
Compiled x86, untested
Size decreased ~2K
old:
$ size drivers/net/e1000e/ethtool.o
textdata bss dec hex filename
14461 0 0 14461
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 22:20:30 -0400
David Miller wrote:
From: Jeff Garzik [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 21:03:36 -0400
I'm wondering if there is a way to avoid adding
if (!is_valid_ether_addr(dev-dev_addr))
Joe Perches wrote:
Minimal macro to function conversion in e1000_ethtool.c
Adds functions reg_pattern_test and reg_set_and_check
Changes REG_PATTERN_TEST and REG_SET_AND_CHECK macros
to call these functions.
Saves ~2.5KB
Compiled x86, untested (no hardware)
old:
$ size
Joe Perches wrote:
Convert REG_PATTERN_TEST and REG_SET_AND_CHECK macros to functions
Reduces x86 defconfig image by about 3k
compiled, untested (no hardware)
Signed-off-by: Joe Perches [EMAIL PROTECTED]
New:
$ size vmlinux
textdata bss dec hex filename
4792735
Joe Perches wrote:
On Wed, 2007-10-31 at 14:30 -0700, Kok, Auke wrote:
Joe Perches wrote:
that's not a bad idea, however see below:
can't we keep the macro here (and just make it call the function instead of
expanding). the resulting code is much more lenghty and contains all these
logic
Andy Gospodarek wrote:
Auke,
It has become clear that this patch resolves some tx-lockups on the ixgb
driver. IBM did some checking and realized this hunk is in your
sourceforge driver, but not anywhere else. Mind if we add it?
I'll quickly double check where this came from in the first
David A. Ranch wrote:
e1000 is being frozen in time as pre-PCI Express e1000's.
Asking the question a different way, will the current e1000 driver
continue to get new features, performance / power / optimization tweaks,
etc. or is most of the primary development be moving only on the
Jeff Garzik wrote:
Auke Kok wrote:
Since data can never exceed u32, it can't even be larger than
LONG_MAX/HZ.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
Two comments:
1) I would prefer to pick a sane limit, like 1 day. The unit of
'data' is seconds, so IMO we
Roel Kluin wrote:
A few patches with changes to net code. I have sent these to the lkml
previously, but they were not yet merged. I am fairly new to kernel
programming, so it is possible that I make some mistakes. I'll explain my
rationale, please nack if incorrect, an additional bit of
Roel Kluin wrote:
Kok, Auke wrote:
Ack this e1000e change here!
(PS since there was only 1 netdriver patch here and the rest is wireless, I
would
have suggested splitting this patch up in two and sending them to the
wireless
maintainer and netdevice maintainer separately. But I'm sure
Stephen Hemminger wrote:
On Fri, 26 Oct 2007 15:10:28 -0700
Auke Kok [EMAIL PROTECTED] wrote:
Trivial replacement - use INT_MAX instead here.
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Acked-by: Stephen Hemminger [EMAIL PROTECTED]
Sure that works. Note: original
Auke Kok wrote:
Fix allocation and freeing of jumbo frames where several bugs
were recently introduced by cleanups after we forked this code
from e1000. This moves ps_pages to buffer_info where it really
belongs and makes it a dynamically allocated array. The penalty
is not that high since
Jeff Garzik wrote:
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the planned removal of the eepro100 driver.
Are the e100 people satisfied that e100 now handles all known cases? I
Nope. There are still e100 work outstanding that means we cannot kill
eepro100.
Agreed,
Jeff Garzik wrote:
Kok, Auke wrote:
Adam Jackson wrote:
On Tue, 2007-10-23 at 09:18 -0700, Kok, Auke wrote:
Adam Jackson wrote:
When the EEPROM gets corrupted, you can fix it with ethtool, but
only if
the module loads and creates a network device. But, without this
option,
if the EEPROM
Dave Jones wrote:
On Tue, Oct 23, 2007 at 04:40:01PM -0400, Jeff Garzik wrote:
In any case, this patch should not be merged. We often send it around to
users to
debug their issue in case it involves eeproms, but merging it will just
conceal
the real issue and all of a sudden a
David Miller wrote:
From: Dave Jones [EMAIL PROTECTED]
Date: Tue, 23 Oct 2007 17:20:26 -0400
Indeed. This is a common enough problem that not including it causes
more pain than its worth. I have two affected boxes myself that I
actually thought the hardware was dead before I tried ajax's
David Mack wrote:
It appears that the needed e100 fix made it into the Fedora
2.6.23.1-23.fc8 kernel. Boots reliably now.
Huge thanks and great work, guys.
DaveJ, I didn't push anything upstream. Can you verify this now works?
Auke
Dave
-Original Message-
From: Kok, Auke
Adrian Bunk wrote:
You want to check for the value, not for the address.
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -1451,11 +1451,11 @@ static int
1 - 100 of 470 matches
Mail list logo
