Yo!
Patrick McHardy wrote:
> OBATA Noboru wrote:
>> Make TCP_RTO_MAX a variable, and allow a user to change it via a
>> new sysctl entry /proc/sys/net/ipv4/tcp_rto_max. A user can
>> then guarantee TCP retransmission to be more controllable, say,
>> at least once per 10 seconds, by setting it to
On Sat, 23 Jun 2007 11:09:04 -0700
Geoff Levand <[EMAIL PROTECTED]> wrote:
> MOKUNO Masakazu wrote:
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -2920,6 +2920,12 @@ M: [EMAIL PROTECTED]
> > L: [EMAIL PROTECTED]
> > S: Maintained
> >
> > +PS3 NETWORK SUPPORT
> > +P: Masakazu Mokuno
> >
On Mon, 25 Jun 2007 19:15:39 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > (Who maintains this driver now?)
>
>
> It was abandonware from the beginning of its life. Stephen H and
> Francois R did a bunch of cleanups most recently.
>
> Jeff
Have a couple of loa
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Mon, 25 Jun 2007 16:23:02 -0700
> It looks like the one Patrick resent was the older version that requires
> a typecast. This is the function prototype currently in the kernel:
>
> +extern int rtattr_parse_nested_compat(struct rtattr *tb[]
On Mon, 25 Jun 2007 17:57:20 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
> Jay L. T. Cornwall wrote:
> > Chris Snook wrote:
> >
> >> What boards have we seen this on? It's quite possible this is:
> >
> > I can reproduce on an Asus P5K with a Core 2 Duo E6600.
> >
> > lspci identifies the cont
Jeff Garzik wrote:
Jay Cliburn wrote:
On Mon, 25 Jun 2007 17:57:20 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
Jay L. T. Cornwall wrote:
Chris Snook wrote:
What boards have we seen this on? It's quite possible this is:
I can reproduce on an Asus P5K with a Core 2 Duo E6600.
lspci identi
Andrew Morton wrote:
On Mon, 25 Jun 2007 19:14:05 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
The chelsio driver is assuming that pci_device_id.driver_data has been
initialised to the board index, but I am unable to locate anywhere where
that initialisation actually happe
On Mon, 25 Jun 2007 19:14:05 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > The chelsio driver is assuming that pci_device_id.driver_data has been
> > initialised to the board index, but I am unable to locate anywhere where
> > that initialisation actually happens.
>
> It
> From: Patrick McHardy <[EMAIL PROTECTED]>
> Date: Mon, 25 Jun 2007 23:08:09 +0200
>
> > David Miller wrote:
> > >
> > >> I've been using this patch and the IPROUTE2 patches Patrick has
> > >> proposed with no issues. Can someone else look at these patches
> > >> when they have time? I'd be i
Jay Cliburn wrote:
On Mon, 25 Jun 2007 17:57:20 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
Jay L. T. Cornwall wrote:
Chris Snook wrote:
What boards have we seen this on? It's quite possible this is:
I can reproduce on an Asus P5K with a Core 2 Duo E6600.
lspci identifies the controller
Andrew Morton wrote:
(Who maintains this driver now?)
It was abandonware from the beginning of its life. Stephen H and
Francois R did a bunch of cleanups most recently.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PRO
Andrew Morton wrote:
The chelsio driver is assuming that pci_device_id.driver_data has been
initialised to the board index, but I am unable to locate anywhere where
that initialisation actually happens.
It's hidden inside the CH_DEVICE() initializer-helper macro.
Jeff
-
To unsubscrib
On Sun, 24 Jun 2007 15:59:54 +0200
Ralf Baechle <[EMAIL PROTECTED]> wrote:
> Fixed by including :
>
> CC drivers/net/au1000_eth.o
> drivers/net/au1000_eth.c: In function 'au1000_probe':
> drivers/net/au1000_eth.c:661: warning: implicit declaration of function
> 'dma_alloc_noncoherent'
> d
On Thu, 21 Jun 2007 18:48:30 +0530
"pradeep singh" <[EMAIL PROTECTED]> wrote:
> diff --git a/drivers/net/chelsio/cxgb2.c b/drivers/net/chelsio/cxgb2.c
> index 231ce43..006c634 100644
> --- a/drivers/net/chelsio/cxgb2.c
> +++ b/drivers/net/chelsio/cxgb2.c
> @@ -1022,6 +1022,11 @@ static int __devin
Ian McDonald wrote:
On 6/26/07, OBATA Noboru <[EMAIL PROTECTED]> wrote:
From: OBATA Noboru <[EMAIL PROTECTED]>
Make TCP_RTO_MAX a variable, and allow a user to change it via a
new sysctl entry /proc/sys/net/ipv4/tcp_rto_max. A user can
then guarantee TCP retransmission to be more controllable
On Tue, 26 Jun 2007 10:18:46 +1200
"Ian McDonald" <[EMAIL PROTECTED]> wrote:
> On 6/26/07, OBATA Noboru <[EMAIL PROTECTED]> wrote:
> > From: OBATA Noboru <[EMAIL PROTECTED]>
> >
> > Make TCP_RTO_MAX a variable, and allow a user to change it via a
> > new sysctl entry /proc/sys/net/ipv4/tcp_rto_max
From: Divy Le Ray <[EMAIL PROTECTED]>
Use the right register to stop broadcast/multicast traffic.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/xgmac.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/cxgb3/xgmac.c b/drivers/net
On 6/26/07, OBATA Noboru <[EMAIL PROTECTED]> wrote:
From: OBATA Noboru <[EMAIL PROTECTED]>
Make TCP_RTO_MAX a variable, and allow a user to change it via a
new sysctl entry /proc/sys/net/ipv4/tcp_rto_max. A user can
then guarantee TCP retransmission to be more controllable, say,
at least once p
Chris Snook wrote:
> What boards have we seen this on? It's quite possible this is:
I can reproduce on an Asus P5K with a Core 2 Duo E6600.
lspci identifies the controller as:
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
Ethernet Adapter (rev b0)
dmesg notes the PCI-DM
> Thats not necessary. I just though you could add one exit point:
>
>
> ...
> out:
> skb->queue_mapping = q->mq ? band : 0;
> return q->queues[band];
> }
>
> But if that doesn't work don't bother ..
Unfortunately it won't, given how band might be used like this to select
the queue:
re
Waskiewicz Jr, Peter P wrote:
@@ -70,14 +72,28 @@ prio_classify(struct sk_buff *skb, struct Qdisc
*sch, int *qerr) #endif
if (TC_H_MAJ(band))
band = 0;
+ if (q->mq)
+skb->queue_mapping =
+
q->prio2b
Jay L. T. Cornwall wrote:
Chris Snook wrote:
What boards have we seen this on? It's quite possible this is:
I can reproduce on an Asus P5K with a Core 2 Duo E6600.
lspci identifies the controller as:
02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit
Ethernet Adapter (rev
> > @@ -70,14 +72,28 @@ prio_classify(struct sk_buff *skb, struct Qdisc
> > *sch, int *qerr) #endif
> > if (TC_H_MAJ(band))
> > band = 0;
> > + if (q->mq)
> > + skb->queue_mapping =
> > +
Luca Tettamanti wrote:
Il Mon, Jun 25, 2007 at 07:42:44AM -0500, Jay Cliburn ha scritto:
Jay L. T. Cornwall wrote:
Jay Cliburn wrote:
For reasons not yet clear to me, it appears the L1 driver has a bug or
the device itself has trouble with DMA in high memory. This patch,
drafted by Luca Tett
> -Original Message-
> From: David Miller [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 25, 2007 2:30 PM
> To: Waskiewicz Jr, Peter P
> Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: Re: [RTNETLINK]: Add nested compat attribute
>
> From: "Waskiewicz Jr, Pe
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Mon, 25 Jun 2007 14:33:12 -0700
> I'm putting them into the latest 2.6.23 tree right now - I'll have them
> tested and sent upstream later today.
Please repull as I just put Patrick's RTNETLINK patch in
"for real this time" :-)
-
To unsubsc
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 25 Jun 2007 23:08:09 +0200
> David Miller wrote:
> >
> >> I've been using this patch and the IPROUTE2 patches Patrick has proposed
> >> with no issues. Can someone else look at these patches when they have
> >> time? I'd be interested in seein
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Mon, 25 Jun 2007 14:01:31 -0700
> Awesome Dave!! Thank you very much. :)
Please get your next round of patches ready, Patrick and
I can review them and barring any serious issues we can
finally put this stuff in to net-2.6.23.
-
To unsubsc
Il Mon, Jun 25, 2007 at 07:42:44AM -0500, Jay Cliburn ha scritto:
> Jay L. T. Cornwall wrote:
> >Jay Cliburn wrote:
> >
> >>For reasons not yet clear to me, it appears the L1 driver has a bug or
> >>the device itself has trouble with DMA in high memory. This patch,
> >>drafted by Luca Tettamanti,
David Miller wrote:
I've been using this patch and the IPROUTE2 patches Patrick has proposed
with no issues. Can someone else look at these patches when they have
time? I'd be interested in seeing them make it into 2.6.23.
I've just put Patrick's patch into the net-2.6.23 tree.
Yo
> From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
> Date: Mon, 25 Jun 2007 10:14:37 -0700
>
> > > This patch adds a new attribute type that can be used to replace
> > > non-nested attributes that contain structures by nested ones in a
> > > compatible way.
> > >
> > > This can be used in cas
From: "Waskiewicz Jr, Peter P" <[EMAIL PROTECTED]>
Date: Mon, 25 Jun 2007 10:14:37 -0700
> > This patch adds a new attribute type that can be used to
> > replace non-nested attributes that contain structures by
> > nested ones in a compatible way.
> >
> > This can be used in cases like Peter's
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Sat, 23 Jun 2007 11:26:49 +0200
> [NETLINK]: attr: add nested compat attribute type
>
> Add a nested compat attribute type that can be used to convert
> attributes that contain a structure to nested attributes in a
> backwards compatible way.
>
> S
From: jamal <[EMAIL PROTECTED]>
Date: Mon, 25 Jun 2007 12:47:31 -0400
> On Fri, 2007-22-06 at 09:26 +0800, Zhu Yi wrote:
> > We don't have THL and THH in our driver. They are what you suggested.
> > The queue wakeup number is 1/4 of the ring size.
>
> So how did you pick 1/4? Experimentation? If
Arjan van de Ven wrote:
> Vlad Yasevich wrote:
>> Hm... This is another case of of two different sockets taking the same
>> lock...
>>
>> Arjan, did this every get fixed, or is the nested locking the right
>> solution
>> to this?
>>
>
> for this specific case it's ok and the nested solution is ri
Vlad Yasevich wrote:
Hm... This is another case of of two different sockets taking the same lock...
Arjan, did this every get fixed, or is the nested locking the right solution
to this?
for this specific case it's ok and the nested solution is right.
In the general case it's obviously not sa
Zach Brown wrote:
> I'm not sure that I've gotten either the sctp or lockdep details right,
> but with this patch I don't get lockdep yelling at me any more :)
>
> --
>
> sctp: lock_sock_nested in sctp_sock_migrate
>
> sctp_sock_migrate() grabs the socket lock on a newly allocated socket whi
On Tue, 26 Jun 2007 01:11:20 +0530
"Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 6/9/07, Jeff Layton <[EMAIL PROTECTED]> wrote:
> > On Sat, 09 Jun 2007 11:30:04 +1000
> > Herbert Xu <[EMAIL PROTECTED]> wrote:
> >
> > > Please cc networking patches to [EMAIL PROTECTED]
> > >
> > > Jeff L
Hi,
On 6/9/07, Jeff Layton <[EMAIL PROTECTED]> wrote:
On Sat, 09 Jun 2007 11:30:04 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Please cc networking patches to [EMAIL PROTECTED]
>
> Jeff Layton <[EMAIL PROTECTED]> wrote:
> >
> > The following patch is a first stab at removing this need. It mak
Kok, Auke wrote:
Patrick McHardy wrote:
@@ -2449,9 +2450,16 @@ e1000_set_multi(struct net_device *netdev)
rctl |= (E1000_RCTL_UPE | E1000_RCTL_MPE);
} else if (netdev->flags & IFF_ALLMULTI) {
rctl |= E1000_RCTL_MPE;
-rctl &= ~E1000_RCTL_UPE;
} else {
-
Patrick McHardy wrote:
[E1000]: Secondary unicast address support
Add support for configuring secondary unicast addresses. Unicast
addresses take precendece over multicast addresses when filling
the exact address filters to avoid going to promiscous mode.
When more unicast addresses are present
On Mon, 25 Jun 2007, Michal Piotrowski wrote:
>
> Memory management
>
> Subject: bug in i386 MTRR initialization
> References : http://lkml.org/lkml/2007/5/19/93
> Submitter : Andrea Righi <[EMAIL PROTECTED]>
> Status : patch available
This one wasn't a bug in the first place, it was
Evgeniy Polyakov wrote:
On Thu, Jun 21, 2007 at 02:00:07PM -0700, Rick Jones ([EMAIL PROTECTED]) wrote:
Simple test included test -> desktop and vice versa traffic with 128 and
4096 block size in netperf-2.4.3 setup.
Is that in conjunction with setting the test-specific -D to set
TCP_NODELAY,
> PJ Waskiewicz wrote:
> > + /* If we're multiqueue, make sure the number of incoming bands
> > +* matches the number of queues on the device we're
> associating with.
> > +*/
> > + if (tb[TCA_PRIO_MQ - 1])
> > + q->mq = *(unsigned char *)RTA_DATA(tb[TCA_PRIO_MQ - 1]);
> > +
Waskiewicz Jr, Peter P wrote:
And RTA_PUT_FLAG. Now that I think of it, does it even makes
sense to have a prio private flag for this instead of a qdisc
global one?
There currently aren't any other qdiscs that are natural fits for
multiqueue that I can see. I can see the benefit though
Ok I have tried it on a Pentium-M ( 32 Bit ,) with 512 MB RAM and Core
2 Duo with 1Gig RAM ( running SMP kernel , 2 CPUS) with same results.
Cant go more than ~4K addresses. I have tried them with vanilla and
custom kernels all 2.6.19+ versions. Results are same on both systems ,
so thats th
> > enum
> > {
> > - TCA_PRIO_UNPSEC,
> > - TCA_PRIO_TEST,
>
>
> You misunderstood me. You can work on top of my compat
> attribute patches, but the example code should not have to go
> in to apply your patch.
Ok. I'll fix my patches.
> > diff --git a/net/sched/Kconfig b/net/sched/Kcon
On Mon, 2007-25-06 at 13:08 -0400, Benjamin LaHaise wrote:
> CPUID:
>
> vendor_id : GenuineIntel
> cpu family : 15
> model : 4
> model name : Intel(R) Xeon(TM) CPU 2.80GHz
>
> shows that it is a P4 Xeon, which sucks compared to:
>
> vendor_id : GenuineIntel
> cpu
> This patch adds a new attribute type that can be used to
> replace non-nested attributes that contain structures by
> nested ones in a compatible way.
>
> This can be used in cases like Peter's who is trying to
> extend sch_prio, which currently uses a fixed structure
> without any holes.
>
On Fri, 2007-22-06 at 12:09 +0200, Johannes Berg wrote:
> Why do you think that would be hard? It'd basically just mean replacing
> the netlink_capable(sock, NL_NONROOT_RECV) calls with a call that
> actually tests depending on the group(s) it wants.
I think it could be done. You will need to hav
On Mon, Jun 25, 2007 at 12:59:54PM -0400, jamal wrote:
> On Thu, 2007-21-06 at 12:55 -0400, Benjamin LaHaise wrote:
>
> > You should qualify that as 'Old P4 Xeon', as the Core 2 Xeons are leagues
> > better.
>
> The Xeon hardware is not that old - about a year or so (and so is the
> opteron).
>
David Hollis wrote:
> You wouldn't happen to know what PHY that device is using? The AX88178
> (Gigabit USB Ethernet) support in the driver currently only supports the
> Marvell PHY, which is the only one I've actually encountered to-date.
I'll quote a few of strings that are spewed that I assum
On Thu, 2007-21-06 at 12:55 -0400, Benjamin LaHaise wrote:
> You should qualify that as 'Old P4 Xeon', as the Core 2 Xeons are leagues
> better.
The Xeon hardware is not that old - about a year or so (and so is the
opteron).
BTW, how could you tell this was old Xeon?
cheers,
jamal
-
To unsub
On Thu, 2007-21-06 at 20:45 +0400, Evgeniy Polyakov wrote:
> On Thu, Jun 21, 2007 at 11:54:17AM -0400, jamal ([EMAIL PROTECTED]) wrote:
> > Evgeniy, did you sync on the batching case with the git tree?
>
> My tree contains following commits:
>
> Latest mainline commit: fa490cfd15d7ce0900097cc4e60
On Fri, 2007-22-06 at 09:26 +0800, Zhu Yi wrote:
> On Thu, 2007-06-21 at 11:39 -0400, jamal wrote:
> It sounds stupid I'm still trying to convince you why we need multiqueue
> support in Qdisc when everybody else are already working on the code,
If you go back historically (maybe 2 years ago on n
> > /* ensure 32-byte alignment of both the device and
> private area */
> > - alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST) &
> ~NETDEV_ALIGN_CONST;
> > + alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST +
> > +(sizeof(struct net_device_subqueue) *
> (queue_count - 1))
On Mon, 25 Jun 2007 15:15:14 +0200
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> OBATA Noboru wrote:
> > From: OBATA Noboru <[EMAIL PROTECTED]>
> >
> > Make TCP_RTO_MAX a variable, and allow a user to change it via a
> > new sysctl entry /proc/sys/net/ipv4/tcp_rto_max. A user can
> > then guarant
On Mon, 25 Jun 2007 22:09:39 +0900 (JST)
OBATA Noboru <[EMAIL PROTECTED]> wrote:
> From: OBATA Noboru <[EMAIL PROTECTED]>
>
> Make TCP_RTO_MAX a variable, and allow a user to change it via a
> new sysctl entry /proc/sys/net/ipv4/tcp_rto_max. A user can
> then guarantee TCP retransmission to be m
Quoting Jeff Garzik ([EMAIL PROTECTED]):
> Eric W. Biederman wrote:
> >Jeff Garzik <[EMAIL PROTECTED]> writes:
> >
> >>David Miller wrote:
> >>>I don't accept that we have to add another function argument
> >>>to a bunch of core routines just to support this crap,
> >>>especially since you give no
Quoting David Miller ([EMAIL PROTECTED]):
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sat, 23 Jun 2007 11:19:34 -0600
>
> > Further and fundamentally all a global achieves is removing the need
> > for the noise patches where you pass the pointer into the various
> > functions. For long
Patrick McHardy wrote:
>
> I normally wouldn't have gone reading some PDF to explain a patch,
> but this one was really worth it .. a couple of pictures of cars
> with four applications using can0-can3 :)
>
This is a really cool insight for car manufacturers employees. If you
miss them out you'
On Mon, 25 Jun 2007 10:28:38 +0530
Varun Chandramohan <[EMAIL PROTECTED]> wrote:
> According to the RFC 4292 (IP Forwarding Table MIB) there is a need for an
> age entry for all the routes in the routing table. The entry in the RFC is
> inetCidrRouteAge and oid is inetCidrRouteAge.1.10.
> Many s
OBATA Noboru wrote:
> From: OBATA Noboru <[EMAIL PROTECTED]>
>
> Make TCP_RTO_MAX a variable, and allow a user to change it via a
> new sysctl entry /proc/sys/net/ipv4/tcp_rto_max. A user can
> then guarantee TCP retransmission to be more controllable, say,
> at least once per 10 seconds, by sett
From: OBATA Noboru <[EMAIL PROTECTED]>
Make TCP_RTO_MAX a variable, and allow a user to change it via a
new sysctl entry /proc/sys/net/ipv4/tcp_rto_max. A user can
then guarantee TCP retransmission to be more controllable, say,
at least once per 10 seconds, by setting it to 10. This is
quite hel
On 6/25/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On Jun 25 2007 12:41, Robert Iakobashvili wrote:
>> > I am getting after initial successes some errors:
>> > "rtnl_talk(): RTNETLINK answers: Cannot allocate memory"
>> > and
>> > #ip addr | wc-l is 8194.
>>
>> I'd be surprised if it was 4096
On Jun 25 2007 12:41, Robert Iakobashvili wrote:
>> > I am getting after initial successes some errors:
>> > "rtnl_talk(): RTNETLINK answers: Cannot allocate memory"
>> > and
>> > #ip addr | wc-l is 8194.
>>
>> I'd be surprised if it was 4096 on x86 and 8192 on x86_64...
>
> Missed to mention: the
On Mon, 2007-06-25 at 11:30 +0200, Patrick McHardy wrote:
> Patrick McHardy wrote:
> > It is. This patch I had originally planned for 2.6.23 switches HTB
> > to the generic estimator, which shouldn't suffer from this.
> >
> > Ranko, can you try if it fixes your timer problem?
>
>
> Forgot the pa
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon, 25 Jun 2007 10:51:59 +0200
> David Miller wrote:
> > Patrick please give me a suitable signed-off-by line, I'd
> > like to apply this to net-2.6.23
> >
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Applied and pushed out, thanks Pa
Oliver Hartkopp wrote:
> Hello Patrick and Jamal,
>
> as i felt a bit misunderstood in the discussion about the usage of
> skb->iif and the idea behind the virtual CAN driver i created four
> PDF-slides to clarify some issues. The slides may give you the
> appropriate background why the incoming (
Hi all,
Here is a list of some known regressions in 2.6.22-rc6
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
*STATISTICS* (a.k.a. list of aces)
NameRegressions fixed since 21-Jun-2007
Andi Kleen
Hi
On 6/25/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On Jun 25 2007 11:47, Robert Iakobashvili wrote:
>
> I am getting after initial successes some errors:
> "rtnl_talk(): RTNETLINK answers: Cannot allocate memory"
> and
> #ip addr | wc-l is 8194.
I'd be surprised if it was 4096 on x86 and
Jan Engelhardt wrote:
> On Jun 24 2007 15:08, Kyle Moffett wrote:
>
>>Do you really need that many IP addresses? When somebody finally gets
>>around to implementing REDIRECT support for ip6tables then you could
>>just redirect them all to the same port on the local system.
>
>
> The way I see i
On Jun 25 2007 11:47, Robert Iakobashvili wrote:
>
> I am getting after initial successes some errors:
> "rtnl_talk(): RTNETLINK answers: Cannot allocate memory"
> and
> #ip addr | wc-l is 8194.
I'd be surprised if it was 4096 on x86 and 8192 on x86_64...
Jan
--
-
To unsubscribe from t
Patrick McHardy wrote:
> It is. This patch I had originally planned for 2.6.23 switches HTB
> to the generic estimator, which shouldn't suffer from this.
>
> Ranko, can you try if it fixes your timer problem?
Forgot the patch ..
[NET_SCHED]: sch_htb: use generic estimator
Use the generic estima
Andrew Morton wrote:
> On Sun, 24 Jun 2007 21:57:19 -0700 (PDT) [EMAIL PROTECTED] wrote:
>
>>I've been experiencing problems with HTB where the whole machine locks
>>up. This usually happens when the whole qdisc is being removed and
>>occasionally when a leaf is being removed.
It shouldn't happe
David Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Sun, 24 Jun 2007 14:53:36 +0200
- sendmsg eth0, no NAT: sys 0m2.508s
- sendmsg eth0, NAT:sys 0m2.539s
- sendmsg eth0, NAT + patch:sys 0m2.445s(no change)
This is probably be
David Miller wrote:
Patrick please give me a suitable signed-off-by line, I'd
like to apply this to net-2.6.23
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo i
David,
On 6/25/07, David Jones <[EMAIL PROTECTED]> wrote:
>> > I am trying to add multiple IP addresses ( v6 ) to my FC7 box on eth0.
>> > But I am hitting a max limit of 4000 IP address . Seems like there
>> is a
>> > limiting variable in linux kernel (which one? ) that prevents from
>> > addi
From: Varun Chandramohan <[EMAIL PROTECTED]>
Date: Mon, 25 Jun 2007 13:28:37 +0530
> Ok i understand. But can you suggest anyother way to do the above?
Just because I found a fault in your patch doesn't mean that
it becomes my job isn't to implement the feature for you.
-
To unsubscribe from this
On Sun, Jun 24, 2007 at 23:11:20 -0700, Stephen Hemminger wrote:
> On Fri, 22 Jun 2007 07:53:42 +0200
> Tino Keitel <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I just found this in the kernel log:
> >
> > 2007-06-22_05:47:50.69894 kern.info: sky2 eth0: disabling interface
> > 2007-06-22_05:47:5
David Miller wrote:
> From: Varun Chandramohan <[EMAIL PROTECTED]>
> Date: Mon, 25 Jun 2007 10:51:39 +0530
>
>
>> YOSHIFUJI Hideaki / wrote:
>>
>>> In article <[EMAIL PROTECTED]> (at Mon, 25 Jun 2007 10:28:38 +0530), Varun
>>> Chandramohan <[EMAIL PROTECTED]> says:
>>>
>>>
81 matches
Mail list logo
