On Wed, Jul 27, 2005 at 10:50:41AM -0700, Stephen Hemminger <[EMAIL PROTECTED]>
wrote:
> On Wed, 27 Jul 2005 10:06:45 +0200
> Lucas Nussbaum <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I'm interested in doing more complex stuff on inbound packets than
> > what is currently possible with ing_fil
On Wed, Jul 27, 2005 at 08:59:56AM -0400, jamal <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-27-07 at 10:06 +0200, Lucas Nussbaum wrote:
> > Hi,
> >
> > I'm interested in doing more complex stuff on inbound packets than what
> > is currently possible with ing_filter (I understand ingress doesn't
> >
From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo)
Date: Thu, 28 Jul 2005 02:46:56 -0300
> Oops, sorry I overlooked that, did a test without an the last one was with
> it defined, but I guess that leaving it as is for a few days wouldn't harm
> so that people get a bit of this debugging and perhap
Em Wed, Jul 27, 2005 at 10:43:45PM -0700, David S. Miller escreveu:
> From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo)
> Date: Thu, 28 Jul 2005 02:19:59 -0300
>
> > Indeed, there were some issues about that thing, I think I have those
> > handled
> > properly now, please take a look at the comm
From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo)
Date: Thu, 28 Jul 2005 02:19:59 -0300
> Indeed, there were some issues about that thing, I think I have those handled
> properly now, please take a look at the comments and tell me if you find any
> holes.
Looks good, I'll get to pulling this in
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Wed, 27 Jul 2005 22:33:32 -0700
> But with so many different workaround methods
> (TG3_FLAG_MBOX_WRITE_REORDER, TG3_FLAG_TXD_MBOX_HWBUG,
> TG3_FLG2_ICH_WORKAROUND, TG3_FLAG_5701_REG_WRITE_BUG, etc), it's
> more like:
>
> if (...)
>
Jeff Garzik wrote:
> Is this theory, or it has been actually measured?
>
> In x86-based CPUs at least (the largest tg3 platform), branch
> prediction
> often prefers
>
> if (...)
> direct_func_1()
> else
> direct_func_2()
>
> to
>
> tp->func()
>
Hi David,
Please consider pulling from:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git/
Regards,
- Arnaldo
tree 238b21aeaed399b847c0f0b0f7328cd69ffcd0d1
parent df2e0392536ecdd6385f4319f746045fd6fae38f
author Arnaldo Carvalho de Melo <[EMAI
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed, 27 Jul 2005 23:44:51 -0400
> In x86-based CPUs at least (the largest tg3 platform), branch prediction
> often prefers
>
> if (...)
> direct_func_1()
> else
> direct_func_2()
>
> to
>
> tp->func()
In
Michael Chan wrote:
This patch adds the basic function pointers to do register accesses in
the fast path. This was suggested by David Miller. The idea is that
various register access methods for different hardware errata can easily
be implemented with these function pointers and performance will
The register write to register 0x68 to restart interrupts is unnecessary
as the interrupt wasn't masked in that register by the irq handler. This
will save one register write in the fast path.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff -Nrup 5/drivers/net/tg3.c 6/drivers/net/tg3.c
--- 5
This patch adds the new workaround for 5703 A1/A2 if it is behind
certain ICH bridges. The workaround disables memory and uses config.
cycles only to access all registers. The 5702/03 chips can mistakenly
decode the special cycles from the ICH chipsets as memory write cycles,
causing corruption of
This patch adds the mailbox read method and also adds an inline function
tw32_mailbox_f() for mailbox writes that require read flush.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff -Nrup 3/drivers/net/tg3.c 4/drivers/net/tg3.c
--- 3/drivers/net/tg3.c 2005-07-26 07:40:18.0 -0700
+++
This patch adds various dedicated register read/write methods for the
existing workarounds, including PCIX target workaround, write with read
flush, etc. The chips that require these workarounds will use these
dedicated access functions.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff -Nrup
This patch adds the basic function pointers to do register accesses in
the fast path. This was suggested by David Miller. The idea is that
various register access methods for different hardware errata can easily
be implemented with these function pointers and performance will not be
degraded on chi
Hi,
I would like to propose a cleanup for struct sockaddr_in that I think
will make the code much more obvious and remove some icky padding
math:
sockaddr_in-cleanup.patch
Description: Binary data
Thanks for all your input!
Cheers,
Kyle Moffett
--
There are two ways of constructing a softw
A set of patches will follow that adds the last remaining register
access workaround for 5703 behind certain ICH bridges.
The first 3 patches add the infrastructure to use function pointers for
various register access methods. Patch #4 adds the new indirect register
access method.
It turns out th
On Wed, Jul 27, 2005 at 06:45:18PM -0700, cramerj wrote:
> Stupid question: Can we assume ethtool will only be used for networking
> devices with a 6-byte hardware address?
I presume not...?
> If not, then the driver-specific approach would give the flexibility of
> copying anything up to MAX_A
B'ah! Nevermind. I'll learn to read #defines one of these days.
Sorry for the spam.
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of cramerj
> Sent: Wednesday, July 27, 2005 6:45 PM
> To: John W. Linville; Jon Wetzel
> Cc: netdev@vger.kernel.org; [
Stupid question: Can we assume ethtool will only be used for networking
devices with a 6-byte hardware address?
If not, then the driver-specific approach would give the flexibility of
copying anything up to MAX_ADDR_LEN.
Perhaps increasing the count to MAX_ADDR_LEN is the way to go??
6/half-doz
Add generic ethtool operation for getting permanenet hardware address.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
This moves and renames the basically generic e1000_get_perm_addr
routine to ethtool_op_get_perm_addr, and causes e1000 to make use of
the new name.
drivers/net/e1000/e10
Build fixup for busted ethtool perm_addr support patch.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
The hunk below is busted...
On Tue, Jul 26, 2005 at 09:32:38AM -0500, Jon Wetzel wrote:
> @@ -683,6 +683,22 @@
> return ret;
> }
>
> +static int ethtool_get_perm_addr(struct ne
On Tue, Jul 26, 2005 at 09:34:10AM -0500, Jon Wetzel wrote:
> This patch gives the e1000 driver the ability to retreive the permanent
> hardware address of its device, via the framework established in part 1
> of this patch series. This patch fills in the new perm_addr field on
> probing, and imp
Herbert Xu wrote:
On Wed, Jul 27, 2005 at 03:18:39PM -0700, David S. Miller wrote:
One idea tossed around between Herbert Xu (also CC:'d) and myself is
to store a generation counter when we attach a route to a socket, then
sk_dst_check() can verify that this generation count matches the
current
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Tue, 26 Jul 2005 19:36:37 -0700
> # HG changeset patch
> # User [EMAIL PROTECTED]
> # Node ID 6cdd6f36d53678a016cfbf5ce667cbd91504d538
> # Parent 75716ae25f9d87ee2a5ef7c4df2d8f86e0f3f762
> Move in_aton from net/ipv4/utils.c to net/core/utils.c
This pa
On 7/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I sent the following posting to linux-kernel at kernel.org. One reply
> suggested I send it to [EMAIL PROTECTED] (mailto:netdev@vger.kernel.org) , so
> I am doing that.
>
> Below are some rather extensive logs showing the Linux 2.6.10 ker
On Wed, Jul 27, 2005 at 03:18:39PM -0700, David S. Miller wrote:
>
> One idea tossed around between Herbert Xu (also CC:'d) and myself is
> to store a generation counter when we attach a route to a socket, then
> sk_dst_check() can verify that this generation count matches the
> current IPSEC flow
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Sun, 24 Jul 2005 07:39:12 +0200
> [IPV4/6]: Check if packet was actually delivered to a raw socket to decide
> whether to send an ICMP unreachable
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Applied, thanks Patrick.
-
To unsubscribe fro
> On Jul 27, 2005, at 13:08, Randy Dunlap wrote:
>
> >
> >
> >> On Jul 25, 2005, at 16:06, Francois Romieu wrote:
> >>
> >>
> >>
> +int mdiobus_register(struct mii_bus *bus)
> +{
> +int i;
> +int err = 0;
> +
> +spin_lock_init(&bus->mdio_lock);
> +
>
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 27 Jul 2005 14:38:35 -0700
>Summary: IPSec incompabilty. Linux kernel waits to long to start
> using new SA for outbound traffic.
I think this is the known bug where we don't notice that a route
attached to a socke
Begin forwarded message:
Date: Wed, 27 Jul 2005 14:31:20 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 4952] New: IPSec incompabilty. Linux kernel waits to
long to start using new SA for outbound traffic.
http://bugzilla.kernel.org/show_bug.cgi?id=4952
From: Andrew McDonald <[EMAIL PROTECTED]>
Date: Sat, 23 Jul 2005 19:04:43 +0100
> Take account of whether a socket is bound to a particular device when
> selecting an IPv6 raw socket to receive a packet. Also perform this
> check when receiving IPv6 packets with router alert options.
>
> Signed-o
From: Kyle Moffett <[EMAIL PROTECTED]>
Subject: Re: [PATCH] setsockopt locking fix
Date: Wed, 27 Jul 2005 16:48:21 -0400
> On Jul 27, 2005, at 16:16:02, David S. Miller wrote:
> > Fix is correct, good thing it only hits Sparc :-)
> >
> > But your patch does not apply cleanly (perhaps your
> > emai
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Wed, 27 Jul 2005 14:11:51 -0700
> Unbalanced netlink_table_ungrab() in the netlink stuff in git-net.patch.
Applied to net-2.6.14, thanks Andrew.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PRO
On Wed, Jul 27, 2005 at 01:19:00PM -0700, David S. Miller wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
> Date: Tue, 26 Jul 2005 19:36:37 -0700
>
> > # HG changeset patch
> > # User [EMAIL PROTECTED]
> > # Node ID 6cdd6f36d53678a016cfbf5ce667cbd91504d538
> > # Parent 75716ae25f9d87ee2a5ef7c4df2
From: Matt Mackall <[EMAIL PROTECTED]>
Date: Wed, 27 Jul 2005 13:46:22 -0700
> Odd, gitweb of Linus' tree seems to disagree. I see it depends on
> NETDEVICES && INET && EXPERIMENTAL. NETDEVICES has been there since
> the beginning of git history and according to my Mercurial import from
> BKCVS, i
Andrew James Wade <[EMAIL PROTECTED]> wrote:
>
> Hello, my kernel crashes on boot with the following BUG():
Indeed it will.
> ENABLING IO-APIC IRQs
> ..TIMER: vector=0x31 pin1=2 pin2=-1
> softlockup thread 0 started up.
> NET: Registered protocol family 16
> [ cut here ]
>
On Jul 27, 2005, at 16:16:02, David S. Miller wrote:
Fix is correct, good thing it only hits Sparc :-)
But your patch does not apply cleanly (perhaps your
email client mangled it somehow) and I need to have
a "Signed-off-by: " line in order to apply the
patch.
Fixed. Attached is below. Patch
From: Kyle Moffett <[EMAIL PROTECTED]>
Date: Wed, 27 Jul 2005 13:47:30 -0400
> # HG changeset patch
> # User Kyle Moffett <[EMAIL PROTECTED]>
> # Node ID 77475acbe89242e63e6fd73dc66fe52643011ed7
> # Parent 43cd2abd0f4c5d2e8ee4666d6bf1f0b96e252e54
> Fix a bug where sock_reset_flag() was called wit
gcc found an (although perhaps harmless) bug:
<-- snip -->
...
CC net/ieee80211/ieee80211_crypt.o
In file included from net/ieee80211/ieee80211_crypt.c:21:
include/net/ieee80211.h:26:5: warning: "WIRELESS_EXT" is not defined
CC net/ieee80211/ieee80211_crypt_wep.o
In file included
Andy Fleming <[EMAIL PROTECTED]> :
[kcalloc]
> Should we move the function, then, to include/linux/slab.h? Or
> somewhere else?
It is already in mm/slab.c
[rc = request_irq(...)]
It appears in drivers/net/*c. Jeff Garzik used to suggest something
similar but it does not matter as long as you
On Jul 27, 2005, at 13:08, Randy Dunlap wrote:
On Jul 25, 2005, at 16:06, Francois Romieu wrote:
+int mdiobus_register(struct mii_bus *bus)
+{
+int i;
+int err = 0;
+
+spin_lock_init(&bus->mdio_lock);
+
+if (NULL == bus || NULL == bus->name ||
+NULL == bus->re
> On Jul 25, 2005, at 16:06, Francois Romieu wrote:
>
>
> >> +int mdiobus_register(struct mii_bus *bus)
> >> +{
> >> +int i;
> >> +int err = 0;
> >> +
> >> +spin_lock_init(&bus->mdio_lock);
> >> +
> >> +if (NULL == bus || NULL == bus->name ||
> >> +NULL == bus->read |
On Jul 25, 2005, at 16:06, Francois Romieu wrote:
[snip]
+config DAVICOM_PHY
+bool "Drivers for Davicom PHYs"
+depends on PHYLIB
+---help---
+ Currently supports dm9161e and dm9131
[snip]
Yeah, I resisted splitting the patch up for this reason. Suffice it
to say, you
On Wed, 27 Jul 2005 10:06:45 +0200
Lucas Nussbaum <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm interested in doing more complex stuff on inbound packets than
> what is currently possible with ing_filter (I understand ingress
> doesn't allow child classes , and can only drop/pass packets, not
> store
Hi,
I am one of the network admins of a campus of large community who
tries to make sure that the academic community is kept happy in spite
of a congested access link. My professor keeps asking me why can't you
give higher bandwidth for web access to educational, and any academic
related sites. I
# HG changeset patch
# User Kyle Moffett <[EMAIL PROTECTED]>
# Node ID 77475acbe89242e63e6fd73dc66fe52643011ed7
# Parent 43cd2abd0f4c5d2e8ee4666d6bf1f0b96e252e54
Fix a bug where sock_reset_flag() was called without lock_sock()
diff -r 43cd2abd0f4c -r 77475acbe892 net/core/sock.c
--- a/net/core/so
Resending and requesting comments. (Patch was against 2.6.13-rc1,
so it's a little stale by now.)
-- Forwarded message --
.
Version 2 of the rfc/patch is attached. It has been changed
as indicated in the commentary below.
Diffstat:
include/linux/sysctl.h |1
net/i
So 20 emails or so later ...
On Wed, 2005-27-07 at 08:43 -0700, Ben Greear wrote:
> I don't see a good reason for the feature, or at least nothing that
> justifies the work of trying to implement it.
You are the one who pointed the ifindex issue. What a waste of time.
> What benefits do you e
jamal wrote:
On Tue, 2005-26-07 at 09:54 -0700, Ben Greear wrote:
[..]
You will need to enforce that nothing else gets the index 34 while eth7 is
removed.
How do you do that?
Thats trivial if you assume there's one management app which most of the
router vendors implementing it have. It
On Wed, 2005-27-07 at 10:06 +0200, Lucas Nussbaum wrote:
> Hi,
>
> I'm interested in doing more complex stuff on inbound packets than what
> is currently possible with ing_filter (I understand ingress doesn't
> allow child classes , and can only drop/pass packets, not store one to
> send it later)
On Tue, 2005-26-07 at 13:00 -0700, David S. Miller wrote:
>
> Calling __dev_get_by_index() at every classification check is quite
> silly and potentially expensive, so let's call using ifindex a last
> resort, yet correct, fix.
Just double checking (I think we are saying the same thing),
that usi
On Tue, 2005-26-07 at 09:54 -0700, Ben Greear wrote:
[..]
> You will need to enforce that nothing else gets the index 34 while eth7 is
> removed.
> How do you do that?
Thats trivial if you assume there's one management app which most of the
router vendors implementing it have. It will get tric
On Tue, Jul 26, 2005 at 04:37:19PM -0700, David S. Miller wrote:
> From: Harald Welte <[EMAIL PROTECTED]>
> Date: Sat, 23 Jul 2005 16:15:52 -0400
>
> > The attached patch adds support for refcounting of modules implementing
> > netlink protocols. The idea is that you prevent the module from
> > d
Hi,
I'm interested in doing more complex stuff on inbound packets than what
is currently possible with ing_filter (I understand ingress doesn't
allow child classes , and can only drop/pass packets, not store one to
send it later).
While this is understandable because it would conflict with the be
Trivial patch adding netpoll support to cs89x0 driver.
Signed-off-by: Deepak Saxena <[EMAIL PROTECTED]>
Please apply,
~Deepak
diff --git a/drivers/net/cs89x0.c b/drivers/net/cs89x0.c
--- a/drivers/net/cs89x0.c
+++ b/drivers/net/cs89x0.c
@@ -86,6 +86,7 @@
Deepak Saxena : [EMAIL PROTECT
56 matches
Mail list logo
