On Sat, Nov 12, 2005 at 05:52:16AM +0100, Adrian Bunk wrote:
> This patch removes the ISA legacy functions that are deprecated since
> kernel 2.4 and that aren't available on all architectures.
>
> The 7 drivers that were still using this obsolete API are now marked
> as BROKEN.
NACK. Al has pa
Jeff Garzik wrote:
I rebooted my RHEL4-based ipv4/ipv6 gateway/server into 2.6.15-rc1, and
very soon the box was brought to its knees, spewing
VFS: file-max limit 400490 reached
Follow-up: I may have excised too much from the head of the log I posted.
It now looks like the radvd troub
Chris Wedgwood wrote:
On Sat, Nov 12, 2005 at 12:26:48AM -0500, Jeff Garzik wrote:
VFS: file-max limit 400490 reached
does lsof show anything useful?
Alas, no. [from memory, I've since rebooted]
lsof | wc -l
808
-
To unsubscribe from this list: send the line "unsubscribe netde
On Sat, Nov 12, 2005 at 12:26:48AM -0500, Jeff Garzik wrote:
> VFS: file-max limit 400490 reached
does lsof show anything useful?
-
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
On Sat, Nov 12, 2005 at 12:27:56AM -0500, Jeff Garzik wrote:
> Matthew Wilcox wrote:
> >On Sat, Nov 12, 2005 at 12:08:29AM -0500, Jeff Garzik wrote:
> >
> >>it's not valid to mark working drivers broken, IMO.
> >>
> >>Mark them x86-only, perhaps.
> >
> >
> >hp100 works fine on parisc.
>
> Certainl
Matthew Wilcox wrote:
On Sat, Nov 12, 2005 at 12:08:29AM -0500, Jeff Garzik wrote:
it's not valid to mark working drivers broken, IMO.
Mark them x86-only, perhaps.
hp100 works fine on parisc.
Certainly. The point was, don't mark them broken, limit them to the
arches where they work.
I rebooted my RHEL4-based ipv4/ipv6 gateway/server into 2.6.15-rc1, and
very soon the box was brought to its knees, spewing
VFS: file-max limit 400490 reached
with the resultant userspace breakage associated with that. Data points:
* recent 2.6.14-git-recent works
* 2.6.15-rc1 fails
On Sat, Nov 12, 2005 at 12:08:29AM -0500, Jeff Garzik wrote:
> it's not valid to mark working drivers broken, IMO.
>
> Mark them x86-only, perhaps.
hp100 works fine on parisc.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More ma
Adrian Bunk wrote:
This patch removes the ISA legacy functions that are deprecated since
kernel 2.4 and that aren't available on all architectures.
The 7 drivers that were still using this obsolete API are now marked
as BROKEN.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
it's not valid t
This patch removes the ISA legacy functions that are deprecated since
kernel 2.4 and that aren't available on all architectures.
The 7 drivers that were still using this obsolete API are now marked
as BROKEN.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
Documentation/DocBook/deviceiobo
Hi:
The recent change to netlink dump "done" callback handling broke IPv6
which played dirty tricks with the "done" callback. This causes an
infinite loop during a dump.
The following patch fixes it.
This bug was reported by Jeff Garzik.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Thanks,
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Fri, 11 Nov 2005 15:21:03 -0800
> On Fri, 2005-11-11 at 15:08 -0800, David S. Miller wrote:
> > From: Sridhar Samudrala <[EMAIL PROTECTED]>
> > Date: Fri, 11 Nov 2005 15:01:42 -0800
> >
> > > I think it is much easier for me to send the patches as
On Fri, 2005-11-11 at 15:08 -0800, David S. Miller wrote:
> From: Sridhar Samudrala <[EMAIL PROTECTED]>
> Date: Fri, 11 Nov 2005 15:01:42 -0800
>
> > I think it is much easier for me to send the patches as attachments
> > rather than re-applying on a new tree. So i am attaching the 4 patches
> > a
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Fri, 11 Nov 2005 15:01:42 -0800
> I think it is much easier for me to send the patches as attachments
> rather than re-applying on a new tree. So i am attaching the 4 patches
> and hope this works for you.
Actually, there are no "Signed-off-by:" l
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Fri, 11 Nov 2005 15:01:42 -0800
> On Fri, 2005-11-11 at 14:13 -0800, David S. Miller wrote:
> > [EMAIL PROTECTED]:~/src/GIT/sctp-2.6$ git pull
> > master.kernel.org:/pub/scm/linux/kernel/git/sridhar/lksctp-2.6.git
> > [EMAIL PROTECTED]'s password:
On Fri, 2005-11-11 at 14:13 -0800, David S. Miller wrote:
> From: Sridhar Samudrala <[EMAIL PROTECTED]>
> Date: Fri, 11 Nov 2005 14:00:40 -0800
>
> > Please pull the following SCTP updates from
> >master.kernel.org:/pub/scm/linux/kernel/git/sridhar/lksctp-2.6.git
>
> I can't pull this cleanly
From: Olaf Kirch <[EMAIL PROTECTED]>
Date: Fri, 11 Nov 2005 11:03:19 +0100
> The patch below fixes a minor issue with inet6_init.
> I noticed though that the code explicitly ignores
> the error code of sock_register by calling:
> (void) sock_register(&inet6_family_ops);
> Why does it do this
From: Ingo Oeser <[EMAIL PROTECTED]>
Date: Fri, 11 Nov 2005 16:33:07 +0100
> Are you sure, that you don't mean just "rtt_sample(sk, tcp_usrtt(skb));" here?
> I always believed that function pointers used like I proposed above.
Both methods of invoking a function via function pointer work
the same
From: Sridhar Samudrala <[EMAIL PROTECTED]>
Date: Fri, 11 Nov 2005 14:00:40 -0800
> Please pull the following SCTP updates from
>master.kernel.org:/pub/scm/linux/kernel/git/sridhar/lksctp-2.6.git
I can't pull this cleanly into Linus's current tree, there
are some file level conflicts:
[EMAIL
Dave,
Please pull the following SCTP updates from
master.kernel.org:/pub/scm/linux/kernel/git/sridhar/lksctp-2.6.git
Thanks
Sridhar
include/linux/sysctl.h |1 +
include/net/sctp/command.h |7 ---
include/net/sctp/structs.h | 19 ---
net/sctp/associola.c
jamal <[EMAIL PROTECTED]> writes:
> duh - I didnt mean to delete _all_ routes. I meant to use that event as
> a base to delete whatever the kernel added and vice-versa.
> what does inactive routes mean? blackhole routes i understand
Negative. Routes that are not considered while making actual ro
jamal <[EMAIL PROTECTED]> writes:
> well, the kernel doesnt add default routes - some admin or daemon does.
> So whatever solution it is should not delete such routes either.
Sure. Inactivate them instead and activate back on carrier (IFF_RUNNING,
not the carrier alone) return.
>> Seems inactive
This is required for always getting the vmalloc()/vfree() prototypes.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/wireless/tiacx/common.c |1 +
drivers/net/wireless/tiacx/pci.c|1 +
drivers/net/wireless/tiacx/usb.c|1 +
3 files changed, 3 insertions(+)
-
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Fri, 11 Nov 2005 10:40:42 -0800
> >Are you sure that removing those last two lines are correct?
> >Maybe this code is trying to influence the congestion window
> >validation engine by updating snd_cwnd_stamp like that. And
> >are we sure that the
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 11 Nov 2005 04:43:47 -0500
> Recent TCP changes broke the build.
>
> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Thanks for catching this Jeff.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMA
No external user and that small - such a function should be static
inline and not a global function.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/sk98lin/h/skvpd.h |8 --
drivers/net/sk98lin/skge.c| 43 --
2 files changed, 21 ins
--- Begin Message ---
http://bugzilla.kernel.org/show_bug.cgi?id=5591
Summary: KERNEL: assertion (!sk->sk_forward_alloc) failed at
net/core/stream.c (279)
Kernel Version: 2.6.14
Status: NEW
Severity: normal
Owner: [EMAIL PROTE
David S. Miller wrote:
From: [EMAIL PROTECTED]
Date: Thu, 10 Nov 2005 15:15:11 -0800
Move all the code that does linear TCP slowstart to one
inline function to ease later patch to add ABC support.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Applied, but one question about t
Jeff Garzik wrote:
Recent TCP changes broke the build.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c
index 4376814..b7d296a 100644
--- a/net/ipv4/tcp_vegas.c
+++ b/net/ipv4/tcp_vegas.c
@@ -236,7 +236,7 @@ static void tcp_vegas_cong_avoi
This seems to have gotten lost, so I'll resend.
Signed-off-by: Andy Fleming <[EMAIL PROTECTED]>
* Added sysfs support to gianfar for modifying FIFO and stashing parameters
* Updated driver to support 10 Mbit, full duplex operation
* Improved comments throughout
* Cleaned up and optimized offloadi
Mitch Williams <[EMAIL PROTECTED]> wrote:
>Jay says he's finally ready to take this patch. So here we go again.
>
>Rebased against 2.6.14 final. Which turned out to be way more work than I
>expected.
>
>Signed-off-by: Mitch Williams <[EMAIL PROTECTED]>
Acked-by: Jay Vosburgh <[EMAIL PROTECTED]
On Fri, 2005-11-11 at 00:36 +0100, Thomas Graf wrote:
> * Stefan Rompf <[EMAIL PROTECTED]> 2005-11-10 19:46
> > fib_disable_ip() evicts all routes pointing to that interface, including
> > userspace generated ones, doesn't it? If so, we don't get away that easy.
>
> Right, the patch represents J
On Thu, 2005-10-11 at 23:10 +, Paul Jakma wrote:
> On Thu, 10 Nov 2005, Thomas Graf wrote:
>
> > This is not only about dial on demand but about "on demand"
> > interfaces. We need to have a route to the device so the
> > driver/manager/whatever can see the demand. If we disable routes on
>
On Thu, 2005-10-11 at 20:01 +0100, Krzysztof Halasa wrote:
> Stefan Rompf <[EMAIL PROTECTED]> writes:
>
> > fib_disable_ip() evicts all routes pointing to that interface, including
> > userspace generated ones, doesn't it? If so, we don't get away that easy.
>
> Right. I'm no longer sure we sho
On Thu, 2005-10-11 at 19:46 +0100, Stefan Rompf wrote:
> Am Mittwoch 09 November 2005 22:12 schrieb Thomas Graf:
>
> > Something like this should do the job, although it doesn't take care
> > of taking things up again for now. Now all supporters of this should
> > tell me how to implement any case
Jeff Garzik wrote:
Frank Pavlic wrote:
[patch 1/7] s390: synthax checking for VIPA addresses fixed
From: Peter Tiedemann <[EMAIL PROTECTED]>
- synthax checking for VIPA addresses fixed
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
diffstat:
qeth.h | 65
+
Hi Stephen,
Stephen Hemminger wrote:
> + if (rtt_sample)
> + (*rtt_sample)(sk, tcp_usrtt(skb));
> }
Are you sure, that you don't mean just "rtt_sample(sk, tcp_usrtt(skb));" here?
I always believed that function
Daniel J Blueman wrote:
Has anyone been able to get the RED (random early detection) qdisc
working lately?
I can't get anything going through it to be dropped or marked; the
'marked', 'early', 'pdrop' and 'other' fields remain at 0 [1]. In my
example script [2], I get the 3072Kbits/s transfer in
Dear Friends,
I am a student working on Linux crypto API and HW accelerators. I want
to change the Linux crypto API to support multiple HW or SW
accelerators. actually I am implementing a scheduler to send the
packet to the best accelerator that can process that packet sooner.
I found your name in
Jeff Garzik wrote:
Vitaly Bordug wrote:
Fs_enet was compile-broken due to recent platform code update (a
number of platform stuff has been moved to the separate header). This
fixes the compile issue.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
hmm, patch doesn't seem to apply
That's
applied
-
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
applied 1-7
-
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
Frank Pavlic wrote:
[patch 1/7] s390: synthax checking for VIPA addresses fixed
From: Peter Tiedemann <[EMAIL PROTECTED]>
- synthax checking for VIPA addresses fixed
Signed-off-by: Frank Pavlic <[EMAIL PROTECTED]>
diffstat:
qeth.h | 65 +++
Vitaly Bordug wrote:
Fs_enet was compile-broken due to recent platform code update (a number
of platform stuff has been moved to the separate header). This fixes the
compile issue.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
hmm, patch doesn't seem to apply
-
To unsubscribe from this
Thomas Graf wrote:
> * Patrick McHardy <[EMAIL PROTECTED]> 2005-11-08 15:11
>
>>I have a patch to do this, but it needs some debugging, for some
>>unknown reason it crashes sometimes if I remove addresses without
>>specifying the mask.
>
> Interesting, do you use an iproute2 version with the wild
On Fri, 11 Nov 2005, Gerd v. Egidy wrote:
Hi,
This is the latest set patches for netfilter IPsec support.
The use of netif_rx for the innermost SA if it used transport
mode has been replaced by explicit NF_HOOK calls in
xfrm{4,6}_input.c.
Could you please describe the solution you implemente
Now that this thread has settled down...
I don't have a philosophical objection to the change, if it gets a
non-trivial segment of the user population working. Since it's just one
report right now, I think its fair to let the patch live outside the
upstream tree.
Jeff
-
To unsub
On Wed, 9 Nov 2005, Mitch Williams wrote:
Jay says he's finally ready to take this patch. So here we go again.
Rebased against 2.6.14 final. Which turned out to be way more work than I
expected.
Is this patchset going to be included in 2.6.15?
Best regards,
Krzys
Hi,
> This is the latest set patches for netfilter IPsec support.
> The use of netif_rx for the innermost SA if it used transport
> mode has been replaced by explicit NF_HOOK calls in
> xfrm{4,6}_input.c.
Could you please describe the solution you implemented a bit more? There was
just so many b
The patch below fixes a minor issue with inet6_init.
I noticed though that the code explicitly ignores
the error code of sock_register by calling:
(void) sock_register(&inet6_family_ops);
Why does it do this?
Olaf
--
Subject:
Recent TCP changes broke the build.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
diff --git a/net/ipv4/tcp_vegas.c b/net/ipv4/tcp_vegas.c
index 4376814..b7d296a 100644
--- a/net/ipv4/tcp_vegas.c
+++ b/net/ipv4/tcp_vegas.c
@@ -236,7 +236,7 @@ static void tcp_vegas_cong_avoid(struct
On Fri, 11 Nov 2005, Thomas Graf wrote:
The state of an on-demand interface must be visible, typically an
on-demand interface is in dormant state and goes to up while it is
in use and back to dormant after some time of inactivity. Further,
if the interface knows that a demand cannot be met it
52 matches
Mail list logo
