Hi Jeff,
Any update on these patch submission? Is it in queue?
Thanks,
~Siva
-Original Message-
From: Veena Parat [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 19, 2007 3:27 PM
To: netdev@vger.kernel.org; [EMAIL PROTECTED]
Cc: Leonid Grossman; Ramkrishna Vepa; Rastapur Santosh;
On Thu, Jun 28, 2007 at 02:55:51PM +0200, Patrick McHardy wrote:
Jarek Poplawski wrote:
On Thu, Jun 28, 2007 at 02:23:36PM +0200, Patrick McHardy wrote:
Jarek Poplawski wrote:
@@ -202,7 +201,6 @@ void gen_kill_estimator(struct gnet_stats_basic
*bstats,
struct gen_estimator *est,
On Fri, Jun 29, 2007 at 09:02:41AM +0200, Jarek Poplawski wrote:
...
same *bstats *rate_est more than once (or max twice if we let
to add, change remove them independently).
...but this doesn't look sensible at all!
So, maybe, if we would need something counted with two intervals...
But,
Update...
I did 2 tests :
1) booted with option acpi=off
It booted correctly, i managed to get some load on one of the card and after a
while (10 minutes i guess) the Timeout occurs. Side effect, at the same moment
the sata contolers lost control of the disks somehow and the raid 5 array on
Ok everything is checked into net-2.6.23, thanks everyone.
Dave, thank you for your patience and feedback on this whole process.
Patrick and everyone else, thank you for your feedback and assistance.
I am looking at your posed virtualization question, but I need sleep
since I just remembered
David Miller wrote:
From: PJ Waskiewicz [EMAIL PROTECTED]
Date: Thu, 28 Jun 2007 09:21:13 -0700
-struct net_device *alloc_netdev(int sizeof_priv, const char *name,
- void (*setup)(struct net_device *))
+struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
+
Kumar Gala wrote:
Please pull from 'for_linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_linus
to receive the following updates:
drivers/net/gianfar.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Kumar Gala (1):
gianfar: Fix typo
On Thu, 2007-28-06 at 11:45 +0200, Johannes Berg wrote:
No, the controller is the only other generic netlink multicast user
according to what I've found. :)
Scanning the code - true ;- Iam a little suprised that the task
accounting folks didnt use it to periodically dump stats.
actually
Johannes Berg wrote:
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
c) Use a global hash table to store all the genl_multicast_groups;
I think this (handwaving) should be searchable by i) name ii)ID and iii)
family.
Yeah, makes sense, I never liked the bitmap stuff I did there.
Do
Ive changed the topic for you friend - otherwise most people wont follow
(as youve said a few times yourself ;-).
On Thu, 2007-28-06 at 21:20 -0700, David Miller wrote:
Now I get to pose a problem for everyone, prove to me how useful
this new code is by showing me how it can be used to solve
On Fri, 2007-06-29 at 07:17 -0400, jamal wrote:
No, the controller is the only other generic netlink multicast user
according to what I've found. :)
Scanning the code - true ;- Iam a little suprised that the task
accounting folks didnt use it to periodically dump stats.
:)
Because of
On Fri, 2007-29-06 at 13:28 +0200, Johannes Berg wrote:
On Fri, 2007-06-29 at 07:17 -0400, jamal wrote:
Because of this I'd really prefer if we could hold off on adding groups,
but I can handle both cases fine by just reserving a family and group ID
for the current users.
sure - if you
On Fri, 2007-06-29 at 07:48 -0400, jamal wrote:
sure - if you rush you can make it into Daves 2.6.23; then both can
conform at the same time.
Yeah, I'll have to see whether I can make that. If not, no big deal
either.
Ok :) Though I'm not sure I understood the suggestion of sending just
On Fri, 2007-29-06 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name?
As i see it: the name would be unique per family
Its like DNS IP to name mapping essentially (in the simple case of IP
being globaly reachable). You do a discovery of the ID by knowing
Johannes Berg wrote:
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name? Or would it suffice
to have them associated with the genl family and be able to find out
the starting group number? In that case something like
struct
Francois Romieu wrote:
Jens Stroebel [EMAIL PROTECTED] :
[...]
Would it
be possible to apply the single patch to 2.6.21.5 and get a working
driver?
Mantra: mainline first, stable later.
hm .. OK.
In the next future, most of this patchset will hopefully go into
2.6.23-rc1. Some people
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name? Or would it suffice
to have them associated with the genl family and be able to find out
the starting group number? In that case something like
struct genl_mc_groups {
struct
jamal wrote:
On Thu, 2007-28-06 at 21:20 -0700, David Miller wrote:
Each guest gets a unique MAC address. There is a queue per-port
that can fill up.
What all the drivers like this do right now is stop the queue if
any of the per-port queues fill up, and that's why my sunvnet
driver does
I'm getting this on current -git after adding an obexfs mount
to my fstab:
=
[ INFO: possible recursive locking detected ]
2.6.22-rc6 #2
-
obexfs/3786 is trying to acquire lock:
(sk_lock-AF_BLUETOOTH){--..},
Johannes Berg wrote:
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name? Or would it suffice
to have them associated with the genl family and be able to find out
the starting group number? In that case something like
struct
On Fri, 2007-06-29 at 14:48 +0200, Patrick McHardy wrote:
Hmm, another thought: since we have 32 bits for group numbers and 16
bits for families we could just reserve 16 bits for groups within each
family. Or do we get trouble with that because in some place there's a
group bitmap or
On Fri, 2007-29-06 at 13:59 +0200, Patrick McHardy wrote:
I'm guessing that that wouldn't allow to do unicast filtering for
the guests on the real device without hacking the bridge code for
this special case.
For ingress (i guess you could say for egress as well): we can do it as
well today
On Fri, 2007-06-29 at 13:51 +0200, Patrick McHardy wrote:
Do multicast groups have to have a seperate name? Or would it suffice
to have them associated with the genl family and be able to find out
the starting group number? In that case something like
struct genl_mc_groups {
struct
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
a) i.e other than the reserved group for controller (which you seem to
be taking care of), every other genetlink user has to explicitly
register when they need a mcast group.
Hm. I'm starting to dislike the dynamic registration the more I think
jamal wrote:
On Fri, 2007-29-06 at 13:59 +0200, Patrick McHardy wrote:
The difference to a real bridge is that the
all addresses are completely known in advance, so it doesn't need
promiscous mode for learning.
You mean the per-virtual MAC addresses are known in advance, right?
Yes.
jamal wrote:
On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
Johannes Berg wrote:
Hmm, another thought: since we have 32 bits for group numbers and 16
bits for families we could just reserve 16 bits for groups within each
family. Or do we get trouble with that because in some
On Fri, 2007-29-06 at 15:08 +0200, Patrick McHardy wrote:
jamal wrote:
On Fri, 2007-29-06 at 13:59 +0200, Patrick McHardy wrote:
Right, but the current bridging code always uses promiscous mode
and its nice to avoid that if possible.
Looking at the code, it
should be easy to avoid though
On Fri, 2007-29-06 at 15:15 +0200, Johannes Berg wrote:
(1) register group X with non-root
(2) non-root app A binds group X
(3) kernel unregisters group X
Kernel sends event (controller) Group X is gone or family Y which
used to own group X is gone
(4) something else in kernel
On Fri, 2007-29-06 at 14:57 +0200, Johannes Berg wrote:
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
Hm. I'm starting to dislike the dynamic registration the more I think
about it. Now when a group is unregistered I'd have to unbind everybody
who's currently using it...
I understood you
On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
Johannes Berg wrote:
Hmm, another thought: since we have 32 bits for group numbers and 16
bits for families we could just reserve 16 bits for groups within each
family. Or do we get trouble with that because in some place there's a
Johannes Berg wrote:
On Wed, 2007-06-27 at 19:24 -0400, jamal wrote:
a) i.e other than the reserved group for controller (which you seem to
be taking care of), every other genetlink user has to explicitly
register when they need a mcast group.
Hm. I'm starting to dislike the dynamic
On Fri, 2007-06-29 at 15:11 +0200, Patrick McHardy wrote:
Hm. I'm starting to dislike the dynamic registration the more I think
about it. Now when a group is unregistered I'd have to unbind everybody
who's currently using it... At least when I want to enforce
root/non-root binds which is
Johannes Berg wrote:
On Fri, 2007-06-29 at 15:11 +0200, Patrick McHardy wrote:
Hm. I'm starting to dislike the dynamic registration the more I think
about it. Now when a group is unregistered I'd have to unbind everybody
who's currently using it... At least when I want to enforce
jamal wrote:
On Fri, 2007-29-06 at 15:12 +0200, Patrick McHardy wrote:
jamal wrote:
On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
Our philosophy in genetlink is to have dynamic resources allocated and
released - remember the real reason we even have this is because we were
On Fri, 2007-06-29 at 15:23 +0200, Patrick McHardy wrote:
I'm not sure that the only sensible thing to do is right, we
do allow dynamic registration of netlink families and do the
module reference thing anyway (admittedly, I never liked that
and the autoloading part very much). I guess it
Johannes Berg wrote:
On Fri, 2007-06-29 at 15:23 +0200, Patrick McHardy wrote:
If you do want the dynamic unregistation *and* the non-root mc
listening then I guess you don't have a choice but to unbind
sockets at unregistration. That shouln't be a real problem,
without having though much about
On Fri, 2007-06-29 at 15:44 +0200, Patrick McHardy wrote:
How about for now I only allow dynamic registration (no unregistration)
and just send out when new groups are registered, and also give
userspace a list of registered mc groups when they ask for a family
description? That should
Johannes Berg wrote:
On Fri, 2007-06-29 at 15:44 +0200, Patrick McHardy wrote:
How about for now I only allow dynamic registration (no unregistration)
and just send out when new groups are registered, and also give
userspace a list of registered mc groups when they ask for a family
On Fri, 2007-29-06 at 15:12 +0200, Patrick McHardy wrote:
jamal wrote:
On Fri, 2007-29-06 at 14:48 +0200, Patrick McHardy wrote:
Our philosophy in genetlink is to have dynamic resources allocated and
released - remember the real reason we even have this is because we were
running out of
On Fri, 2007-06-29 at 15:53 +0200, Patrick McHardy wrote:
If you're worried about patch size, you could sell that part as a
bugfix :)
Heh. Actually, right now I'm more worried about how much work I have to
do short-term.
This patch keeps the bitmap but does dynamic group allocation. Just to
On Fri, 29 Jun 2007 11:48:37 +0200 (CEST)
Pierre Capillon [EMAIL PROTECTED] wrote:
Hello,
I'm a french IT engineering student and as part of my
internship, I'm writing a congestion avoidance module
based on research by my tutor. It aims at better
efficiency and throughput on mobile adhoc
On Fri, 2007-06-29 at 16:05 +0200, Johannes Berg wrote:
+ mc_groups =
+ kzalloc(mc_groups_bits/BITS_PER_LONG + 1,
+ GFP_KERNEL);
+ if (!mc_groups)
+ return
Sivakumar Subramani wrote:
Hi Jeff,
Any update on these patch submission? Is it in queue?
it's in my mbox queue, to be reviewed.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Fri, 2007-06-29 at 16:19 +0200, Johannes Berg wrote:
Uh huh, this reallocation is buggy. Fixed version below.
More breakage, sorry about the patch-spam.
Btw, I notice that the bug we talked about isn't present in practice
since we have no multicast users except for the always-present
On Fri, Jun 29, 2007 at 10:50:20AM +0200, Jean-Baptiste Vignaud wrote:
Update...
I did 2 tests :
1) booted with option acpi=off
It booted correctly, i managed to get some load on one of the card
and after a while (10 minutes i guess) the Timeout occurs. Side effect,
at the same moment the
Jens Stroebel wrote:
Francois Romieu wrote:
[...]
It may help and/or accelerate things if you can narrow the fix(es) in
the current r8169 serie.
Instead, I built 2.6.21.5+[a patch I snatched from a mail communication
you had on 2007-06-20
(Msg-ID: [EMAIL PROTECTED] )].
I will attach it
Patrick McHardy wrote:
Right, but the current bridging code always uses promiscous mode
and its nice to avoid that if possible. Looking at the code, it
should be easy to avoid though by disabling learning (and thus
promisous mode) and adding unicast filters for all static fdb entries.
I am
Patrick McHardy wrote:
Ben Greear wrote:
Could someone give a quick example of when I am wrong and promisc mode
would allow
a NIC to receive a significant number of packets not really destined for
it?
In a switched environment it won't have a big effect, I agree.
It might help avoid
Ben Greear wrote:
Patrick McHardy wrote:
Right, but the current bridging code always uses promiscous mode
and its nice to avoid that if possible. Looking at the code, it
should be easy to avoid though by disabling learning (and thus
promisous mode) and adding unicast filters for all static
David Stevens [EMAIL PROTECTED] writes:
I think there's a more general problem that's a huge hassle. There are
lots of
new SNMP MIB's, but no conventions (that I'm aware of, at least) to allow
for
changes to the /proc entries that get them to applications.
Actually /proc/net/snmp and
Hi Auke,
I understand there is some delay in getting e1000-7.5.5 into the
upstream kernel given the major re-working of the chipset specific
parts.
I wonder would it be feasible in the meantime to backport the ich9
support and push it upstream?
A first-cut at the backport
On Fri, Jun 29, 2007 at 06:29:18PM +0100, Mark McLoughlin wrote:
I understand there is some delay in getting e1000-7.5.5 into the
upstream kernel given the major re-working of the chipset specific
parts.
I wonder would it be feasible in the meantime to backport the ich9
support
This patch makes the PHY optional for ucc_geth.c ethernet driver.
This is useful to support a direct mii to mii connection to, for example,
a onboard swicth.
Signed-off-by: Joakim Tjernlund [EMAIL PROTECTED]
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 32bb748..8630294
Jens Stroebel [EMAIL PROTECTED] :
[...]
It seems like the patch is able to change things in a way which makes
the machine lock up hard. Pity that, looked so promising at first...
As a 8168 user, you should really apply the serie I sent yesterday before
anything else. Then you can try again this
That works ok for some things, like new global counters, but some
items really fit best in existing files and the concern there is about
other uses of them beyond the standard tools.
Examples:
-addition of route age in /proc/net/route and /proc/net/ipv6_route
Routing information
Please pull from branch 'r8169-for-jeff-20070629' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
r8169-for-jeff-20070629
to get the changes below.
Following mails on netdev describe each patch.
Distance from 'netdev-2.6-upstream
Use netdev_alloc_skb and remove the useless sk_buff * argument of
rtl8169_alloc_rx_skb.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 27 ++-
1 files
The former style suggests a modulo arithmetic misuse but
the expression should never be 0. Even if it does, the
driver will simply loop longer than expected (not that
the remaining parts of the system will necessarily
appreciate it...).
Let's warn the user when something goes wrong and try
to go
- pci_dma_sync_single_for_cpu is not needed for a single large packet
- remove the function pointer to help gcc optimizing the inline
pci_dma functions.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
It hasn't summed anything in over 7 years, and it's
just a straight mempcy ala skb_copy_to_linear_data()
so just get rid of it.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |2 +-
1
On Fri, Jun 29, 2007 at 12:51:02PM -0700, Kok, Auke wrote:
For distro's not following kernel.org releases we have the perfect
solution: A fully tested 7.5.5 driver on sourceforge that was extensively
tested against RHEL5 for instance, but also a lot of other older kernels.
I'm sure you and
rtl_hw_start_8168 inherits the content of rtl_hw_start_8169 minus
the code which depends on RTL_GIGA_MAC_VER_XY (XY != {11/12}).
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 34 +++---
1 files changed,
Rationale: rtl8169_hw_start will not help maintaining an unified
driver for different chipsets but people at Realtek are probably
too polite to say it distinctly.
Let's add the hook and keep hw_start handler unchanged.
As can be seen from the content of rtl8169_pci_tbl, the RTL_CFG_1
entry in
They aim to limit the amount of moved code when the hw_start
handler gets more specialized.
No functional change.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 53 +-
1 files changed,
- new identifier for the 8110SCe
- the PCI latency timer is set unconditionally. This part is identical
in Realtek's r8168 (8.001.00) and r8101 (1.001.00)
- initialization of the cache line size register is for the 8169s only
- more magic in rtl_hw_start_8169
- it is not possible to factor
The rx copybreak part is straightforward.
The align field in struct rtl_cfg_info is related to the alignment
requirements of the DMA operation. Its value is set at 2 to limit the
scale of possible regression but my old v1.21 8169 datasheet claims a
8 bytes requirements (which never appeared in
Extracted from version 1.001.00 of Realtek's r8101.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index
Signed-off-by: Rolf Eike Beer [EMAIL PROTECTED]
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index
It has been documented as deprecated:
- in MODULE_PARM_DESC since may 2005 ;
- at the top of the source file and in printk since june 2004.
Good bye.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 72
This one includes:
- more tweaks to rtl_hw_start_8168
- a work around for a Rx FiFO overflow issue on the 8168Bb
- rtl8169_{intr_mask/napi_event} are replaced with per-device fields,
namely tp-{intr/napi}_event
- rtl_cfg_info is converted to C99 for readability but the values are
not
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 5d9e754..d8862cd 100644
--- a/drivers/net/r8169.c
+++
Align the IP header when the chipset can DMA at any location (plain 0x8169).
Otherwise (0x8136/0x8168) obey the constraint imposed by the hardware.
This patch complements the previous alignment rework done for copybreak.
Original idea from Philip Craig [EMAIL PROTECTED]
Signed-off-by: Francois
Same thing as the previous change for rtl_hw_start_8168.
The 8101 related code in rtl_hw_start_8169 (see RTL_GIGA_MAC_VER_13)
goes away.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 47
...still a bit yucky though.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c | 20 ++--
1 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 56b9040..eb793fa
No functionnal change:
- trim the old history log
- whitespace/indent/case police
- unsigned int where signedness does not matter
- removal of obsolete assert
- needless cast from void * (dev_instance)
- remove dead code once related to power management
- use netdev_alloc_skb.
Signed-off-by:
Merged from Realtek's r8169-6.001 driver.
I have added some locking to protect against the arp monitoring
timer in the bonding driver. Accessing the configuration registers
is otherwise performed under RTNL locking.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL
It does not cost much and it will ease the identification of (so far)
unknown devices.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c
It does not really make sense to update the RX config register
before the mac filtering registers.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
Cc: Edward Hsu [EMAIL PROTECTED]
---
drivers/net/r8169.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
+ pci_write_config_byte(tp-pci_dev, PCI_LATENCY_TIMER, 0x40);
can you create a pci_set_latency_timer() for this please?
+
+ if (tp-mac_version = RTL_GIGA_MAC_VER_06)
+ pci_write_config_byte(tp-pci_dev, PCI_CACHE_LINE_SIZE, 0x08);
and something for this as well?
-
To
Francois Romieu wrote:
Please pull from branch 'r8169-for-jeff-20070629' in repository
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
r8169-for-jeff-20070629
to get the changes below.
Following mails on netdev describe each patch.
Distance from 'netdev-2.6-upstream
Arjan van de Ven wrote:
+ pci_write_config_byte(tp-pci_dev, PCI_LATENCY_TIMER, 0x40);
can you create a pci_set_latency_timer() for this please?
+
+ if (tp-mac_version = RTL_GIGA_MAC_VER_06)
+ pci_write_config_byte(tp-pci_dev, PCI_CACHE_LINE_SIZE, 0x08);
and
This conversation begins to go into a pointless direction already, as
I feared it would.
Nobody is going to configure bridges, classification, tc, and all of
this other crap just for a simple virtualized guest networking device.
It's a confined and well defined case that doesn't need any of
Jeff Garzik wrote:
Jason Lunz wrote:
What's the prognosis for the 7.5.5-series e1000 reorg going into
netdev-2.6?
As I have posted previously, I am not keen on merging basically an e1000
rewrite. That basically throws away all Internet-wide testing so far.
The rewrite was not done
On Fri, 29 Jun 2007 14:39:20 -0700
Kok, Auke [EMAIL PROTECTED] wrote:
That's why we want to introduce a second e1000 driver (named differently,
pick
any name) that contains the new code base, side-by-side into the kernel with
the
current e1000.
Sounds like a reasonable approach to me
Kok, Auke wrote:
That's why we want to introduce a second e1000 driver (named
differently, pick any name) that contains the new code base,
side-by-side into the kernel with the current e1000.
We do not want to introduce duplicate drivers for the same hardware. We
spend -years- before the
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
Kok, Auke [EMAIL PROTECTED] wrote:
That's why we want to introduce a second e1000 driver (named differently, pick
any name) that contains the new code base, side-by-side into the kernel with the
current e1000.
Sounds like a reasonable
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
Kok, Auke [EMAIL PROTECTED] wrote:
That's why we want to introduce a second e1000 driver (named differently, pick
any name) that contains the new code base, side-by-side into the kernel with the
current e1000.
Sounds like a reasonable
Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
Kok, Auke [EMAIL PROTECTED] wrote:
That's why we want to introduce a second e1000 driver (named differently, pick
any name) that contains the new code base, side-by-side into the kernel with the
current e1000.
Sounds
Kok, Auke wrote:
Jeff Garzik wrote:
Andrew Morton wrote:
On Fri, 29 Jun 2007 14:39:20 -0700
Kok, Auke [EMAIL PROTECTED] wrote:
That's why we want to introduce a second e1000 driver (named
differently, pick any name) that contains the new code base,
side-by-side into the kernel with the
On 6/29/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Given past history with duplicate drivers and the problems that they
cause -- I know, I've caused some of those problems :( -- I strongly
recommend against when it can be avoided.
Leaving e1000 with current hardware, and a new e1001 for newer
On 6/29/07, Andrew Grover [EMAIL PROTECTED] wrote:
I think making e1000new ICH9-and-newer isn't really the best place to
split it. The Windows e1000 driver got split on the PCI-PCIe
transition, something that clearly delineated what nics one driver
supported, and the other. There's no real
Andrew Grover wrote:
I think making e1000new ICH9-and-newer isn't really the best place to
split it. The Windows e1000 driver got split on the PCI-PCIe
transition, something that clearly delineated what nics one driver
supported, and the other. There's no real technical reason for
splitting now
Sorry if this is a duplication, I forgot to switch to plain text.
On 6/29/07, Jim McCullough [EMAIL PROTECTED] wrote:
It goes back to ICH7 for the PCIe support. That also includes models used as
plugin PCIe devices. I dont remember if ICH6 erra devices were PCI or PCIe.
I'll leave that
Jeff Garzik wrote:
Andrew Grover wrote:
I think making e1000new ICH9-and-newer isn't really the best place to
split it. The Windows e1000 driver got split on the PCI-PCIe
transition, something that clearly delineated what nics one driver
supported, and the other. There's no real technical
Jim McCullough wrote:
It goes back to ICH7 for the PCIe support. That also includes models used
as plugin PCIe devices. I dont remember if ICH6 erra devices were PCI or
PCIe. I'll leave that part for Auke.
On 6/29/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Andrew Grover wrote:
I think making
one possibility would be to merge e1000new with support only for chips
not supported by e1000, and semi-freeze e1000 (fixes only, new device
support goes into e1000new). Then if there are some devices that are
more naturally supported by e1000new, we could later on merge patches
to move support
From: jamal [EMAIL PROTECTED]
Date: Fri, 29 Jun 2007 21:30:53 -0400
On Fri, 2007-29-06 at 14:31 -0700, David Miller wrote:
Maybe for the control node switch, yes, but not for the guest network
devices.
And that is precisely what i was talking about - and i am sure thats how
the
97 matches
Mail list logo
