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
>>>
---Original Message-
>> From: Kok, Auke [mailto:[EMAIL PROTECTED]
>> Sent: Friday, October 12, 2007 10:05 AM
>> To: Herbert Xu
>> Cc: David Mack; Dave Jones; netdev@vger.kernel.org;
>> [EMAIL PROTECTED]
>> Subject: Re: e100 problems in .23rc8 ?
>>
>
Joe Perches wrote:
> On Mon, 2007-10-15 at 09:20 -0700, Kok, Auke wrote:
>>> Instead the fix should be for the 2 existing bugs on macro:
>>> o Comma after KERN_DEBUG
>>> o Semicolon in macro
>> will push a patch, thanks.
>
> Perhaps you could fix this
Joe Perches wrote:
> On Fri, 2007-10-05 at 13:53 -0400, Jeff Garzik wrote:
>>> diff --git a/drivers/net/e1000e/hw.h b/drivers/net/e1000e/hw.h
>>> index 848217a..aa82f1a 100644
>>> --- a/drivers/net/e1000e/hw.h
>>> +++ b/drivers/net/e1000e/hw.h
>>> @@ -852,7 +852,7 @@ struct e1000_hw {
>>>
>>> #i
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 e1000_loopback
Herbert Xu wrote:
> On Fri, Oct 12, 2007 at 07:54:33AM -0700, David Mack wrote:
>> Still no joy here. See attached capture. What's really weird is that it
>> shows *two* kernel panics, one in e100_poll and one in _list_add.
>
> Yes that's the symptom one would expect from that bug. We really
> n
Herbert Xu wrote:
> On Wed, Oct 10, 2007 at 08:36:38PM -0400, Dave Jones wrote:
>> The e1000 changes you reference above, is this the changeset you mean?
>>
>> commit 416b5d10afdc797c21c457ade3714e8f2f75edd9
>> Author: Auke Kok <[EMAIL PROTECTED]>
>> Date: Fri Jun 1 10:22:39 2007 -0700
>>
>>
jamal wrote:
> On Mon, 2007-08-10 at 15:40 -0700, Kok, Auke wrote:
>
>> My biggest problem with the patch as you sent it that it's a tonload of
>> changes
>> and no implicit benefit immediately as I can see.
>
> The patch looks scary but is pretty tame
jamal wrote:
> Ok, here you go; the explanation is below. This is from net-2.6.24 of
> early this AM. I saw a patch you posted that is derived from Krishna;
> although it hasnt showed up in the tree - i have considered those
> changes and this patch adds a little more optimization in case of
> erro
maximilian attems wrote:
> Linux tau 2.6.23-rc8-mm2-686 #1 SMP Wed Oct 3 23:56:32 CEST 2007 i686
> GNU/Linux
>
> eth0 renamed to eth1
> sysfs: duplicate filename 'eth1' can not be created
> WARNING: at fs/sysfs/dir.c:433 sysfs_add_one()
> [] dump_trace+0x68/0x1d5
> [] show_trace_log_lvl+0x18/0x2
I'm getting this on net-2.6.24 today:
CC [M] net/ipv4/ip_gre.o
net/ipv4/ip_gre.c:1135: error: 'ipgre_header' undeclared here (not in a
function)
make[2]: *** [net/ipv4/ip_gre.o] Error 1
make[1]: *** [net/ipv4] Error 2
make[1]: *** Waiting for unfinished jobs
the git log says sch touched
jamal wrote:
> Auke,
>
> heres part of something i promised.
> I couldnt do any packet testing on because 82571EB is disabled in the
> driver. I uncommented the code out in the table, but the best i could
> get was the module loading, some probing and some sysfs renaming
> failures (probably a de
jamal wrote:
> On Sun, 2007-30-09 at 18:59 -0700, Kok, Auke wrote:
>
>> the IDs are the only thing needed to enable all pci-e e1000 hardware.
>
> I'll give it a whirl in the next few days. It failed as a module (with
> e1000 compiled out), i will try to compile i
jamal wrote:
> On Sun, 2007-30-09 at 15:23 -0400, Jeff Garzik wrote:
>
>> Gotta wait a bit, otherwise we have confusion and a bit of breakage from
>> two drivers with the same PCI IDs.
>
> ah, ok ;->
> When i was testing i compiled out e1000. I am willing to totaly migrate
> to e1000e, since ma
jamal wrote:
> Auke,
>
> heres part of something i promised.
> I couldnt do any packet testing on because 82571EB is disabled in the
> driver. I uncommented the code out in the table, but the best i could
> get was the module loading, some probing and some sysfs renaming
> failures (probably a de
Dave Jones wrote:
> Last night, I hit this bug during boot up..
> http://www.codemonkey.org.uk/junk/e100-2.jpg
>
> This morning, I got a mail from a Fedora user of the same
> .23-rc8 based kernel that has seen a different trace
> also implicating e100..
>
> http://www.codemonkey.org.uk/junk/e100.
jamal wrote:
> On Mon, 2007-24-09 at 00:00 -0700, Kok, Auke wrote:
>
>> that's bad to begin with :) - please send those separately so I can
>> fasttrack them
>> into e1000e and e1000 where applicable.
>
> Ive been CCing you ;-> Most of the changes are
jamal wrote:
> On Sun, 2007-23-09 at 12:36 -0700, Kok, Auke wrote:
>
>> please be reminded that we're going to strip down e1000 and most of the
>> features
>> should go into e1000e, which has much less hardware workarounds. I'm still
>> reluctant to putti
jamal wrote:
> On Sun, 2007-23-09 at 14:19 -0400, Jeff Garzik wrote:
>
>> You should post at least a couple driver patches to see how its used on
>> Real Hardware(tm)... :)
>
> This is the tg3 patch i used for the testing - against whats in Daves
> net-2.6.24 tree. Patch may be a bit hard to r
jamal wrote:
>> AFAIK the RX side is fully covered
>
> so you can handle both 64B and 68B?
I never saw any bugreports about e1000 not being able to accept vlan packets
because of this, so I'm quite certain it works OK, feel free to find me a case
where this isn't so :)
Auke
-
To unsubscribe fro
jamal wrote:
> On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote:
>
>> I just re-read the spec, and a bridge *may* pad up to 68, but it is not
>> required.
>> On page 166, it says equipment must be able to handle 64 byte minimums.
>>
>> See page 22 (section 7.2) of this document:
>>
>> http://s
Jeff Garzik wrote:
> Auke Kok wrote:
>> This blade-specific board form factor is identical to the 82571EB
>> board.
>>
>> Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
>> ---
>>
>> drivers/net/e1000/e1000_ethtool.c |1 +
>> drivers/net/e1000/e1000_hw.c |1 +
>> drivers/net/e1000/e1000_h
Rick Jones wrote:
> Kok, Auke wrote:
>> L F wrote:
>>
>>>>>>> tx_deferred_ok: 486
>>>>
>>>> this one I wonder about, and might cause delays, I'll have to look
>>>> up what it exactly could implicate though.
>>>
L F wrote:
>> To me it suggests that your speed is not full-duplex. Check `ethtool eth0`
>> output
>> and see if your link is full duplex or not. also check previous kernel
>> messages
>> and see what the e1000 driver posted there for link speed messages (as in
>> "e1000:
>> Link is UP speed XX
Jiri Slaby wrote:
> On 12/23/-28158 08:59 PM, Auke Kok wrote:
>> This incorporates the new napi_struct changes into e1000e. Included
>> bugfix for ifdown hang from Krishna Kumar for e1000.
>>
>> Disabling polling is no longer needed at init time, so remove
>> napi_disable() call from _probe().
>>
>
James Chapman wrote:
> Kok, Auke wrote:
>> James Chapman wrote:
>>> Kok, Auke wrote:
>
>>>>> rx_long_byte_count: 34124849453
>>>
>>> Are these long frames expected in your network? What is the MTU of
>>> the transmitting clients?
L F wrote:
> tx_deferred_ok: 486
>> this one I wonder about, and might cause delays, I'll have to look
>> up what it exactly could implicate though.
> Please do and let me know. samba 3.0.26 helped, but the issue is
> still there.
ok, from the spec: tx_deferred_ok is what is in the DC stats re
James Chapman wrote:
Kok, Auke wrote:
L F wrote:
On 9/14/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
this slowness might have been masking the issue
That is possible. However, it worked for upwards of twelve months
without an error.
I have not yet seen other reports of this issue, and it
Dan Williams wrote:
On Thu, 2007-09-13 at 01:30 -0400, Jeff Garzik wrote:
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/atl1/atl1_main.c | 19 +++
d
L F wrote:
On 9/14/07, Kok, Auke <[EMAIL PROTECTED]> wrote:
this slowness might have been masking the issue
That is possible. However, it worked for upwards of twelve months
without an error.
I have not yet seen other reports of this issue, and it would be interesting to
see if the st
L F wrote:
Folks,
I've been playing with multiple gigabit ethernet drivers to get samba
3.0.25+ to work reliably. The situation is as follows.
I have a network, one of the machines on the network is a
server/firewall. It contains an Intel PRO1000 dual port PCI Express
card and runs Debian-testing
Andrew Morton wrote:
On Wed, 12 Sep 2007 15:20:01 -0700
"Kok, Auke" <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
On Wed, 12 Sep 2007 11:13:07 -0700
Auke Kok <[EMAIL PROTECTED]> wrote:
This incorporates the new napi_struct changes into ixgbe.
I get a reject stor
Andrew Morton wrote:
On Wed, 12 Sep 2007 11:13:07 -0700
Auke Kok <[EMAIL PROTECTED]> wrote:
This incorporates the new napi_struct changes into ixgbe.
I get a reject storm.
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -557,14 +557,15 @@ static irqreturn_t ixgb
Jeff Garzik wrote:
David Miller wrote:
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Thu, 06 Sep 2007 11:31:47 -0700
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
http://foo-projects.org/~sofa
David Miller wrote:
From: Robert Olsson <[EMAIL PROTECTED]>
Date: Sat, 8 Sep 2007 09:53:49 +0200
Yes a correct observation. I've spotted this bug too and it caused by the
policy change in the NAPI scheduling. Look at tx_cleaned.
I suggest we revert this change for now.
The tx_cleaned lo
Kok, Auke wrote:
David,
From an old thread:
> 5) Since, in the NETPOLL case, netif_napi_init() adds the NAPI struct
> to the per-device list I renamed it to netif_napi_add(). Currently
> no teardown is really necessary, anything that would need to be done
> would be dri
David,
From an old thread:
> 5) Since, in the NETPOLL case, netif_napi_init() adds the NAPI struct
> to the per-device list I renamed it to netif_napi_add(). Currently
> no teardown is really necessary, anything that would need to be done
> would be driver internal, so I didn't create th
Jiri Slaby wrote:
Kok, Auke napsal(a):
Jiri Slaby wrote:
I still have problems with the driver. When I do `ip link set eth0
up', ksoftirq
runs with 100 % cpu time, so I think you endlessly re-schedule some
timer (or
the new napi layer?)
something changed in the logic and e1000e appar
Jiri Slaby wrote:
On 09/07/2007 09:19 AM, Jiri Slaby wrote:
Hi,
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e driver.
napi_disable(&adapter->napi) in e1000_probe freezes the kernel on boot.
Ok, after these changes:
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e10
Auke Kok wrote:
This incorporates the new napi_struct changes into e1000e. Included
bugfix for ifdown hang from Krishna Kumar for e1000.
Disabling polling is no longer needed at init time, so remove
napi_disable() call from _probe().
david,
while testing this patch I noticed that the poll ro
Jeff Garzik wrote:
Kok, Auke wrote:
Jeff Garzik wrote:
Kok, Auke wrote:
David Miller wrote:
From: Jiri Slaby <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 09:19:30 +0200
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e
driver.
napi_disable(&adapter->napi) i
Jeff Garzik wrote:
Kok, Auke wrote:
David Miller wrote:
From: Jiri Slaby <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 09:19:30 +0200
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e
driver.
napi_disable(&adapter->napi) in e1000_probe freezes the kernel on bo
Kok, Auke wrote:
David Acker wrote:
Kok, Auke wrote:
first impressions are not good: pings are erratic and shoot up to 3
seconds. In an overnight stress test, the receive unit went offline and
never came back up (TX still working).
it sounds like something in the logic is suspending the ru
David Acker wrote:
Kok, Auke wrote:
first impressions are not good: pings are erratic and shoot up to 3
seconds. In an overnight stress test, the receive unit went offline and
never came back up (TX still working).
it sounds like something in the logic is suspending the ru too much, but
I
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 li
David Miller wrote:
From: Jiri Slaby <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 09:19:30 +0200
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e driver.
napi_disable(&adapter->napi) in e1000_probe freezes the kernel on boot.
Yes, the semantics changed slightly in the net-2.6.2
Andrew Morton wrote:
On Thu, 06 Sep 2007 12:44:22 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Thu, 06 Sep 2007 11:31:47 -0700
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-200
Auke Kok wrote:
This patch adds support for the Intel 82598 PCI-Express 10GbE
chipset. Devices will be available on the market soon.
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
http://foo-projects.org/~sofar/ixgbe-20070905-
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 li
Marc Sigler wrote:
Hello everyone,
I have several systems with three integrated Intel 82559 (I *think*).
Does someone know if these boards support hardware interrupt mitigation?
I.e. is it possible to configure them to raise an IRQ only if their
hardware buffer is full OR if some given time (
Adrian Bunk wrote:
This patch contains the planned removal of the eepro100 driver.
Signed-off-by: Adrian Bunk
you lost your e-mail address? :)
---
This patch has been sent on:
- 14 Aug 2007
- 29 Jul 2007
currently we won't have e100 fixed up for ARM in 2.6.23, so removing this for
2.6.2
Milton Miller wrote:
On Jun 5, 2007, at 8:34 AM, David Acker wrote:
David, Milton,
This was the last communication on-topic for the proposed changes to fix e100 on
ARM. We're holding our breath here waiting for more, and would love to hear that
this issue and fixes hasn't died off.
Thanks,
James Chapman wrote:
Recent NAPI changes require that napi_enable() is always matched with
a napi_disable(). This patch makes sure that this invariant holds for
e100. It also moves the netif_napi_add() call until after private
pointers have been intialized, though this might only be significant
f
Krishna Kumar wrote:
Doing napi_disable twice hangs "ifdown" of the device. e1000_down is the
common place to call napi_disable.
Signed-off-by: Krishna Kumar <[EMAIL PROTECTED]>
---
e1000_main.c |4
1 files changed, 4 deletions(-)
diff -ruNp org/drivers/net/e1000/e1000_main.c new/driv
Gerrit Renker wrote:
With the davem-2.6.24 tree I get the following Oops in the e100 driver (cribbed
from console):
Code: 6c ff ff ff 8b 48 0c ba 01 00 00 00 89 f0 e8 1b f2 ff ff c7 86 9c 00 00 00
01 00 00 00 e9 4e ff ff ff 89 d0 e8 b3 f8 0b 00 eb 8e <0f> 0b eb fe 55 89
e5
56 53 83
Michal Piotrowski wrote:
Hi,
This patch fixes the following compilation warning
drivers/net/e1000e/netdev.c: In function ‘e1000_setup_rctl’:
drivers/net/e1000e/netdev.c:1963: warning: unused variable ‘pages’
Regards,
Michal
also exposes a symbol issue. I think I want to remove this
Krishna Kumar wrote:
E1000: Implement batching capability (ported thanks to changes taken from
Jamal). Not all changes are made in this as in IPoIB, eg, handling
out of order skbs (see XXX in the first mail).
Signed-off-by: Krishna Kumar <[EMAIL PROTECTED]>
---
e1000_main.c | 1
David Miller wrote:
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 18:21:25 -0700
this sounds highly optimistic ("64 queues is enough for everyone"?)
and probably will be quickly outdated by both hardware and demand...
As such drivers appear in the tr
David Miller wrote:
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 17 Aug 2007 17:49:09 -0700
Fix optimization of netdev_priv() lost by the addition of multiqueue.
Only configurations that define MULITQUEUE need the extra overhead in
netdevice structure and the loss of the netdev_priv
Tejun Heo wrote:
Brandon Philips wrote:
- mmio_start = pci_resource_start(pdev, BAR_0);
mmio_len = pci_resource_len(pdev, BAR_0);
You don't need mmio_len either.
- err = -EIO;
- adapter->hw.hw_addr = ioremap(mmio_start, mmio_len);
+ adapter->hw.hw_addr = pcim_
Joe Perches wrote:
On Wed, 2007-08-15 at 19:58 -0400, Dave Jones wrote:
Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
diff --git a/drivers/infiniband/hw/mlx4/mad.c b/drivers/infiniband/hw/mlx4/mad.c
index 3330917..0ed02b7 100644
--- a/drivers/infiniband/hw/mlx4/mad.c
+++ b/drivers/infiniband/hw
Rick Jones wrote:
if you grep around this effort was already started using the 'e1e_'
prefix. I like the shorter prefix, but your call ultimately. Either
way, make sure to make the driver consistent there too.
should it then be consistent with the overall driver name too?
certainly calling
Kok, Auke wrote:
Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
From: Adrian Bunk <[EMAIL PROTECTED]>
e1000_{read,write}_pci_cfg() are no longer used.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Cc: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROT
Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
From: Adrian Bunk <[EMAIL PROTECTED]>
e1000_{read,write}_pci_cfg() are no longer used.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Cc: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_hw.h
[EMAIL PROTECTED] wrote:
From: "Peter Oruba" <[EMAIL PROTECTED]>
These driver changes incorporate the proposed PCI-X / PCI-Express read byte
count interface. Reading and setting those valuse doesn't take place
"manually", instead wrapping functions are called to allow quirks for some
PCI bridge
Rick Jones wrote:
David Miller wrote:
From: Ben Greear <[EMAIL PROTECTED]>
Date: Fri, 10 Aug 2007 15:40:02 -0700
For GSO on output, is there a generic fallback for any driver that
does not specifically implement GSO?
Absolutely, in fact that's mainly what it's there for.
I don't think ther
Andi Kleen wrote:
"Kok, Auke" <[EMAIL PROTECTED]> writes:
All,
Another update on e1000e. Many thanks to Jeff for helping out and
getting this going forward. The driver is unfortunately still too
large to post, so please use the URL's below to review:
Just some
Jeff Garzik wrote:
Auke Kok wrote:
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
include/linux/ethtool.h |8 +++
include/linux/netdevice.h |1 +
net/core/ethtool.c| 53 +
3 files changed, 62 insertions(+), 0 deletions(-)
di
Chuck Ebbert wrote:
On 08/08/2007 07:15 PM, Auke Kok wrote:
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/82571.c |4
drivers/net/e1000e/e1000.h |7 ---
drivers/net/e1000e/es2lan.c |5 +
drivers/net/e1000e/ethtool.c |3 ++-
drivers/net/e10
Brandon Philips wrote:
On 17:30 Wed 08 Aug 2007, Ramkrishna Vepa wrote:
Before slot_reset event is called io_error_detected could be called
(where pci_disable_device() is called), right?
Oops! Right, the documentation says .error_detected is _always_ called
before .slot_reset. So, this patc
Adrian Bunk wrote:
On Thu, Aug 09, 2007 at 01:51:06AM -0700, Andrew Morton wrote:
...
- There is a new e1000 driver in git-netdev-all, called e1000e. I'm sure
the developers would like it tested. Please cc netdev@vger.kernel.org on
any reports.
...
Changes since 2.6.23-rc2-mm1:
...
git-ne
Brandon Philips wrote:
I sent this last week as part of my devres patches but it is purely a
bug fix and can be merged now.
On a slot_reset event pci_disable_device() is never called so calling
pci_enable_device() will unbalance the enable count.
Signed-off-by: Brandon Philips <[EMAIL PROTECTED
Auke Kok wrote:
This patch adds support for the Intel 82598 PCI-Express 10GbE
chipset. Devices will be available on the market soon.
This version of the driver is largely the same as the last release:
* Driver uses a single RX and single TX queue, each using 1 MSI-X
irq vector.
* Driver runs
time.
happens to everyone :)
Thanks for letting us know.
Auke
On Mon, 06 Aug 2007 17:45:09 -0700, Kok, Auke wrote
[moving to netdev mailinglist]
ericj wrote:
On Mon, 6 Aug 2007 11:20:58 -0500, ericj wrote
On Mon, 06 Aug 2007 12:13:28 -0400, Jeff Garzik wrote
eepro100 is going to be re
Andi Kleen wrote:
"Kok, Auke" <[EMAIL PROTECTED]> writes:
All,
Another update on e1000e. Many thanks to Jeff for helping out and
getting this going forward. The driver is unfortunately still too
large to post, so please use the URL's below to review:
Just some
[moving to netdev mailinglist]
ericj wrote:
On Mon, 6 Aug 2007 11:20:58 -0500, ericj wrote
On Mon, 06 Aug 2007 12:13:28 -0400, Jeff Garzik wrote
eepro100 is going to be removed. Please try e100 on 2.6.22 or
2.6.23-rc2.
I will give the 2.6.23 a try.
I tried 2.6.23-rc2 and there was no cha
All,
Another update on e1000e. Many thanks to Jeff for helping out and getting this
going forward. The driver is unfortunately still too large to post, so please
use the URL's below to review:
http://foo-projects.org/~sofar/e1000e-20070806.patch [525k]
http://foo-projects.org/~sofar
Simon Arlott wrote:
00:0a.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller
(Copper) (rev 01)
Subsystem: Intel Corp.: Unknown device 1012
Flags: bus master, 66Mhz, medium devsel, latency 32, IRQ 5
Memory at e302 (64-bit, non-prefetchable) [size=12
Bill Fink wrote:
On Fri, 3 Aug 2007, Auke Kok wrote:
+
+Contents
+
+
+- In This Release
+- Identifying Your Adapter
+- Command Line Parameters
There is no section "Command Line Parameters" in the document.
-Bill
hmm yes, I removed all
Auke Kok wrote:
This patch adds support for the Intel 82598 PCI-Express 10GbE
chipset. Devices will be available on the market soon.
Also available through http and git:
http://foo-projects.org/~sofar/ixgbe-20070803-submission.patch
http://foo-projects.org/~sofar/ixgbe-20070803-submission.pa
Andrew Gallatin wrote:
To follow up on Jan-Bernd Themann's LRO patch earlier today,
this patch shows how the generic LRO interface can be used for
page based drivers.
Again, many thanks to Jan-Bernd Themann for leading this effort.
Drew
Singed off by: Andrew Gallatin <[EMAIL PROTECTED]>
pl
Jan-Bernd Themann wrote:
This patch shows how the generic LRO interface is used for SKB mode
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |1 +
drivers/net/ehea/ehea.h |9 -
drivers/net/ehea/ehea_ethtool.c | 15 +++
drivers/
Auke Kok wrote:
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
@@ -496,6 +516,14 @@ static void parse_cmdline(int argc, char **argp)
i = argc;
break;
}
+ if (mode == MODE_SQUEUE) {
+
All,
Recently new features have been written to add multiqueue support and LRO.
However, none of the patches touch on a basic configuration scheme and most use
module parameters.
I propose several patches to add support to change these features for LRO and
multiqueue. Currently these patche
Jeff Garzik wrote:
Stephen Hemminger wrote:
Why make this a user selectable option at all? Unless you want
to deal with out of tree drivers (not my problem), it should be hidden
to avoid having to explain an support it.
In this case it's an optional library kernel module. That seems to be a
Jan-Bernd Themann wrote:
Added LRO support using the "SKB aggregate" interface
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea.h |9 -
drivers/net/ehea/ehea_ethtool.c | 15 +++
drivers/net/ehea/ehea_main.c| 82 +
Matthew Wilcox wrote:
All drivers implement ethtool get_perm_addr the same way -- by calling
the generic function. So we can inline the generic function into the
caller and avoid going through the drivers.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
For the e100, e1000, ixgb parts:
Ack
Jeff Garzik wrote:
Andi Kleen wrote:
"Kok, Auke" <[EMAIL PROTECTED]> writes:
* Removed all multi-queue code
Why? With David's new multi NAPI work it will finally make sense, won't it?
It will come back, most definitely.
Not speaking for Auke, but I'm p
All,
Here's a short update on progress with e1000e, the future pci-express -only
version of the current e1000 driver. Since about a month ago, a lot has changed
so I'd like to keep everyone posted on progress and solicit ideas.
What happened since I posted "e1000new" ? Here's a summary:
* e
Jeff Garzik wrote:
Adrian Bunk wrote:
I found the discussion, and Christoph's e1000e sounds like the best name
("new" doesn't say whether it's a new driver for old hardware or a
driver for new hardware).
Yeah, I think "e1000new" is a lame name.
Moreover, Andrew should probably just drop thi
Andy Gospodarek wrote:
There seems to have been some discussion about a patch like this in the
past but I still haven't noticed any platforms fixes or noticed that
this got included, so I'd like to propose this modified version.
Thoughts?
I've written a completely new version for IBM based on
Jeff Garzik wrote:
Kok, Auke wrote:
http://foo-projects.org/~sofar/igb.patch [558K]
http://foo-projects.org/~sofar/igb.patch.bz2 [98K]
Just took a look at this.
This has the same problem as in the other thread -- huge internal API --
except this time, the problem is
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/
From [EMAIL PROTECTED] Tue Jul 3 02:03:55 2007
From: Marian Balakowicz <[EMAIL PROTECTED]>
Date: Tue, 03 Jul 2007 11:03:18 +0200
Subject: [PATCH] PCI: quirk_e100_interrupt() called too early
To: "Kok, Auke" &
[adding netdev]
David Fries wrote:
When I did a software suspend to disk then resumed the Intel network
card using eepro100 driver would be unable to transmit packets. I
tracked this down and found a register write after the print message
"DP83840 specific setup" which wasn't being executed whe
All,
We are pleased to announce a new Gigabit Ethernet product and its driver to the
linux community. This product is the Intel(R) 82575 Gigabit Ethernet adapter
family. Physical adapters will be available to the public soon. These adapters
come in 2- and 4-port versions (copper PHY) currently.
Jeff Garzik wrote:
Kok, Auke wrote:
Sorry for not replying to this earlier (I was on vacation for 2 days).
We had some internal discussions and all the noses appear to be facing
in the proper direction. I'm very happy with this and it will be my
highest priority to make this work. I
Jeff Garzik wrote:
Kok, Auke wrote:
I would strongly vote for taking a stripped down e1000new then, mask out
all the pci id's except ich9, remove all code for pre-pci-e silicon and
remove the most annoying and needlessly complexing code like the
semi-implemented multiqueue code that
[EMAIL PROTECTED] wrote:
This patch adds support for the Intel(R) 82598 based PCI Express 10GbE
adapters.
Please find the full driver as a patch to latest linus-2.6 tree here:
git-pull git://lost.foo-projects.org/~aveerani/git/linux-2.6 ixgbe
Andrew, I rebased this with the new driver cod
Jeff Garzik wrote:
Ignoring small potatoes, the merge stoppers in my mind are:
1) Transition plan. I strongly oppose switching all e1000 users en
masse to a new driver, especially so soon. Flag day transitions to
unproven drivers suck. Defaults don't work: users use the old driver
until t
Bill Davidsen wrote:
Adrian Bunk wrote:
On Thu, Jul 05, 2007 at 12:01:56PM -0400, Bill Davidsen wrote:
Please do not make unnecessary kernel changes which require changes in our
systems.
If you think the e100 driver fixes your problems use it and be happy. But
since you don't have to test
101 - 200 of 500 matches
Mail list logo
