headers
Samuel Ortiz | 1 Oct 2007 01:21

[PATCH] IrDA: Oops fix for ksdazzle

Hi Dave,

This is the last remaining patch for IrDA, against net-2.6.24.

It fixes a kernel oops triggered by the ksdazzle SIR driver.
We need more space for input frames, and 2048 should be plenty of it.

Signed-off-by: Alex Villacís Lasso <a_villacis <at> palosanto.com>
Signed-off-by: Samuel Ortiz <samuel <at> sortiz.org>

---
 drivers/net/irda/ksdazzle-sir.c |   16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

Index: net-2.6.24-quilt/drivers/net/irda/ksdazzle-sir.c
===================================================================
--- net-2.6.24-quilt.orig/drivers/net/irda/ksdazzle-sir.c	2007-10-01 01:53:56.000000000 +0300
+++ net-2.6.24-quilt/drivers/net/irda/ksdazzle-sir.c	2007-10-01 01:53:58.000000000 +0300
 <at>  <at>  -1,7 +1,7  <at>  <at> 
 /*****************************************************************************
 *
 * Filename:      ksdazzle.c
-* Version:       0.1.1
+* Version:       0.1.2
 * Description:   Irda KingSun Dazzle USB Dongle
 * Status:        Experimental
 * Author:        Alex Villacís Lasso <a_villacis <at> palosanto.com>
 <at>  <at>  -113,6 +113,7  <at>  <at> 
 #define KINGSUN_REQ_SEND 0x09
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Oct 2007 02:41
Favicon

Re: [PATCH 2/3 Rev4] Initilize and populate age field

From: Varun Chandramohan <varunc <at> linux.vnet.ibm.com>
Date: Thu, 20 Sep 2007 20:57:51 +0530

>  <at>  <at>  -420,6 +421,7  <at>  <at>  static int fn_hash_insert(struct fib_tab
>  	else
>  		fa = fib_find_alias(&f->fn_alias, tos, fi->fib_priority);
>  
> +	do_gettimeofday(&tv);
>  	/* Now fa, if non-NULL, points to the first fib alias
>  	 * with the same keys [prefix,tos,priority], if such key already
>  	 * exists or to the node before which we will insert new one.

gettimeofday() is expensive, we don't even use it to timestamp every
incoming packet and we therefore should not do it every route cache
entry we create in order to handle DoS situations efficiently

I honestly don't like these patches.  I literally cringe every time
you post a new revision.  It's either going to add new costs to route
management or be so inaccurate as to be useless.

I question it's usefulness even if implemented efficiently and
accurately.  I really don't see people lining up asking for a route
aging metric.

We could report zero and be compliant with the RFC, we don't age our
route entries like the model of the SNMP vars seems to suggest, so
it's honestly accurate.  And this would mean no kernel changes, as the
userland program could just report zero in the absense of a kernel
provided value.
-
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Oct 2007 02:51
Favicon

Re: SFQ qdisc crashes with limit of 2 packets

From: Alexey Kuznetsov <kuznet <at> ms2.inr.ac.ru>
Date: Fri, 21 Sep 2007 19:55:22 +0400

> Hello!
> 
> Remove artificial limitation for sfq queue limit.
> 
> This is followup to Patrick's patch. A little optimization to enqueue
> routine allows to remove artificial limitation on queue length.
> 
> Plus, testing showed that hash function used by SFQ is too bad or even worse.
> It does not even sweep the whole range of hash values.
> Switched to Jenkins' hash.
> 
> 
> Signed-off-by: Alexey Kuznetsov <kaber <at> ms2.inr.ac.ru>

Applied, thanks Alexey.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
David Miller | 1 Oct 2007 02:57
Favicon

Re: [PATCH 1/2] bnx2: factor out gzip unpacker

From: "Michael Chan" <mchan <at> broadcom.com>
Date: Fri, 21 Sep 2007 19:47:17 -0700

> On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote:
> > From: Denys Vlasenko <vda.linux <at> googlemail.com>
> > Date: Fri, 21 Sep 2007 18:03:55 +0100
> > 
> > > Do patches look ok to you?
> > 
> > I'm travelling so I haven't looked closely yet :-)
> > 
> > Michael can take a look and I'll try to do so as well
> > tonight.
> > 
> 
> I've already reviewed the earlier versions of the patch and have made
> some suggestions.  This latest one looks ok to me and tested ok.
> 
> I'll follow up later with another patch to remove all the zeros in other
> firmware sections, and to remove the gzip headers completely.
> 
> Acked-by: Michael Chan <mchan <at> broadcom.com>

I've added these patches to net-2.6.24, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kok, Auke | 1 Oct 2007 03:59
Picon
Favicon

Re: [PATCH][E1000E] some cleanups

jamal wrote:
> On Sun, 2007-30-09 at 15:23 -0400, Jeff Garzik wrote:
> 
>> Gotta wait a bit, otherwise we have confusion and a bit of breakage from 
>> two drivers with the same PCI IDs.
> 
> ah, ok ;-> 
> When i was testing i compiled out e1000. I am willing to totaly migrate
> to e1000e, since major machine i have access to has PCIE. Auke, just let
> me know what you need to do other than uncommenting the table entries
> and i will leave you alone ;->

the IDs are the only thing needed to enable all pci-e e1000 hardware.

by all means we need to have guys like you and Jeff test the commented IDs! I've
been doing this myself and the e1000e driver goes to our labs for a period of
testing from next week. Unfortunately they don't know how to break it that good as
some of you guys ;)

I'll personally try to get an 82571EB tested on monday.

Auke
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Brian Haley | 1 Oct 2007 05:27
Picon
Favicon

Re: [IPV6] Fix ICMPv6 redirect handling with target multicast address

Hi Yoshifuji,

YOSHIFUJI Hideaki / ???? wrote:
> Dave, Brian,
> 
> Let me double check this patch.
> 
> Regards,
> 
> --yoshfuji
> 
> In article <OF5FC97D70.5FD0A80A-ON88257365.00025E58-88257365.00048D1E <at> us.ibm.com> (at Fri, 28
Sep 2007 17:50:38 -0700), David Stevens <dlstevens <at> us.ibm.com> says:
> 
>> Brian,
>>         A multicast address should never be the target of a neighbor
>> discovery request; the sender should use the mapping function for all
>> multicasts. So, I'm not sure that your example can ever happen, and it
>> certainly is ok to send ICMPv6 errors to multicast addresses in general.
>> But I don't see that it hurts anything. either (since it should never 
>> happen :-)),

TAHI generates a lot of packets that shouldn't happen :) see below for 
the problem.  The patch in ndisc_send_redirect() is probably 
unnecessary, but since the code was identical I figured it wouldn't hurt.

>> so I don't particularly object, either.
>>         I think it'd also be better if you add the check to be:
>>
>>         if (ipv6_addr_type(target) &
(Continue reading)

Permalink | Reply | 0 comments |
headers
Xia Yang | 1 Oct 2007 05:53
Picon
Favicon

Removing DAD in IPv6

Hi all,

I am new to this list, so please forgive me if I say anything
inappropriate.

I am working on a mobility testbed based on IPv6. In order to improve
the performance, I would like to remove the DAD process during the
auto-configuration process of an IPv6 address for my testbed. 

During my experiment, I observed that when an address is configured
based on a router advertisement, the outgoing packets can be sent out
immediately. But the packets destined to local node can only be received
after some time (about 1 sec). I found the lost packets are discarded in
the kernel and never make it to the transport layer. I suspect it is
caused by the DAD process.

I would like to ask for help on how to remove or disable the DAD process
properly, as long as the node can send, receive and forward packets
immediately after a new IPv6 address is generated. Any pointer is
appreciated. Thanks a lot in advance!

Best Regards,

Xia Yang

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bill Fink | 1 Oct 2007 06:11
Picon

Re: [PATCH 2/3][NET_BATCH] net core use batching

On Sun, 30 Sep 2007, jamal wrote:

> This patch adds the usage of batching within the core.
> 
> cheers,
> jamal

> [sep30-p2of3  text/plain (6.8KB)]
> [NET_BATCH] net core use batching
> 
> This patch adds the usage of batching within the core.
> The same test methodology used in introducing txlock is used, with
> the following results on different kernels:
> 
>         +------------+--------------+-------------+------------+--------+
>         |       64B  |  128B        | 256B        | 512B       |1024B   |
>         +------------+--------------+-------------+------------+--------+
> Original| 467482     | 463061       | 388267      | 216308     | 114704 |
>         |            |              |             |            |        |
> txlock  | 468922     | 464060       | 388298      | 216316     | 114709 |
>         |            |              |             |            |        |
> tg3nobtx| 468012     | 464079       | 388293      | 216314     | 114704 |
>         |            |              |             |            |        |
> tg3btxdr| 480794     | 475102       | 388298      | 216316     | 114705 |
>         |            |              |             |            |        |
> tg3btxco| 481059     | 475423       | 388285      | 216308     | 114706 |
>         +------------+--------------+-------------+------------+--------+
> 
> The first two colums "Original" and "txlock" were introduced in an earlier
> patch and demonstrate a slight increase in performance with txlock.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Dumazet | 1 Oct 2007 07:59

Re: 2.6.21 -> 2.6.22 & 2.6.23-rc8 performance regression

Denys a écrit :
> Hi 
> 
> I got
> 
> pi linux-git # git bisect bad
> Bisecting: 0 revisions left to test after this
> [f85958151900f9d30fa5ff941b0ce71eaa45a7de] [NET]: random functions can use 
> nsec resolution instead of usec
> 
> I will make sure and will try to reverse this patch on 2.6.22
> 
> But it seems "that's it".

Well... thats interesting...

No problem here on bigger servers, so I CC David Miller and netdev on this one.

AFAIK do_gettimeofday() and ktime_get_real() should use the same underlying 
hardware functions on PC and no performance problem should happen here.

(relevant part of this patch :

 <at>  -1521,7 +1515,6  <at>  <at>  __u32 secure_ip_id(__be32 daddr)
  __u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
                                  __be16 sport, __be16 dport)
  {
-       struct timeval tv;
         __u32 seq;
         __u32 hash[4];
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Miller | 1 Oct 2007 09:12
Favicon

Re: 2.6.21 -> 2.6.22 & 2.6.23-rc8 performance regression

From: Eric Dumazet <dada1 <at> cosmosbay.com>
Date: Mon, 01 Oct 2007 07:59:12 +0200

> No problem here on bigger servers, so I CC David Miller and netdev
> on this one.  AFAIK do_gettimeofday() and ktime_get_real() should
> use the same underlying hardware functions on PC and no performance
> problem should happen here.

One thing that jumps out at me is that on 32-bit (and to a certain
extent on 64-bit) there is a lot of stack accesses and missed
optimizations because all of the work occurs, and gets expanded,
inside of ktime_get_real().

The timespec_to_ktime() inside of there constructs the ktime_t return
value on the stack, then returns that as an aggregate to the caller.

That cannot be without some cost.

ktime_get_real() is definitely a candidate for inlining especially in
these kinds of cases where we'll happily get computations in local
registers instead of all of this on-stack nonsense.  And in several
cases (if the caller only needs the tv_sec value, for example)
computations can be elided entirely.

It would be constructive to experiment and see if this is in fact part
of the problem.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)

Permalink | Reply | 0 comments |

Gmane