Hua Zhong <[EMAIL PROTECTED]> wrote:
>
> I am developing a profiling tool to check if likely/unlikely usages are wise.
> I find that the following one is always a miss:
>
> # Hit# miss Function:[EMAIL PROTECTED]
> ! 0 50505 tcp_transmit_skb():net/ipv4/[EMAIL PROTECTED]
>
>
On Mon, Apr 24, 2006 at 01:56:09AM +0200, Florian Zumbiehl wrote:
>
> Well, at least the tcp part of it, it seems, yep. The debugging I've
> done so far also seems to confirm that the problem is somewhere beyond
> the tcp code, but I don't have any real clue yet ...
One way to proceed is to add p
linux-os (Dick Johnson) wrote:
On Mon, 24 Apr 2006, Auke Kok wrote:
Ingo Oeser wrote:
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible. One bottleneck is the
receive interrupt,
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> This follows after the earlier two patches.
>
> Change the initialization of the class device portion of the net device
> to be done earlier, so that any races before registration completes are
> harmless. Add a mutex to avoid changes to netdevice
The udev stuff runs after the device has already chosen it's default name.
It has to, it's part of the hotplug infrastructure, and we don't want
to depend on usermode to define the name. Just choose some other
convention "eth_0" or something like that.
Is that because adding another NIC at a
On Mon, 2006-04-24 at 16:40 -0400, John W. Linville wrote:
> The following changes since commit 7c241d37fe0e6442c5cf3b5d73f7f58f2dc66352:
> Michael Buesch:
> bcm43xx: make PIO mode usable
>
> are found in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linvill
On Mon, 24 Apr 2006 16:47:34 -0700
Rick Jones <[EMAIL PROTECTED]> wrote:
> I might be out to lunch, certainly it happens often enough :) I've
> spent the afternoon trying to stop my NIC names from being "random" on
> each boot. To that end, I've been doing udev rules based on an example
> I f
I might be out to lunch, certainly it happens often enough :) I've
spent the afternoon trying to stop my NIC names from being "random" on
each boot. To that end, I've been doing udev rules based on an example
I found at http://www.debianhelp.co.uk/udev.htm In this case I'm
running a Debian 2
This follows after the earlier two patches.
Change the initialization of the class device portion of the net device
to be done earlier, so that any races before registration completes are
harmless. Add a mutex to avoid changes to netdevice during the
class device registration.
Signed-off-by: St
On Fri, Apr 14, 2006 at 06:48:31PM -0400, Luis R. Rodriguez wrote:
>
> John, (Jean please update your docs)
>
> as promised here's a new 802.11b driver for wireless-2.6. It is based on
> Jouni Malinen's original work and maintained by Michael Wu.
> This driver is for ADM8211A, ADM8211B, and ADM82
On Fri, Mar 31, 2006 at 11:31:59PM -0800, Pete Zaitcev wrote:
> Implement proper set_bssid_filter. If filters are not set, firmware receives
> management frames only (instead of everything), so this is necessary.
Merged to master branch of wireless-2.6 tree.
Thanks!
--
John W. Linville
[EMAIL PR
The following changes since commit 6b426e785cb81e53dc2fc4dcf997661472b470ef:
Linus Torvalds:
Merge git://git.kernel.org/.../kyle/parisc-2.6
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-fixes
Johannes Berg:
Hi
We will consider moving vpd_data out of stack. We will wait for few more
time for other review comment, and submit one more patch on top of 5th patch
addressing all review comments.
If there are no further comments please apply the patches 1 to 5 and notify
us. We will submit one more patch w
On Mon, 24 Apr 2006, Rick Jones wrote:
Thats right. This will be made a non issue with early demuxing
on the NIC and MSI (or was it MSI-X?) which will select
the right CPU based on hardware channels.
>>>
>>> MSI-X. with MSI you still have only one cpu handling all MSI interrupts an
On Mon, 24 Apr 2006 10:39:52 -0700
"Ananda Raju" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Currently the only way we can differentiate between copper CX4 transponder
> adapters from optical transponder adapters is by reading the product name
> string in vpd.
That makes sense. Though often the VPD
Hi,
Currently the only way we can differentiate between copper CX4 transponder
adapters from optical transponder adapters is by reading the product name
string in vpd.
Actually we added the VPD read function for identifying CX4 adapter. While
submitting the patch the CX4 changes went in patch 3
On Mon, 24 Apr 2006 00:52:35 +0200
Hagen Paul Pfeifer <[EMAIL PROTECTED]> wrote:
> * Stephen Hemminger | 2006-04-21 08:19:17 [-0700]:
>
> >2.6.13 still had lots of problems, things didn't really get working
> >right till 2.6.15 or later. Especially with TSO.
>
> --verbose?
>
> >I have a tool us
[EMAIL PROTECTED] wrote:
> Subject: Re: Van Jacobson's net channels and real-time
>
>
> On Mon, 24 Apr 2006, Auke Kok wrote:
>
>> Ingo Oeser wrote:
>>> On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden o
On Sat, 22 Apr 2006 11:03:01 +0200
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Jeff Kirsher <[EMAIL PROTECTED]> :
> [...]
> > diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
> > index c83271b..a696c33 100644
> > --- a/drivers/net/ixgb/ixgb.h
> > +++ b/drivers/net/ixgb/ixgb.h
> [...
Thats right. This will be made a non issue with early demuxing
on the NIC and MSI (or was it MSI-X?) which will select
the right CPU based on hardware channels.
MSI-X. with MSI you still have only one cpu handling all MSI interrupts and
that doesn't look any different than ordinary interrupts. M
On Sat, 22 Apr 2006 11:28:02 +0200
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Ananda Raju <[EMAIL PROTECTED]> :
> [...]
> > Signed-off-by: Ananda Raju <[EMAIL PROTECTED]>
> > ---
> > diff -upNr perf_fixes/drivers/net/s2io.c
> > dmesg_param_fixes/drivers/net/s2io.c
> > --- perf_fixes/drivers/net
On Mon, 24 Apr 2006, Auke Kok wrote:
> Ingo Oeser wrote:
>> On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
>>> That was another main point, yes. And the endpoints should be as
>>> little burden on the bottlenecks as possible. One bottleneck is the
>>> receive interrupt, which shouldn't wa
Ingo Oeser wrote:
On Saturday, 22. April 2006 15:49, Jörn Engel wrote:
That was another main point, yes. And the endpoints should be as
little burden on the bottlenecks as possible. One bottleneck is the
receive interrupt, which shouldn't wait for cachelines from other cpus
too much.
Thats r
On 4/24/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 24, 2006 at 01:42:12PM +0800, Aubrey wrote:
> >
> > dev->last_rx = jiffies;
> > skb->dev = dev;
> > skb->protocol = eth_type_trans(skb, dev);
> > skb->ip_summed = CHECKSUM_UNNECESSARY;
> > netif_rx(skb);
>
> This doesn't make
On Fri, 21 Apr 2006 19:44:31 -0700, Jouni Malinen wrote:
> On Fri, Apr 21, 2006 at 10:53:28PM +0200, Jiri Benc wrote:
> > Default management interface (wlanXap) confuses users. It is only needed for
> > AP mode (and only until interfaces are converted to use native 802.11
> > frames).
>
> Or when
On Sun, 23 Apr 2006, Török Edwin wrote:
> > This could be done with nfqueue, modular policy and a pretty simple tool.
> How do I determine if the policy needs to be changed? I.e. how do I determine
> if the packet would be dropped? You say packets are silently dropped, won't
> they generate an a
On Mon, Apr 24, 2006 at 01:42:12PM +0800, Aubrey wrote:
>
> dev->last_rx = jiffies;
> skb->dev = dev;
> skb->protocol = eth_type_trans(skb, dev);
> skb->ip_summed = CHECKSUM_UNNECESSARY;
> netif_rx(skb);
This doesn't make sense. First of all you're setting ip_summed to
CHECK_UNNECESSARY
From: Heiko Carstens <[EMAIL PROTECTED]>
Convert inet_init to an fs_initcall to make sure its called before any device
driver's initcall.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
net/ipv4/af_inet.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/af_i
> > Tried to figure out what is causing the delays I experienced when I replaced
> > module_init() in af_inet.c with fs_initcall(). After all it turned out that
> > synchronize_net() which is basicically nothing else than synchronize_rcu()
> > sometimes takes several seconds to complete?! No idea w
m I have forgotten to tell you that both mimosa & pleiadi
are running 2.6.16.9 driven by openswan 2.4.5
-
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
Hi Herbert,
The following change works properly on my side, it just do the same
thing as the driver not in netpoll mode. Let me know it's acceptable,
please.
Thanks,
-Aubrey
==
int __netpoll_rx(struct sk_buff *skb)
{
snip
if (ip_
Hi
When i ran the below command on vicidial dialer:
[EMAIL PROTECTED] ~]# tethereal -i eth0 -a duration:300 -w sample.cap
Capturing on eth0
320167
147496 packets dropped
Machine configuration:
Linux vicidial2.esselshyam.net 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2
23:08:39 EDT 2005 i686 i686 i386 G
Hi Herbert,
Things seem to be more clear for me.
When not in netpoll mode, before an udp package passed to "udp_rcv",
the ip layer will call the routine "__skb_checksum_complete(skb);"
to do the checksum. After ip checksum, "skb->ip_summed" will be
assigned to CHECKSUM_UNNECESSARY.
On Sat, Apr 22, 2006 at 02:02:59AM +0200, Andi Kleen told us:
> On Friday 21 April 2006 19:15, Jesse Brandeburg wrote:
> > On 4/21/06, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > We do seem to have had a few reports of ppp regressions around this
> > > timeframe.
> >
> > me too. I couldn
34 matches
Mail list logo
