In article <[EMAIL PROTECTED]> (at Wed, 21 Mar 2007 00:26:09 +0100 (CET)),
YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> says:
> In article <[EMAIL PROTECTED]> (at Tue, 20 Mar 2007 15:16:40 -0700), Sridhar
> Samudrala <[EMAIL PROTECTED]> says:
>
> > On Tue, 2007-03-20 at 10:19 +0100, YOSHIFUJI H
Eric W. Biederman wrote:
Daniel Lezcano <[EMAIL PROTECTED]> writes:
3. General observations
---
The objective to have no performances degrations, when the network
namespace is off in the kernel, is reached in both solutions.
When the network is used outside the container a
>>The loss of performances is very noticeable inside the container and
>>seems to be directly related to the usage of the pair device and the
>>specific network configuration needed for the container. When the
>>packets are sent by the container, the mac address is for the pair
>>device but the IP
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_hw.c |1 -
drivers/net/forcedeth.c |8 ++-
drivers/net/mv643xx_et
Herbert Poetzl wrote:
On Wed, Mar 28, 2007 at 12:16:34AM +0200, Daniel Lezcano wrote:
Hi,
[ cut ]
3. General observations
---
The objective to have no performances degrations, when the network
namespace is off in the kernel, is reached in both solutions.
When the networ
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 08:02:21 +0200
> This is what I thought too at the begining.
>
> But after some thinking I recalled having to reboot machines just because
> netfilter was not in (because of noticeable performance hit), and I could
> find
> the tr
From: "Nikolaos D. Bougalis" <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 22:01:38 -0700
> What this boils down to is, yes, we can keep patching our own kernels to
> use tagged jenkins hashing if this affects us, waiting for something better
> to come along.
You don't have to patch, I put jen
Brice Goglin wrote:
Correctly detect when TSO should be used on transmit by looking at the
skb->gso_size rather than seeing if the frame was larger than our MTU.
The old method causes problems when a host with a large (jumbo) MTU is
sending to a host with a small (standard) MTU.
Signed-off-by: B
Jay Cliburn wrote:
From: Jay Cliburn <[EMAIL PROTECTED]>
The original vendor driver contained a private ether_crc_le() function
that produced an inverted crc. When we changed to the kernel version of
ether_crc_le(), we neglected to undo the inversion. Let's do it now.
Discovered by and patch p
[EMAIL PROTECTED] wrote:
From: "Cyrill V. Gorcunov" <[EMAIL PROTECTED]>
This patch adds checking for allocated DVMA memory and granted IRQ line.
Signed-off-by: Cyrill V. Gorcunov <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
applied to #upstream-fixes
-
To unsubscribe
Dale Farnsworth wrote:
From: Gabriel Paubert <[EMAIL PROTECTED]>
In this driver, the default ethernet address is first set by by calling
eth_port_uc_addr_get() which reads the relevant registers of the
corresponding port as initially set by firmware. However that function
used the port_num field
Ron Mercer wrote:
This was removed in a previous patch to increase performance, but
caused a transmit error for the 4032 chip.
Signed-off-by: Ron Mercer <[EMAIL PROTECTED]>
---
drivers/net/qla3xxx.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applied 1-4 to #upstream-fixes
-
Ayaz Abdulla wrote:
The nic poll routine was missing the call to the optimized irq routine.
This patch adds the missing call for the optimized path.
See http://bugzilla.kernel.org/show_bug.cgi?id=7950 for more information.
Signed-Off-By: Ayaz Abdulla <[EMAIL PROTECTED]>
applied 1-2
-
To un
David Miller a écrit :
From: Mark Huth <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 16:09:30 -0700
Actually, there are legitimate uses for this sort of API. The patch
allows an administrator to kill specific connections that are in use by
other applications, where the close is not available, si
Hi,
Replacing with time_after in drivers/net/eexpress.c
Applies and compiles clean on latest tree.Not tested.
thanks.
Signed-off-by: Shani Moideen <[EMAIL PROTECTED]>
diff --git a/drivers/net/eexpress.c b/drivers/net/eexpress.c
index 3868b80..7825f78 100644
--- a/drivers/net/eexpress.c
+++
From: Paul Walmsley <[EMAIL PROTECTED]>
Ejecting a PCMCIA IBM Token Ring card that has not had its dev->open()
called will reliably trigger an uninitialized spinlock oops when
spinlock debugging is enabled. The system then hangs, occasionally
softlockup oopsing. It seems that ibmtr.c:tok_interru
"Andi Kleen" ([EMAIL PROTECTED]) wrote:
To truly defend against this you would likely need a cryptographic
hash, which would be likely too slow.
I do not think that a cryptographically secure hash is necessary for
this. Using a better hash function (i.e. one which does a good job of
thror
Hi,
>> Wed, 28 Mar 2007 12:49:40 +0900 (JST)
>> [Subject: Re: [PATCH net-2.6.22] [IPV6] FIB6RULE: Find source address during
>> looking up route.]
>> YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> wrote...
> > Out of curiosity, what sort of rules would have this flag set?
> > The majority of looku
When looking up route for destination with rules with
source address restrictions, we may need to find a source
address for the traffic if not given.
Based on patch from Noriaki TAKAMIYA <[EMAIL PROTECTED]>.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
---
include/linux/fib_rules.h | 1
In article <[EMAIL PROTECTED]> (at Tue, 27 Mar 2007 16:25:19 +0200), Thomas
Graf <[EMAIL PROTECTED]> says:
> * YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2007-03-27 22:45
> > When looking up route for destination with rules with
> > source address restrictions, we may need to find a sour
David Miller wrote:
It doesn't build with bridging disabled, and I can't see
exactly how to work out the 'ret' assignment in the way
the new code works so I'm reverting.
Please resubmit a version that builds and works properly
with bridging enabled and disabled, thanks :-)
okay, i'll fix it
John Heffner <[EMAIL PROTECTED]> wrote:
>
> Responding to myself in good form :P I'll add that there are other ways
> to do this currently but all I know of are hackish, f.e. using a raw
> socket to send RST packets to yourself.
While not pretty, it is easy enough to ptrace a process using gdb
黃建興-Jesse wrote:
> Dear Sirs,
>
> I have got the status.
> I appreciate your contribution to this driver.
> And if anything I can help or any update, please let me know.
Someone needs to send me a signed-off patch.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netde
From: David Miller <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 19:38:09 -0700 (PDT)
> It doesn't build with bridging disabled, and I can't see
> exactly how to work out the 'ret' assignment in the way
> the new code works so I'm reverting.
>
> Please resubmit a version that builds and works proper
It doesn't build with bridging disabled, and I can't see
exactly how to work out the 'ret' assignment in the way
the new code works so I'm reverting.
Please resubmit a version that builds and works properly
with bridging enabled and disabled, thanks :-)
-
To unsubscribe from this list: send the l
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 20 Mar 2007 14:15:52 -0700
> While in the STP learning state, don't route packets; wait until
> forwarding delay has expired. The purpose of the forwarding delay
> is to detect loops in the network, and if a brouter started up
> and started fo
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 20 Mar 2007 14:17:09 -0700
> Instead of hashing the whole Ethernet address, it should be faster
> to just use the last 4 bytes. Add a random salt value to the hash
> to make it more difficult to construct worst case DoS hash chains.
>
> Signe
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 20 Mar 2007 14:12:51 -0700
>
> Change the bridging hook to be simple function with return value
> rather than modifying the skb argument. This could generate better
> code and is cleaner.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTE
Daniel Lezcano <[EMAIL PROTECTED]> writes:
>
> 3. General observations
> ---
>
> The objective to have no performances degrations, when the network
> namespace is off in the kernel, is reached in both solutions.
>
> When the network is used outside the container and the network
From: John Heffner <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 20:27:44 -0400
> As a concrete example of a way I've used this type of feature is to
> defend against a netkill [1] style attack, where the defense involves
> making decisions about which connections to kill when memory gets
> scarce
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 20:07:50 -0300
> Okay, Hairaru is this way:
>
> master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Pulled, thanks a lot.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a messa
From: Mark Huth <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 16:09:30 -0700
> Actually, there are legitimate uses for this sort of API. The patch
> allows an administrator to kill specific connections that are in use by
> other applications, where the close is not available, since the socket
> i
Hi Mr. David
I have modified my patch according to you advice. I think -
EHOSTUNREACH
is only for "input path". In "output" path, we can just simply check
-ENETUNREACH (^_^), the patch is shown in the end of this mail.
BTW: my E-mail has been changed to [EMAIL PROTECTED]
>> Function nee
Jay Cliburn <[EMAIL PROTECTED]> writes:
> On Tue, 27 Mar 2007 14:42:20 -0600
> [EMAIL PROTECTED] (Eric W. Biederman) wrote:
>
> Thanks for replying, Eric. I've added atl1-devel to the cc list.
>
>> Do you have msi's working in 2.6.21-rc4 in the x86_64 kernel?
>
> I can't personally verify it anym
On Wed, 28 Mar 2007 01:00:24 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Subject: atl1 net driver: problem with sockets
> References : http://lkml.org/lkml/2007/3/21/248
> Submitter : Jose Alberto Reguero <[EMAIL PROTECTED]>
> Patch : http://marc.info/?l=linux-netdev&m=117502041808665
From: Jay Cliburn <[EMAIL PROTECTED]>
The original vendor driver contained a private ether_crc_le() function
that produced an inverted crc. When we changed to the kernel version of
ether_crc_le(), we neglected to undo the inversion. Let's do it now.
Discovered by and patch proffered by Jose Albe
John Heffner wrote:
I also believe this is a useful thing to have. I'm not 100% sure this
ioctl is the way to go, but it seems reasonable. This directly
corresponds to writing deleteTcb to the tcpConnectionState variable in
the TCP MIB (RFC 4022). I don't think it constitutes a protocol viol
On Wed, 2007-03-28 at 07:30 +1000, Herbert Xu wrote:
> Sorry, that patch is indeed broken. We do need to set IF_READY in
> the case where all addresses were deleted (including the link-local)
> and then recreated. The IPv6 device will be destroyed and recreated
> too in that case.
Your new patc
Mark Huth wrote:
David Miller wrote:
From: [EMAIL PROTECTED] (David Griego)
Date: Tue, 27 Mar 2007 14:47:54 -0700
Adds an IOCTL for aborting established TCP connections, and is
designed to be an HA performance improvement for cleaning up, failure
notification, and application termination.
There is no reason for this ioctl at all. Either existing
facilities provide what you need or what you want is a
protocol violation we can't do.
I agree that 99 times out of ten such a mechanism serves only as a
massive KLUDGE to paper-over application bugs. I'll also sadly
point-out that su
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 22 Mar 2007 12:36:17 +0100
> jamal wrote:
> > The mutex is certainly a cleaner approach;
> > and a lot of the RCU protection would go away. I like it.
>
> Not as much as I initially thought, but at least we would have
> consistent locking for t
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Wed, 21 Mar 2007 13:58:47 +0300
> On Wed, Mar 21, 2007 at 11:54:45AM +0100, Patrick McHardy ([EMAIL PROTECTED])
> wrote:
> > Evgeniy Polyakov wrote:
> > > We would already do that on init.
> > > Some things become very confused, when nl_table is no
On Wed, Mar 28, 2007 at 12:16:34AM +0200, Daniel Lezcano wrote:
>
> Hi,
>
> I did some benchmarking on the existing L2 network namespaces.
>
> These patches are included in the lxc patchset at:
> http://lxc.sourceforge.net/patches/2.6.20
> The lxc7 patchset series contains Dmitry's patchset
On 3/28/07, Jay Cliburn <[EMAIL PROTECTED]> wrote:
On Tue, 27 Mar 2007 14:42:20 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
Thanks for replying, Eric. I've added atl1-devel to the cc list.
> Do you have msi's working in 2.6.21-rc4 in the x86_64 kernel?
I can't personally verify it anym
David Miller wrote:
From: [EMAIL PROTECTED] (David Griego)
Date: Tue, 27 Mar 2007 14:47:54 -0700
Adds an IOCTL for aborting established TCP connections, and is
designed to be an HA performance improvement for cleaning up, failure
notification, and application termination.
Signed-off-by:
On 3/27/07, David Miller <[EMAIL PROTECTED]> wrote:
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 18:56:11 -0300
> On 3/27/07, David Miller <[EMAIL PROTECTED]> wrote:
> > From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
> > Date: Tue, 27 Mar 2007 16:41:48 -0300
>
On Tue, 27 Mar 2007 14:42:20 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
Thanks for replying, Eric. I've added atl1-devel to the cc list.
> Do you have msi's working in 2.6.21-rc4 in the x86_64 kernel?
I can't personally verify it anymore because I removed x86_64 to
duplicate the MSI pro
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 18:56:11 -0300
> On 3/27/07, David Miller <[EMAIL PROTECTED]> wrote:
> > From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
> > Date: Tue, 27 Mar 2007 16:41:48 -0300
> >
> > > +static inline void skb_move_linear_data(const
From: [EMAIL PROTECTED] (David Griego)
Date: Tue, 27 Mar 2007 14:47:54 -0700
> Adds an IOCTL for aborting established TCP connections, and is
> designed to be an HA performance improvement for cleaning up, failure
> notification, and application termination.
>
> Signed-off-by: David Griego <[EM
Jeff Garzik <[EMAIL PROTECTED]> :
> Jesse Huang wrote:
> >Dear all:
> >
> >Would someone tell me the current status of IP1000A Linux Driver?
> >Would it be putted into Linux Kernel or not?
>
> I forgot what the status of this was? Didn't it need some cleanups?
More cleanups than what it already
El Martes, 27 de Marzo de 2007, Jose Alberto Reguero escribió:
> El Martes, 27 de Marzo de 2007, Jose Alberto Reguero escribió:
> > El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
> > > On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero
> >
> > ([EMAIL PROTECTED]) wrote:
> >
Hi,
I did some benchmarking on the existing L2 network namespaces.
These patches are included in the lxc patchset at:
http://lxc.sourceforge.net/patches/2.6.20
The lxc7 patchset series contains Dmitry's patchset
The lxc8 patchset series contains Eric's patchset
Here are the following scenar
On 3/27/07, David Miller <[EMAIL PROTECTED]> wrote:
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 16:41:48 -0300
> +static inline void skb_move_linear_data(const struct sk_buff *skb,
> + const int from_offset,
> +
Adds an IOCTL for aborting established TCP connections, and is
designed to be an HA performance improvement for cleaning up, failure
notification, and application termination.
Signed-off-by: David Griego <[EMAIL PROTECTED]>
---
include/linux/ipv6.h |8
include/linux/socket.h
Arnaldo Carvalho de Melo wrote:
> On 3/27/07, Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>> nf_nat_helper.c:mangle_content() could make use of this, but it
>> would need memmove. Something to do this with non-linear packets
>> would be even cooler :)
>
>
> Damn, that was so fast man! For the q
On 3/27/07, Patrick McHardy <[EMAIL PROTECTED]> wrote:
Arnaldo Carvalho de Melo wrote:
> On 3/27/07, David Miller <[EMAIL PROTECTED]> wrote:
>
>> From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
>> Date: Tue, 27 Mar 2007 16:41:48 -0300
>>
>> > +static inline void skb_move_linear_data(const stru
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 28 Mar 2007 07:30:32 +1000
> On Tue, Mar 27, 2007 at 02:57:18PM +0100, David Woodhouse wrote:
> >
> > > [IPV6]: Do not set IF_READY if device is down
> > >
> > > Now that we add the IPv6 device at registration time we don't need
> > >
On Tue, Mar 27, 2007 at 02:57:18PM +0100, David Woodhouse wrote:
>
> > [IPV6]: Do not set IF_READY if device is down
> >
> > Now that we add the IPv6 device at registration time we don't need
> > to set IF_READY in ipv6_add_dev anymore because we will always get
> > a NETDEV_UP
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 18:22:14 -0300
> I don't want to intend anything with this, was just a brain fart, a
> failed attempt to convince me that this was needed, I apologise for
> letting this sleep thru, will remove and resubmit, ok?
Perfect.
Arnaldo Carvalho de Melo wrote:
> On 3/27/07, David Miller <[EMAIL PROTECTED]> wrote:
>
>> From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
>> Date: Tue, 27 Mar 2007 16:41:48 -0300
>>
>> > +static inline void skb_move_linear_data(const struct sk_buff *skb,
>> > +
On 3/27/07, Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> wrote:
On 3/27/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
> Date: Tue, 27 Mar 2007 16:41:48 -0300
>
> > +static inline void skb_move_linear_data(const struct sk_buff *skb,
> > +
On 3/27/07, David Miller <[EMAIL PROTECTED]> wrote:
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 16:41:48 -0300
> +static inline void skb_move_linear_data(const struct sk_buff *skb,
> + const int from_offset,
> +
On Tue, Mar 27, 2007 at 10:51:53PM +0200, Patrick McHardy wrote:
>
> Just wondering, how does Xen know whether a packet will be forwarded?
It's up to Linux to handle it correctly.
> The input path doesn't seem to deal with CHECKSUM_PARTIAL correctly,
> ip_defrag for example resets them to CHECKS
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 15:47:04 +0200
> As IPPROTO_TCP is 6, it makes sense to make sure inet_protos[] array is
> properly cache line aligned to avoid false sharing on SMP.
>
> c0680540 b peer_total
> c0680544 b inet_peer_unused_head
> c0680560 B inet_proto
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 16:41:48 -0300
> +static inline void skb_move_linear_data(const struct sk_buff *skb,
> + const int from_offset,
> + const int to_offset,
> +
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 18:28:48 +0200
> Fix fallout from my qdisc endless loop fixes. I've checked
> all qdiscs, these two should be the only broken ones.
> The patch applies to current -git and the last -stable.
Applied, thanks Patrick.
-
To unsubscribe
David Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 12:13:43 +0200
Hi David
Please find this patch against net-2.6.22
Thank you
[PATCH] NET : inet_ehash_secret should be __read_mostly and set only once
There is a very tiny probability that build_ehash_secret
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 15:25:13 +0200
>
> tcp_memory_pressure and tcp_socket currently share a cache line with
> tcp_memory_allocated, tcp_sockets_allocated.
> (Very hot cache line)
> It makes sense to declare these variables as __read_mostly, to avoid fals
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 15:38:45 +0200
> The results of FIB rules lookups are cached in the routing cache
> except for IPv6 as no such cache exists. So far, it was the
> responsibility of the user to flush the cache after modifying any
> rules. This lead to man
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 27 Mar 2007 12:13:43 +0200
> Hi David
>
> Please find this patch against net-2.6.22
>
> Thank you
>
> [PATCH] NET : inet_ehash_secret should be __read_mostly and set only once
>
> There is a very tiny probability that build_ehash_secret() is ca
Herbert Xu wrote:
> Hi Dave:
>
> [NET]: Allow forwarding of ip_summed except CHECKSUM_COMPLETE
>
> Right now Xen has a horrible hack that lets it forward packets with
> partial checksums. One of the reasons that CHECKSUM_PARTIAL and
> CHECKSUM_COMPLETE were added is so that we can get rid of thi
Jay Cliburn <[EMAIL PROTECTED]> writes:
> We're trying to track down the source of a problem that occurs whenever
> the atl1 network driver is activated on a 32-bit 2.6.21-rc4 kernel. We
> need help from netdev.
>
> We can load the driver just fine, but whenever we activate the
> network, we see
Correctly detect when TSO should be used on transmit by looking at the
skb->gso_size rather than seeing if the frame was larger than our MTU.
The old method causes problems when a host with a large (jumbo) MTU is
sending to a host with a small (standard) MTU.
Signed-off-by: Brice Goglin <[EMAIL PR
Correctly detect when TSO should be used on transmit by looking at the
skb->gso_size rather than seeing if the frame was larger than our MTU.
The old method causes problems when a host with a large (jumbo) MTU is
sending to a host with a small (standard) MTU.
---
drivers/net/myri10ge/myri10ge.c |
Hi Jeff,
Here's a last minute fix for myri10ge in 2.6.21. Please apply.
Thanks,
Brice
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Document new IP_PMTUDISC_PROBE value for IP_MTU_DISCOVERY. (Going into
2.6.22).
Thanks,
-John
diff -rU3 man-pages-2.43-a/man7/ip.7 man-pages-2.43-b/man7/ip.7
--- man-pages-2.43-a/man7/ip.7 2006-09-26 09:54:29.0 -0400
+++ man-pages-2.43-b/man7/ip.7 2007-03-27 15:46:18.0 -0400
Rick Jones wrote:
I have some 10gig nics and ethtool is reporting unknown for the speed.
Is there already a patch, or have I found an opportunity? FWIW, the
version five bits from sourceforge still report unknown - are they the
latest or are there later bits somewhere?
Nope, patches welcome.
For consistency with other skb data accessors, reducing the number of direct
accesses to skb->data.
Signed-off-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
---
drivers/bluetooth/bluecard_cs.c |6 +++---
drivers/bluetooth/bt3c_cs.c |6 +++---
drivers/bluetooth/btuart_cs.c |6
Hi David,
Reworked the patches to not use skb_copy_bits, but some new accessors,
namely skb_copy_from_linear_data{_offset}().
Please consider pulling from the usual place:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.22
Best Regards,
- Arnaldo
-
To unsubscribe from
I have some 10gig nics and ethtool is reporting unknown for the speed.
Is there already a patch, or have I found an opportunity? FWIW, the
version five bits from sourceforge still report unknown - are they the
latest or are there later bits somewhere?
thanks,
rick jones
-
To unsubscribe from
El Martes, 27 de Marzo de 2007, Jose Alberto Reguero escribió:
> El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
> > On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero
>
> ([EMAIL PROTECTED]) wrote:
> > > El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
> > > > On
Jesse Huang wrote:
Dear all:
Would someone tell me the current status of IP1000A Linux Driver?
Would it be putted into Linux Kernel or not?
I forgot what the status of this was? Didn't it need some cleanups?
Maybe Francois has a better memory than me.
Jeff
-
To unsubscribe from t
Fix fallout from my qdisc endless loop fixes. I've checked
all qdiscs, these two should be the only broken ones.
The patch applies to current -git and the last -stable.
[NET_SCHED]: sch_htb/sch_hfsc: fix oops in qlen_notify
During both HTB and HFSC class deletion the class is removed from the
cla
Denys wrote:
> Hi again
>
> Looks like everything is fine, i will deploy at few NAS today night and will
> see if there any issues.
Thanks for testing.
> Both oops what i gave, is it related to this bug?
Yes, they were both because of the same bug.
-
To unsubscribe from this list: send the li
Hi again
Looks like everything is fine, i will deploy at few NAS today night and will
see if there any issues. Both oops what i gave, is it related to this bug?
No need to dig anything else?
On Tue, 27 Mar 2007 17:10:36 +0200, Patrick McHardy wrote
> Denys wrote:
> > Mar 26 21:20:04 ROUTER-75 [
On Tue, Mar 27, 2007 at 05:27:42PM +0200, Simba ([EMAIL PROTECTED]) wrote:
> I am currently working on a new l2/l3 protocol (just for
> research reasons) and i would like to make a test implementation
> in the linux kernel.
>
> For this i need to modify the ethernet header and replace it
> with my
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
> On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero
([EMAIL PROTECTED]) wrote:
> > El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
> > > On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero
> >
> > ([EMAI
Greetings,
I am new to this list. I have a very special question.
I am currently working on a new l2/l3 protocol (just for
research reasons) and i would like to make a test implementation
in the linux kernel.
For this i need to modify the ethernet header and replace it
with my header. The paylo
Yes, correct, i am able to reproduce problem, i was scared i will be not able.
Just when i am killing pppd on "server" side, flooding interface, it's
happens.
I will try patch in next 30 minutes max.
I have also bug, related to mirred to ifb0 and ethernet checksum offloading,
but maybe it is fi
Denys wrote:
> Mar 26 21:20:04 ROUTER-75 [ 551.481081] BUG: unable to handle kernel NULL
> pointer dereference
> Mar 26 21:20:04 ROUTER-75 at virtual address 0074
> Mar 26 21:20:04 ROUTER-75 [ 551.481187] printing eip:
> Mar 26 21:20:04 ROUTER-75 [ 551.481236] f8a11df1
> Mar 26 21:20:04 RO
On Tue, Mar 27, 2007 at 04:29:11PM +0200, Jose Alberto Reguero ([EMAIL
PROTECTED]) wrote:
> El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
> > On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero
> ([EMAIL PROTECTED]) wrote:
> > > I had two python programs, server.py and cli
James Chapman wrote:
>>> Wouldn't that effectively duplicate the code in udp_sendmsg()? If I
>>> don't use a socket, I'd also have to build an IP header and feed the
>>> frame into the IP stack for outbound routing. It doesn't feel like the
>>> right thing to do.
>>
>>
>> Thats what other tunnel dr
El Martes, 27 de Marzo de 2007, Evgeniy Polyakov escribió:
> On Mon, Mar 26, 2007 at 11:03:21PM +0200, Jose Alberto Reguero
([EMAIL PROTECTED]) wrote:
> > I had two python programs, server.py and client.py(attached)
> >
> > With server.py in a kernel 2.6.21-rc5 x86_64 and client.py in the same
>
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2007-03-27 22:45
> When looking up route for destination with rules with
> source address restrictions, we may need to find a source
> address for the traffic if not given.
Out of curiosity, what sort of rules would have this flag set?
The majo
On Thu, 2007-03-08 at 03:59 +, Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c7ababbdc647e67e953d153ddf62cbdc9fe3297e
> Commit: c7ababbdc647e67e953d153ddf62cbdc9fe3297e
> Parent: 16bec31db751030171b31d77
When looking up route for destination with rules with
source address restrictions, we may need to find a source
address for the traffic if not given.
Based on patch from Noriaki TAKAMIYA <[EMAIL PROTECTED]>.
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
---
include/linux/fib_rules.h |
As IPPROTO_TCP is 6, it makes sense to make sure inet_protos[] array is
properly cache line aligned to avoid false sharing on SMP.
c0680540 b peer_total
c0680544 b inet_peer_unused_head
c0680560 B inet_protos
On i386 this example, we can see that inet_protos[IPPROTO_TCP] shares a
potentially ho
The results of FIB rules lookups are cached in the routing cache
except for IPv6 as no such cache exists. So far, it was the
responsibility of the user to flush the cache after modifying any
rules. This lead to many false bug reports due to misunderstanding
of this concept.
This patch automaticall
On Tue, Mar 27, 2007 at 04:23:49PM +0200, Andi Kleen ([EMAIL PROTECTED]) wrote:
> > 2) An extra list insert/delete to give list of all sockets
>
> That is currently limited by readlock on the hash buckets. I suspect
> any change to a trie with less atomic operations will make it faster.
The best
* Muli Ben-Yehuda <[EMAIL PROTECTED]> 2007-03-27 15:30
> That looks like a bug - shouldn't we flush the cache first, then do
> the rules_ops_put()?
Good catch, it's unlikely to happen but it is a bug.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [
1 - 100 of 118 matches
Mail list logo
