From: Michael Tokarev <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2006 10:39:19 +0400
> Patrick McHardy wrote:
> > These are the updated patches (against net-2.6.19) to increase the number
> > of possible routing tables to 2^32. They basically consist of four parts:
> >
> > - Use u32 for routing table
From: Krzysztof Oledzki <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 20:18:23 +0200 (CEST)
> OK, this patch really solves the bug from my report. Are there any chances
> for similar fix in the net-2.6.19.git?
I'm still thinking about this patch and what various people have
explained about the situ
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 14:36:02 +0200
> * David Miller <[EMAIL PROTECTED]> 2006-08-02 15:18
> > From: Stephen Hemminger <[EMAIL PROTECTED]>
> > Date: Wed, 2 Aug 2006 12:56:36 -0700
> >
> > > The HTB scheduler code is a mess, this patch set does some basic
> >
Patrick McHardy wrote:
> These are the updated patches (against net-2.6.19) to increase the number
> of possible routing tables to 2^32. They basically consist of four parts:
>
> - Use u32 for routing table IDs everywhere inside the kernel
Just out of curiocity: why current limit of 2^31 isn't su
From: Evgeniy Polyakov <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2006 10:33:53 +0400
> That requires mmap hacks to substitute pages in run-time without user
> notifications. I do not expect it is a good solution, since on x86 it
> requires full TLB flush (at least when I did it there were no exported
On Thu, Aug 10, 2006 at 11:25:05PM -0700, Ulrich Drepper ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov wrote:
> > The main disadvantage is that all memory is allocated on the start even
> > if it will not be used later. I think dynamic grow is appropriate
> > solution, since user will have that me
Evgeniy Polyakov wrote:
> The main disadvantage is that all memory is allocated on the start even
> if it will not be used later. I think dynamic grow is appropriate
> solution, since user will have that memory used anyway, since kevents
> are allocated,
If you _allocate_ memory at startup you're
On Thu, Aug 10, 2006 at 11:23:40PM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> On Fri, 11 Aug 2006 10:15:35 +0400
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Aug 10, 2006 at 05:56:39PM -0700, Andrew Morton ([EMAIL PROTECTED])
> > wrote:
> > > > Per kevent fd.
> > > > I have
On Fri, 11 Aug 2006 10:15:35 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 10, 2006 at 05:56:39PM -0700, Andrew Morton ([EMAIL PROTECTED])
> wrote:
> > > Per kevent fd.
> > > I have some ideas about better mmap ring implementation, which would
> > > dinamically grow it's buffer
On Thu, Aug 10, 2006 at 05:56:39PM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> > Per kevent fd.
> > I have some ideas about better mmap ring implementation, which would
> > dinamically grow it's buffer when events are added and reuse the same
> > place for next events, but there are some nit
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 21:30:04 +0200 (MEST)
> [DECNET]: Increase number of possible routing tables to 2^32
>
> Increase the number of possible routing tables to 2^32 by replacing the
> fixed sized array of pointers by a hash table and replacing iteration
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 21:30:01 +0200 (MEST)
> [IPV4]: Increase number of possible routing tables to 2^32
>
> Increase the number of possible routing tables to 2^32 by replacing the
> fixed sized array of pointers by a hash table and replacing iterations
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 21:30:06 +0200 (MEST)
> [NET]: Increate RT_TABLE_MAX to 2^32
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
2^32-1 :-)
Applied, thanks Patrick.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the bod
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 21:30:00 +0200 (MEST)
> [NET]: Introduce RTA_TABLE/FRA_TABLE attributes
>
> Introduce RTA_TABLE route attribute and FRA_TABLE routing rule attribute
> to hold 32 bit routing table IDs. Usespace compatibility is provided by
> continu
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 21:30:03 +0200 (MEST)
> [IPV6]: Increase number of possible routing tables to 2^32
>
> Increase number of possible routing tables to 2^32 by replacing iterations
> over all possible table IDs by hash table walking.
>
> Signed-off-b
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 11:34:03 -0700
> Rather than opencoding the mask, it looks better to use ALIGN()
> macro from kernel.h.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, thanks Stephen.
-
To unsubscribe from this list: send the l
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 21:29:59 +0200 (MEST)
> [NET]: Use u32 for routing table IDs
>
> Use u32 for routing table IDs in net/ipv4 and net/decnet in preparation of
> support for a larger number of routing tables. net/ipv6 already uses u32
> everywhere and
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 21:23:23 +0200
> Dave, please revert the whole patchset.
Done and I've rebased the net-2.6.19 tree as well at:
kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.19.git
Thomas, there was a conflict which I did expect since I a
From: [EMAIL PROTECTED]
Date: Thu, 10 Aug 2006 22:15:26 -0400
> On Sun, 06 Aug 2006 03:08:09 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/
>
> After applying the patch that Patrick McHardy pointed me at, it lived
> longer. H
Thomas Graf wrote:
skb->dev is not guaranteed to still point to the "allocating" device
once the skb is freed again so reserve/unreserve isn't symmetric.
You'd need skb->alloc_dev or something.
There's another consequence of this property of the network
stack.
Every network interface must be
On Sun, 06 Aug 2006 03:08:09 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/
After applying the patch that Patrick McHardy pointed me at, it lived
longer. However, I'm now seeing problems at system shutdown (or anytime
you try to
On Wed, Aug 09, 2006 at 09:04:38PM -0700, David Miller wrote:
> From: Dave Jones <[EMAIL PROTECTED]>
> Date: Wed, 9 Aug 2006 22:21:16 -0400
>
> > config.h is automatically included by kbuild these days.
> >
> > Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
>
> Applied to net-2.6.19, than
On Thu, 10 Aug 2006 12:22:35 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 10, 2006 at 01:02:54AM -0700, Andrew Morton ([EMAIL PROTECTED])
> wrote:
> > > > Afaict this mmap function gives a user a free way of getting pinned
> > > > memory.
> > > > What is the upper bound on th
On Thu, August 10, 2006 18:50, Peter Zijlstra said:
> You are right if the reserve wasn't device bound - which I will abandon
> because you are right that with multi-path routing, bridge device and
> other advanced goodies this scheme is broken in that there is no
> unambiguous mapping from sockets
> > > +static inline u32 map_swqe_size(u8 swqe_enc_size)
> > > +{
> > > + return 128 << swqe_enc_size;
> > > +} ^
> > > + |
> > > +static inline u32|map_rwqe_size(u8 rwqe_enc_size)
> > > +{ |
> > > + return 128 << rwqe_enc_size;
>
On Thu, Aug 10, 2006 at 01:28:27PM -0700, Stephen Hemminger wrote:
> >
> >On Wed, Aug 09, 2006 at 11:31:42AM -0700, Stephen Hemminger wrote:
> >> Replace the gross custom locking done in socket code for net_family[]
> >> with simple RCU usage. Some reordering necessary to avoid sleep
> >> issues wi
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 3 Aug 2006 10:05:58 -0700
> Fix from [EMAIL PROTECTED], STP packets are incorrectly received on all
> LLC datagram sockets, whichever interface they are bound to.
> The llc_sap datagram receive logic sends packets with a unicast destination
> > +static inline u32 map_swqe_size(u8 swqe_enc_size)
> > +{
> > + return 128 << swqe_enc_size;
> > +}^
> > + |
> > +static inline u32|map_rwqe_size(u8 rwqe_enc_size)
> > +{|
> > + return 128 << rwqe_enc_size;
^
> > +}
[IPROUTE]: Fix struct alignment with cris architecture
gcc for the cris arch does not pad structures to the next multiple of 4
bytes, as the i386 gcc does.
This causes errors like this when displaying xfrm policies:
# ip x p
!!!Deficit 3, rta_len=300
src 192.168.251.32/29 dst 192.168.251.32/29
[BNX2]: Convert to netdev_alloc_skb()
Convert dev_alloc_skb() to netdev_alloc_skb() and increase default
rx ring size to 255. The old ring size of 100 was too small.
Update version to 1.4.44.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
in
[BNX2]: Fix tx race condition.
Fix a subtle race condition between bnx2_start_xmit() and bnx2_tx_int()
similar to the one in tg3 discovered by Herbert Xu:
CPU0CPU1
bnx2_start_xmit()
if (tx_ring_full) {
tx_lock
Please add comments to make the code more readable, especially at the
start of functions/structures to describe what they do. A large readme
at the start of ehea_main.c which gave an overview of the driver design
would be really useful.
Comments inline below...
> +static void *ipz_qpageit_get_i
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 16:52:16 -0700
> Dave, here is my version...
> Don't leak memory on interrupted read. And only allocate
> as much memory as needed.
>
> Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
I think I'm going to go with James's saf
Dave, here is my version...
Don't leak memory on interrupted read. And only allocate
as much memory as needed.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- linux-2.6.orig/net/ipv4/tcp_probe.c 2006-08-10 16:32:36.0 -0700
+++ linux-2.6/net/ipv4/tcp_probe.c 2006-08-10 16:45
From: "Jesper Juhl" <[EMAIL PROTECTED]>
Date: Fri, 11 Aug 2006 00:18:44 +0200
> Hmm, perhaps I'm going blind, but I don't see it.
I definitely screwed that changeset up somehow. Thanks for catching
this.
Somehow James's fix got clobbered into just my subsequent warning fix,
like this:
commit 1
Stephen Hemminger wrote:
> Applied thanks. Let me know when your done, it has been too long
> since a real release of iproute2. I'll roll one as soon as the flow subsides.
I only have one more patchset I would like to submit soon, the time
cleanups. But they are only meant to make auditing for in
On Fri, 11 Aug 2006 00:14:47 +0200 (MEST)
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> These patches add support for a larger number of routing tables to iproute
> and are needed for the patches doing the same for the kernel I just sent.
> They apply on top of the "[IPROUTE]: Support IPv6 routing
On 05/08/06, David Miller <[EMAIL PROTECTED]> wrote:
From: "Jesper Juhl" <[EMAIL PROTECTED]>
Date: Sat, 5 Aug 2006 01:30:49 +0200
> On 31/07/06, David Miller <[EMAIL PROTECTED]> wrote:
> > From: "Jesper Juhl" <[EMAIL PROTECTED]>
> > Date: Sun, 30 Jul 2006 23:51:20 +0200
> >
> > > Looks ok to me.
These patches add support for a larger number of routing tables to iproute
and are needed for the patches doing the same for the kernel I just sent.
They apply on top of the "[IPROUTE]: Support IPv6 routing table filter" patch.
Please apply, thanks.
include/linux/rtnetlink.h |4 -
include/r
[IPROUTE]: Use hash for routing table name cache
Use a hash for routing table name cache instead of the fixed size array.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit ccd621fbb5faa91a98479e9492baee525c6f10c0
tree e4e1416406b5ed252b3b1a91efc3d8caadbf1bd0
parent 00d896184c5f873726
[IPROUTE]: Add support for larger number of routing tables
Support support for 2^32 routing tables by using the new RTA_TABLE
attribute for specifying tables > 255 and intepreting it if it is
sent by the kernel.
When tables > 255 are used on a kernel not supporting it an error will
occur because
[IPROUTE]: Preparation for 32 bit table IDs
The route table filter uses an integer for the table number and the value
-1 to represent cloned routes. For 32 bit table IDs it needs to become an
unsigned, so this won't work anymore. Introduce a new filter flag "cloned"
and use instead of filter.tb =
On Thu, 10 Aug 2006 22:02:03 +0200, Patrick McHardy said:
> [EMAIL PROTECTED] wrote:
> > On Sun, 06 Aug 2006 03:08:09 PDT, Andrew Morton said:
> >
> >>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/
> >
> >
> > Building a kernel with IPV6_MULTIPLE_TABLES
Hello
* Alexey Kuznetsov <[EMAIL PROTECTED]> 2006-08-11 00:32
> Nothing! NLM_F_ECHO _is_ listening for notifications without subscription
> to multicast groups and need to figure out what messages are yours.
> But beyond this NLM_F_ECHO is totally subset of this.
> Which still makes much more sens
[EMAIL PROTECTED] wrote:
> On Sun, 06 Aug 2006 03:08:09 PDT, Andrew Morton said:
>
>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/
>
>
> Building a kernel with IPV6_MULTIPLE_TABLES=y breaks my IPv6 connectivity
> quite badly. It basically totally refus
Support IPv6 routing table filter in presence of multiple tables,
f.e. "ip -6 route list table 123". Compatibility is preserved for
kernels not supporting multiple IPv6 tables.
[IPROUTE]: Support IPv6 routing table filter
The current behaviour for IPv6 routing table filters is to derive the
tabl
>
>On Wed, Aug 09, 2006 at 11:31:42AM -0700, Stephen Hemminger wrote:
>> Replace the gross custom locking done in socket code for net_family[]
>> with simple RCU usage. Some reordering necessary to avoid sleep
>> issues with sock_alloc.
>
>Definitely a good use of RCU from a read-intensive standpoi
On Tue, Aug 08, 2006 at 04:39:15PM -0700, David Miller ([EMAIL PROTECTED])
wrote:
>
> I'm beginning to think that where we store the
> skb_shared_info() is a weakness of the SKB design.
Food for thoughts - unix sockets can use PAGE_SIZEd chunks of memory
(and they do it almost always), which are
On Thu, 10 Aug 2006 22:42:58 +0200
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Support IPv6 routing table filter in presence of multiple tables,
> f.e. "ip -6 route list table 123". Compatibility is preserved for
> kernels not supporting multiple IPv6 tables.
>
>
applied thanks
--
-
To unsubs
Hello!
> What's wrong with listening to the notification for that purpose?
Nothing! NLM_F_ECHO _is_ listening for notifications without subscription
to multicast groups and need to figure out what messages are yours.
But beyond this NLM_F_ECHO is totally subset of this.
Which still makes much mor
[IPV6]: Increase number of possible routing tables to 2^32
Increase number of possible routing tables to 2^32 by replacing iterations
over all possible table IDs by hash table walking.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit cad398a8f3ef363abba9e6450dded94a022c96fa
tree 4fe
[DECNET]: Increase number of possible routing tables to 2^32
Increase the number of possible routing tables to 2^32 by replacing the
fixed sized array of pointers by a hash table and replacing iterations
over all possible table IDs by hash table walking.
Signed-off-by: Patrick McHardy <[EMAIL PRO
[NET]: Increate RT_TABLE_MAX to 2^32
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit f20cbb83204cd7e2ffa9cf4e8ee8b6353628d5d3
tree 8f0eaa4219506715449e7118037040f396875c99
parent 9203e4cdab89d96c474c6a903ef9a1f47c7eee07
author Patrick McHardy <[EMAIL PROTECTED]> Thu, 10 Aug 2006 20:
These are the updated patches (against net-2.6.19) to increase the number
of possible routing tables to 2^32. They basically consist of four parts:
- Use u32 for routing table IDs everywhere inside the kernel
- Introduce new netlink attributes to carry extended table IDs and add
compatibility f
[NET]: Introduce RTA_TABLE/FRA_TABLE attributes
Introduce RTA_TABLE route attribute and FRA_TABLE routing rule attribute
to hold 32 bit routing table IDs. Usespace compatibility is provided by
continuing to accept and send the rtm_table field, but because of its
limited size it can only carry the
[NET]: Use u32 for routing table IDs
Use u32 for routing table IDs in net/ipv4 and net/decnet in preparation of
support for a larger number of routing tables. net/ipv6 already uses u32
everywhere and needs no further changes. No functional changes are made by
this patch.
Signed-off-by: Patrick Mc
[IPV4]: Increase number of possible routing tables to 2^32
Increase the number of possible routing tables to 2^32 by replacing the
fixed sized array of pointers by a hash table and replacing iterations
over all possible table IDs by hash table walking.
Signed-off-by: Patrick McHardy <[EMAIL PROTE
* Patrick McHardy <[EMAIL PROTECTED]> 2006-08-10 21:08
> The error code (-ENOMEM) gives it a pretty good idea what went
> wrong. Its true that it doesn't know which group was affected
> (that could be fixed), but at least it knows that something
> went wrong and it needs to resync. If that fails du
Thomas Graf wrote:
> * Patrick McHardy <[EMAIL PROTECTED]> 2006-08-10 20:09
>
>>I disagree with this patch, how else are applications supposed
>>to know when they missed an update and are not in sync anymore?
>>I actually have a half-finished patch to add this in some spots
>>where its missing (an
* Patrick McHardy <[EMAIL PROTECTED]> 2006-08-10 20:09
> Thomas Graf wrote:
> > Setting a socket error on all sockets subscribed to a group
> > if an event notificiation of said group fails due to memory
> > pressure only confuses applications and is of no use.
> >
> > This patch removes it all t
* Alexey Kuznetsov <[EMAIL PROTECTED]> 2006-08-10 19:51
> > This patch handles NLM_F_ECHO in netlink_rcv_skb() to
> > handle it in a central point. Most subsystems currently
> > interpret NLM_F_ECHO as to just unicast events to the
> > originator of the change while the real meaning of the
> > flag
On Thu, 10 Aug 2006 05:36:13 + (UTC) Alexey Toptygin wrote:
> On Wed, 9 Aug 2006, David Miller wrote:
>
> > From: Stephen Hemminger <[EMAIL PROTECTED]>
> > Date: Wed, 09 Aug 2006 11:31:38 -0700
> >
> >> These patches cleanup the net socket family interface and
> >> convert it to RCU. This is
On Wed, Aug 09, 2006 at 11:31:42AM -0700, Stephen Hemminger wrote:
> Replace the gross custom locking done in socket code for net_family[]
> with simple RCU usage. Some reordering necessary to avoid sleep
> issues with sock_alloc.
Definitely a good use of RCU from a read-intensive standpoint -- do
Rather than opencoding the mask, it looks better to use ALIGN()
macro from kernel.h.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- net-2.6.19.orig/include/net/neighbour.h
+++ net-2.6.19/include/net/neighbour.h
@@ -101,7 +101,7 @@ struct neighbour
__u8dead;
On Thu, 3 Aug 2006, Krzysztof Oledzki wrote:
On Wed, 2 Aug 2006, David Miller wrote:
Finally, I'm still a little stumped about why this change is necessary
still, to be honest.
If I understand it correctly this patch fixes the "[PATCH] bonding: suppress
duplicate packets" patch:
http:
Thomas Graf wrote:
> Setting a socket error on all sockets subscribed to a group
> if an event notificiation of said group fails due to memory
> pressure only confuses applications and is of no use.
>
> This patch removes it all together.
I disagree with this patch, how else are applications sup
Michal,
This looks correct, but I think a better way to do it is:
in_dev = inetdev_by_index(...)
(void) ip_mc_leave_src()
if (in_dev) {
ip_mc_dec_group()
in_dev_put()
}
That way, sflist internal details aren't visible
On Sun, 06 Aug 2006 03:08:09 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/
Building a kernel with IPV6_MULTIPLE_TABLES=y breaks my IPv6 connectivity
quite badly. It basically totally refuses to answer an IPv6 Neighbor Solicit
p
On Wed, 09 Aug 2006 20:47:45 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Wed, 09 Aug 2006 11:31:39 -0700
>
> > If socket create call races with module unload, it correctly
> > fails the socket call but doesn't return an error. This rac
> > > Tricky, but since you are using own allocator here, you could change it to
> > > be not so aggressive - i.e. do not round size to number of pages.
> >
> > I'm not sure I follow you, I'm explicitly using
> > alloc_pages()/free_page(), if
> > I were to go smart here, I'd loose the whole reaso
I found this patch for 2.4 that allows the host running ipvs to act
as it's own client via loopback connection. Does anyone have a similar
patch for 2.6?
--- ip_vs_core.c.orig 2003-11-28 19:26:21.0 +0100
+++ ip_vs_core.c.list 2004-07-02 11:13:51.0 +0200
@@ -1036,7 +1036,7 @@
On Thu, Aug 10, 2006 at 04:46:31PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> On Thu, 2006-08-10 at 18:02 +0400, Evgeniy Polyakov wrote:
> > On Thu, Aug 10, 2006 at 03:32:49PM +0200, Peter Zijlstra ([EMAIL
> > PROTECTED]) wrote:
> > > Hi,
> >
> > Hello, Peter.
> >
> > > So I try again,
Took some time but this time the inlined patch should be OK.
Hi all!
It seems to me that there is a leak of struct ip_sf_socklist in the
ip_mc_drop_socket function (in net/ipv4/igmp.c) which is called on socket
close.
This patch corrects it:
diff -Naur linux-2.6.17.8.orig/net/ipv4/igmp.c linux
Hello!
> This patch handles NLM_F_ECHO in netlink_rcv_skb() to
> handle it in a central point. Most subsystems currently
> interpret NLM_F_ECHO as to just unicast events to the
> originator of the change while the real meaning of the
> flag is to echo the request.
Do not you think it is useless t
Hi,
thanks for your comments!
We'll post a modified patch very soon.
Jan-Bernd
Alexey Dobriyan wrote:
On Wed, Aug 09, 2006 at 10:38:20AM +0200, Jan-Bernd Themann wrote:
--- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_main.c
+++ kernel/drivers/net/ehea/ehea_main.c
+static inline u64 get_sw
Arnd Bergmann wrote:
On Wednesday 09 August 2006 10:38, Jan-Bernd Themann wrote:
--- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_hcall.h 1969-12-31
16:00:00.0 -0800
+++ kernel/drivers/net/ehea/ehea_hcall.h2006-08-08 23:59:38.111462960
-0700
@@ -0,0 +1,52 @@
+
+/**
+ * This f
Hi Michael,
thanks for your very helpful comments so far, we'll provide a patch with these
and other fixes
very soon.
See comments below.
Jan-Bernd
Michael Ellerman wrote:
> Hi Jan-Bernd,
>
> Comments below the code they refer to.
>
> On Wed, 2006-08-09 at 10:38 +0200, Jan-Bernd Themann wrote
Sam Ravnborg wrote:
On Wed, Aug 09, 2006 at 10:40:20AM +0200, Jan-Bernd Themann wrote:
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
drivers/net/ehea/Makefile |7 +++
1 file changed, 7 insertions(+)
--- linux-2.6.18-rc4-orig/drivers/net/ehea/Makefile 1969-12-31
16:00:00.
On Thu, 2006-08-10 at 18:02 +0400, Evgeniy Polyakov wrote:
> On Thu, Aug 10, 2006 at 03:32:49PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
> wrote:
> > Hi,
>
> Hello, Peter.
>
> > So I try again, please tell me if I'm still on crack and should go detox.
> > However if you do so, I kindly request
On Thu, Aug 10, 2006 at 03:32:49PM +0200, Peter Zijlstra ([EMAIL PROTECTED])
wrote:
> Hi,
Hello, Peter.
> So I try again, please tell me if I'm still on crack and should go detox.
> However if you do so, I kindly request some words on the how and why of it.
I think you should talk with doctor i
Hi,
So I try again, please tell me if I'm still on crack and should go detox.
However if you do so, I kindly request some words on the how and why of it.
so I try to map to net_device in several fashions:
1) netdev_alloc_skb()
- has an argument with the actual incoming device
2) free_skb_page
On Mon, Aug 07, 2006 at 11:55:14AM +1000, Philip Craig wrote:
> > I have one machine at home that appears to be on my employer's network
> > via such a tunnel. I don't use bridging, because I don't need any other
> > machine at home to access this tunnel. I do want bridging, and not proxy
> > AR
Jay Vosburgh wrote:
I haven't studied the effects of having large amounts of
multicast traffic coming in under this situation.
However, I would suspect that the MAC filters found on
sufficiently modern network adapters would drop the incoming multicast
traffic on the backup slave
* David Miller <[EMAIL PROTECTED]> 2006-08-02 15:18
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Wed, 2 Aug 2006 12:56:36 -0700
>
> > The HTB scheduler code is a mess, this patch set does some basic
> > house cleaning. The first four should cause no code change, but the
> > last two need
Stephen Hemminger wrote:
On the 88E805X chipsets (used in laptops), the PHY was not getting powered
out of shutdown properly. The variable reg1 was getting reused incorrectly.
This is probably the cause of the bug.
http://bugzilla.kernel.org/show_bug.cgi?id=6471
Signed-off-by: Stephen He
Grant Grundler wrote:
On Wed, Aug 09, 2006 at 01:33:18AM -0400, Jeff Garzik wrote:
2) nobody (but parisc folks?) knows what CBMA and CBIO mean. Just use
"MMIO" and "PIO"
"CBIO" is what's in the public documentation. I just want to make it
easy for anyone who bothers to read the documentation
On Thu, Aug 10, 2006 at 04:16:38PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> With this patchset rate of requests per second has achieved 2500 req/sec
> while with epoll/kqueue and similar techniques it is about 1600-1800
> requests per second on my test hardware and trivial web server.
This patch includes core kevent files:
- userspace controlling
- kernelspace interfaces
- initialization
- notification state machines
- timer and poll/select notifications
With this patchset rate of requests per second has achieved 2500 req/sec
while with epoll/kqueue and similar techniques it is
From: David Miller <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 05:12:41 -0700 (PDT)
> From: Michal Ruzicka <[EMAIL PROTECTED]>
> Date: Thu, 10 Aug 2006 14:07:06 +0200
>
> > This patch corrects it:
>
> Correct or not this patch is corrupted by your email client, turning
> tabs into spaces among ot
Hello.
Generic event handling mechanism.
Changes from 'take6' patchset:
* a lot of comments!
* do not use list poisoning for detection of the fact, that entry is in the
list
* return number of ready kevents even if copy*user() fails
* strict check for number of kevents in syscall
* use ARRA
From: Michal Ruzicka <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 14:07:06 +0200
> This patch corrects it:
Correct or not this patch is corrupted by your email client, turning
tabs into spaces among other things. This makes your patch unusable.
Please configure your email client to not mangle the
Hi all!
It seems to me that there is a leak of struct ip_sf_socklist in the
ip_mc_drop_socket function (in net/ipv4/igmp.c) which is called on socket
close.
This patch corrects it:
diff -Naur linux-2.6.17.8.orig/net/ipv4/igmp.c
linux-2.6.17.8/net/ipv4/igmp.c
--- linux-2.6.17.8.orig/net/ipv4
hi all,
The transmit functions of ethernet drivers (dev->hard_start_xmit) are
protected to prevent multiple execution of transmits going in parallel. The
general scheme used by most of driver is :
1. Reset NETIF_F_LLTX flag in dev->features and then use kernel locking given
through HARD_TX_LOC
Hi Jeff:
I will use sundance.c in this tree to generate patch files.
Thanks for this information.
Jesse
- Original Message -
From: "Jeff Garzik" <[EMAIL PROTECTED]>
To: "Jesse Huang" <[EMAIL PROTECTED]>
Cc: "Francois Romieu" <[EMAIL PROTECTED]>;
; ; "Andrew Morton"
<[EMAIL PROTECTE
Jesse Huang wrote:
Dear All:
We had some patch need to submit. Would you tell me where to get current
sundance.c for myself to generate those patch files.
Sorry, I only got this link:
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=f13b2a195c708fe32d8c53d05988875a5
YOSHIFUJI Hideaki wrote:
> As a result of original lookup (with possible ambiguous outout interface),
> one interface for original output is selected.
> Which means, we have a route for the (original) destination through that
> interface.
>
> Redirects shall come from that interface.
> So, it is
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Thu, 10 Aug 2006 01:19:50 -0700
>
Just pull from net-2.6.19, Stephen's stuff is all merged in
there.
I'll fix the "* var" stuff, I hate that too :-)
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMA
Hello.
In article <[EMAIL PROTECTED]> (at Thu, 10 Aug 2006 00:37:14 +0300), Ville
Nuorvala <[EMAIL PROTECTED]> says:
> >> commit e0ad64d5b44179ea1296d737dec23279c72c9636
> >> Author: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
> >> Date: Wed Aug 9 17:08:33 2006 +0900
> >>
> >> [IPV6] NDISC: Allo
On Thu, Aug 10, 2006 at 01:02:54AM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> > > Afaict this mmap function gives a user a free way of getting pinned
> > > memory.
> > > What is the upper bound on the amount of memory which a user can thus
> > > obtain?
> >
> > it is limited by maximum q
On Wed, 09 Aug 2006 11:31:40 -0700
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> Make socket.c conform to current style:
> * run through Lindent
> * get rid of unneeded casts
> * split assignment and comparsion where possible
>
> -static ssize_t sock_aio_read(struct kiocb *i
1 - 100 of 104 matches
Mail list logo
