| Xia Yang | 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
a...
| Sep 30, 11:53 pm 2007 |
| Samuel Ortiz | [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@palosanto.com>
Signed-off-by: Samuel Ortiz <samuel@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
...
| Sep 30, 7:21 pm 2007 |
| jamal | [PATCH][TG3]Some cleanups
Here are some non-batching related changes that i have in my batching
tree. Like the e1000e, they make the xmit code more readable.
I wouldnt mind if you take them over.
cheers,
jamal
| Sep 30, 2:11 pm 2007 |
| jamal |
| Sep 30, 2:12 pm 2007 |
| jamal | [PATCH][E1000E] some cleanups
Auke,
heres part of something i promised.
I couldnt do any packet testing on because 82571EB is disabled in the
driver. I uncommented the code out in the table, but the best i could
get was the module loading, some probing and some sysfs renaming
failures (probably a debianism); the machine access is intermittent, so
thats as far as i could go. In any case, you probably have a good reason
for disabling that chip. So, heres the patch, the burden of testing now
falls on you ;->
Once you have 82...
| Sep 30, 1:41 pm 2007 |
| Kok, Auke | Re: [PATCH][E1000E] some cleanups
no, all the hardware that is commented should work just fine. I tested this driver
on 82571, 82573 and ich8/ich9 - extensively.
the reason that we disable them is that we're going to migrate devices over in
batches. At introduction we'll support ich9, afterwards we'll drop in the IDs of
thanks, I'll go and look at this in depth in the coming weeks.
Auke
-
| Sep 30, 2:16 pm 2007 |
| jamal | Re: [PATCH][E1000E] some cleanups
Something else is wrong then. Can you just uncomment the 82571EB bits in
Dave's net-2.6.24 and just send a ping? If it works, let me know what
It just makes it easier to kill LLTX. If you consider killing LLTX
risky, then i will focus on e1000e.
cheers,
jamal
-
| Sep 30, 3:01 pm 2007 |
| Jeff Garzik |
| Sep 30, 3:23 pm 2007 |
| jamal | Re: [PATCH][E1000E] some cleanups
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 ;->
cheers,
jamal
-
| Sep 30, 3:31 pm 2007 |
| Kok, Auke | Re: [PATCH][E1000E] some cleanups
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
-
| Sep 30, 9:59 pm 2007 |
| Anton Blanchard | ehea work queues
Hi,
I booted 2.6.23-rc8 and noticed that ehea loves its workqueues:
# ps aux|grep ehea
root 3266 0.0 0.0 0 0 ? S< 11:02 0:00 [ehea_driver_wq/]
root 3268 0.0 0.0 0 0 ? S< 11:02 0:00 [ehea_driver_wq/]
root 3269 0.0 0.0 0 0 ? S< 11:02 0:00 [ehea_driver_wq/]
root 3270 0.0 0.0 0 0 ? S< 11:02 0:00 [ehea_driver_wq/]
root 3271 0.0 0.0 0 0 ? S< 11:02 0:00 [ehea_driver_wq/]
root 3272 ...
| Sep 30, 12:20 pm 2007 |
| Patrick McHardy |
| Sep 30, 11:39 am 2007 |
| Denis V. Lunev |
| Sep 30, 9:13 am 2007 |
| Patrick McHardy | Re: [PATCH] rtnl: Simplify ASSERT_RTNL
In the IPv6 case we're only changing the multicast list,
so we're never calling into __dev_set_promiscuity.
I actually even added a comment about this :)
/* Unicast addresses changes may only happen under the rtnl,
* therefore calling __dev_set_promiscuity here is safe.
*/
I would prefer to keep the ASSERT_RTNL in __dev_set_promiscuity
since it also covers the __dev_set_rx_mode path. How about
adding an ASSERT_RTNL_ATOMIC without the might_sleep or simply
open co...
| Sep 30, 11:47 am 2007 |
| Brian Haley | Re: [IPV6] Fix ICMPv6 redirect handling with target multicas...
Hi Yoshifuji,
TAHI generates a lot of packets that shouldn't happen :) see below for
the problem. The patch in ndisc_send_redirect() is probably
I did have it:
if (ipv6_addr_type(target) &
(IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST) ==
(IPV6_ADDR_LINKLOCAL|IPV6_ADDR_UNICAST))
but changed it since I had proposed ipv6_addr_linklocal() in a previous
patch because there are other possible users of that.
This is the actual packet trace that was sent to me, edited to remove
no...
| Sep 30, 11:27 pm 2007 |
| linux | Re: 2.6.23-rc8 network problem. Mem leak? ip1000a?
> ntpd. Sounds like pps leaking to me.
That's what I'd think, except that pps does no allocation in the normal
running state, so there's nothing to leak. The interrupt path just
records the time in some preallocated, static buffers and wakes up
blocked readers. The read path copies the latest data out of those
static buffers. There's allocation when the PPS device is created,
Ah, thanks you; I've been using SLUB which doesn't support this option.
Here's what I've extracted. I've only pres...
| Sep 30, 3:59 am 2007 |
| Andrew Morton | Re: 2.6.23-rc8 network problem. Mem leak? ip1000a?
Absolutely. Normally a driver's transmit completion interrupt handler will
run dev_kfree_skb_irq() against the skbs which have been fully sent.
However it'd be darned odd if the driver was leaking only tcp acks.
I can find no occurrence of "dev_kfree_skb" in drivers/net/ipg.c, which is
suspicious.
I assume that meminfo was not captured when the system was ooming? There
isn't much slab there.
-
| Sep 30, 5:23 am 2007 |
| linux | Re: 2.6.23-rc8 network problem. Mem leak? ip1000a?
> OK. Did you try to reproduce it without the pps patch applied?
No. But I've yanked the ip1000a driver (using old crufy vendor-supplied
It's leaking lots of things... you can see ARP packets in there and
all sorts of stuff. But the big traffic hog is BackupPC doing inbound
rsyncs all night long, which generates a lot of acks. Those are the
Look for "IPG_DEV_KFREE_SKB", which is a wrapper macro. (Or just add
"-i" to your grep.) It should probably be deleted (it just expands to
As I w...
| Sep 30, 7:40 am 2007 |
| Patrick McHardy | Re: [PKT_SCHED]: Add stateless NAT
From a quick look it seems at least IPv4 and IPv6 don't need to
change the skb anywhere else. It seems to be necessary for
bridging though to unshare the skb. OTOH br_netfilter.c already
unshares the skb for IPv4 and IPv6, so we could simply do this
unconditionally before calling the hooks.
-
| Sep 30, 11:38 am 2007 |
| David Miller |
| Sep 30, 8:57 pm 2007 |
| David Miller | Re: [PATCH 2/3 Rev4] Initilize and populate age field
From: Varun Chandramohan <varunc@linux.vnet.ibm.com>
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 efficie...
| Sep 30, 8:41 pm 2007 |
| David Miller |
| Sep 30, 8:51 pm 2007 |
| jamal | [PATCHES] TX batching
Latest net-2.6.24 breaks the patches i posted last week; so this is an
update to resolve that. If you are receiving these emails and are
finding them overloading, please give me a shout and i will remove your
name.
Please provide feedback on the code and/or architecture.
Last time i posted them i received none. They are now updated to
work with the latest net-2.6.24 from a few hours ago.
Patch 1: Introduces batching interface
Patch 2: Core uses batching interface
Patch 3: get rid of dev->...
| Sep 30, 2:50 pm 2007 |
| jamal | Re: [PATCHES] TX batching
And heres a patch that provides a sample of the usage for batching with
tg3.
Requires patch "[TG3]Some cleanups" i posted earlier.
cheers,
jamal
| Sep 30, 3:19 pm 2007 |
| jamal |
| Sep 30, 2:51 pm 2007 |
| jamal |
| Sep 30, 2:54 pm 2007 |
| jamal |
| Sep 30, 2:52 pm 2007 |
| jamal |
| Sep 30, 2:53 pm 2007 |
