Hi Francois,
On Tue, 2 May 2006, Francois Romieu wrote:
Btw the whole serie is available in branch 'netdev-ipg' at:
git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git
The interim steps may be useful if testing reveals something wrong
(especially if it happens in a few weeks/months).
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 2 May 2006 18:02:43 +0200
On Tuesday 02 May 2006 18:19, Just Marc wrote:
I thought that maybe it's time to either set TCP_DEBUG to 0 or
alternatively allow an admin to toggle the printing of this message
off/on? On a few busy web servers
I don't think we should be defining driver APIs when we haven't even
figured out how the core of it would even work yet.
A key part of this is the netfilter bits, that will require
non-trivial flow identification, a hash will simply not be enough, and
it will not be allowed to not support the
Just Marc [EMAIL PROTECTED] wrote:
We're now at 2.6.16.12 and it is still showing thousands of times a day
on a busy web server, have all the bugs been discovered yet?
There are no known bugs on the RX side in 2.6.16 that would cause this.
The few busy web servers that I have access to do
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 2 May 2006 18:02:43 +0200
On Tuesday 02 May 2006 18:19, Just Marc wrote:
I thought that maybe it's time to either set TCP_DEBUG to 0 or
alternatively allow an admin to toggle the printing of this message
off/on? On a few busy web
Hello,
yesterday I did a little mess with GIT... now the patch is
complete. Sorry. :)
I forgot also to say that it has been done against
«linux-2.6.16-stable» branch.
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail:[EMAIL PROTECTED]
Linux Device Driver
Mark Brown wrote:
On Thu, Apr 27, 2006 at 05:54:58AM -0400, Jeff Garzik wrote:
Provide a module option which configures the natsemi driver to use the
external MII port on the chip but ignore any PHYs that may be attached to
it. The link state will be left as it was when the driver started and
Herbert Xu wrote:
BTW, this message is already under net_ratelimit so I don't see any
urgency in getting rid of it completely. If we're going down the
path of disabling it, we probably should go for something more global
rather than a sysctl that controls this one message.
Already there:
Hi,
Just Marc [EMAIL PROTECTED] wrote:
We're now at 2.6.16.12 and it is still showing thousands of times a day
on a busy web server, have all the bugs been discovered yet?
There are no known bugs on the RX side in 2.6.16 that would cause this.
The few busy web servers that I have
On Wed, May 03, 2006 at 01:49:05PM +0100, Just Marc wrote:
You're right, actually this box serves http/ftp file transfers only,
it's a mirror with a large amount of downloads a day.
That's interesting. The RX bug that I fixed earlier would usually
manifest itself under exactly these
Hi
Herbert Xu wrote:
BTW, this message is already under net_ratelimit so I don't see any
urgency in getting rid of it completely. If we're going down the
path of disabling it, we probably should go for something more global
rather than a sysctl that controls this one message.
Already
Just Marc [EMAIL PROTECTED] wrote:
That's good, but it may (and probably will) suppress many other messages
which may be of more interest...
That's the crux of the matter. There is no way we can satisfy everyone
short of putting a knob on each individual printk.
So the only solution is
Hi
On Wed, May 03, 2006 at 01:49:05PM +0100, Just Marc wrote:
You're right, actually this box serves http/ftp file transfers only,
it's a mirror with a large amount of downloads a day.
That's interesting. The RX bug that I fixed earlier would usually
manifest itself under exactly
On Wed, 3 May 2006, Herbert Xu wrote:
Can you take a tcpdump of the TCP sessions involving those IPs and
then show me the sections that occur when those messages are triggered?
I'm curious, how would you do this without filling the disk? With a script
that starts tcpdump to a ring in the
On Wed, May 03, 2006 at 01:47:31PM +0200, Ingo Oeser wrote:
Already there: /proc/sys/net/core/{message_cost,message_burst}
Just set burst to 0 and cost to a very big value to basically supppress
all net_ratelimit()ed messages.
Or did you think of sth. else?
No that'll do just fine.
Hi
Just Marc [EMAIL PROTECTED] wrote:
That's good, but it may (and probably will) suppress many other messages
which may be of more interest...
That's the crux of the matter. There is no way we can satisfy everyone
short of putting a knob on each individual printk.
So the only
On Mon, 01 May 2006 12:31:40 +0300
Pekka Enberg [EMAIL PROTECTED] wrote:
[PATCH] IP1000 Gigabit Ethernet device driver
This is a cleaned up fork of the IP1000A device driver:
http://www.icplus.com.tw/driver-pp-IP1000A.html
Please remember that to merge this we'll need a signed-off-by
On Wed, 3 May 2006, Andrew Morton wrote:
Please remember that to merge this we'll need a signed-off-by from the
original developers. (That's not very gplish, but such is life).
OK. Lets see if we can track one of them developers down. I see Craig
Rich's email (only email found in the original
Hi David,
On Wed, 3 May 2006, David Gómezz wrote:
I'll test it tomorrow ASAP. For now, here is another patch removing
more dead code. This code is never reached (NOTGRACE is not defined)
and the *fiber_detect functions are subsequently never used.
No need to resend this one, but in future,
On Wed, May 03, 2006 at 12:15:30PM +, Alexey Toptygin wrote:
I'm curious, how would you do this without filling the disk? With a script
that starts tcpdump to a ring in the background, waits for the offending
log entry to appear and then kills tcpdump?
Well if you know the set of IPs
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David S. Miller
Sent: Tuesday, May 02, 2006 11:48 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org
Subject: Re: VJ Channel API - driver level (PATCH)
I don't think we
Pekka J Enberg wrote:
On Wed, 3 May 2006, Andrew Morton wrote:
Please remember that to merge this we'll need a signed-off-by from the
original developers. (That's not very gplish, but such is life).
OK. Lets see if we can track one of them developers down. I see Craig
Rich's email (only
Now when there are no interfaces allocated together anymore, let's use
alloc_netdev for allocation of interfaces. We save some code and also
the structures are really aligned finally.
Signed-off-by: Jiri Benc [EMAIL PROTECTED]
---
net/d80211/ieee80211.c | 43
Sending packets from management interface (wmasterXap) didn't work. This
patch fixes that problem; it's not nice but it will go away when the
interface between kernel and hostapd is changed to netlink (the packets will
be sent through master interface then).
Signed-off-by: Jiri Benc [EMAIL
Default management interface (wmasterXap) confuses users. It is only needed
for AP mode (and only until the new netlink interface between kernel and
hostapd is implemented).
This patch removes default management interface. When first interface is
switched to AP mode, a management interface is
Following patches can be also obtained from:
git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git up
Jiri Benc:
d80211: get rid of default management interface
d80211: use alloc_netdev
d80211: fix is_ieee80211_device
net/d80211/ieee80211.c | 150
[EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David S. Miller
Sent: Tuesday, May 02, 2006 11:48 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org
Subject: Re: VJ Channel API - driver level (PATCH)
On Tue, 2 May 2006 14:18:17 -0700, Jouni Malinen wrote:
Add a configuration option for disabling client MLME in kernel
code. This is used to enable user space MLME for client mode (e.g.,
with wpa_supplicant). The kernel MLME implementation is unmodified,
but it could be removed or at least
Hi John,
Please apply to wireless-dev.
--
Rewrite the virtual interface handling.
With this monitor_during_oper is made possible.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx.h
hello *
On Tue, 2006-05-02 at 11:20 -0500, Mark Schank wrote:
At 08:23 AM 5/2/06 +0200, Herbert Valerio Riedel wrote:
On Mon, 2006-05-01 at 15:09 -0500, Mark Schank wrote:
The Cogent CSB655 used the Broadcom Dual Phy. They eventually redesigned
the board and switched to two single
On Wed, May 03, 2006 at 06:28:15PM +0200, Jiri Benc wrote:
It is too early for this. We need to implement some better communication
interface between kernel and hostapd (or what will implement userspace
MLME) first. The current solution, where there is some special
net_device interface
On 5/2/06, Ben Greear [EMAIL PROTECTED] wrote:
In commit: a292ca6efbc1f259ddfb9c902367f2588e0e8b0f
to e1000_main.c, there is the change below.
I am curious why the skb_put no longer subtracts ETHERNET_FCS_SIZE
from the length. Is the idea that we will now always include the
FCS at the end of
On Wed, 3 May 2006 18:42:04 +0200, Michael Buesch wrote:
Rewrite the virtual interface handling.
With this monitor_during_oper is made possible.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Acked-by: Jiri Benc [EMAIL PROTECTED]
--
Jiri Benc
SUSE Labs
-
To unsubscribe from this list:
Are you proposing a mechanism for the consuming end of a tx
channel to support a large number of channels, or are you
assuming that the number of tx channels will be small enough
that simply polling them in priority order is adequate?
-
To unsubscribe from this list: send the line unsubscribe
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler ([EMAIL PROTECTED])
wrote:
I'd expect high end NIC ASICs to implement rx steering based
upon some sort of hash (for load balancing), as well as
explicit 1:1 steering between a sw channel and a hw
channel. Both options for channel
On Wed, 3 May 2006 09:44:58 -0700, Jouni Malinen wrote:
Why do you think that this would be too early now? I agree that the
interface between kernel and user space MLME can be improved, but I see
no point in making client MLME implementation wait for that to happen.
Personally, I don't think
Evgeniy Polyakov wrote:
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
([EMAIL PROTECTED]) wrote:
I'd expect high end NIC ASICs to implement rx steering based upon
some sort of hash (for load balancing), as well as explicit 1:1
steering between a sw channel and a hw channel. Both
Jesse Brandeburg wrote:
On 5/2/06, Ben Greear [EMAIL PROTECTED] wrote:
In commit: a292ca6efbc1f259ddfb9c902367f2588e0e8b0f
to e1000_main.c, there is the change below.
I am curious why the skb_put no longer subtracts ETHERNET_FCS_SIZE
from the length. Is the idea that we will now always
On 5/3/06, Ben Greear [EMAIL PROTECTED] wrote:
So, as of 2.6.16.13, is the hardware stripping (SERC) enabled? Could
you also let me know where this bit is defined in case I want to twiddle
it myself (a quick grep for SERC in 2.6.16.13 yields nothing.)
You missed a C, it's SECRC (Strip
On Wed, May 03, 2006 at 08:10:59PM +0200, Jiri Benc wrote:
If you really feel this is a necessary feature (although I think we
should focus more on putting the stack to a form suitable for inclusion
in the kernel than on adding new features now), what about making the
wmaster0ap interface
In article [EMAIL PROTECTED] (at Wed, 3 May 2006 22:07:40 +0400), Evgeniy
Polyakov [EMAIL PROTECTED] says:
Even if the hardware cannot fully implement netfilter rules
there is still value in having an interface that documents
exactly how much filtering a given piece of hardware can do.
On Wed, 3 May 2006 11:12:15 -0700
Caitlin Bestler [EMAIL PROTECTED] wrote:
Evgeniy Polyakov wrote:
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
([EMAIL PROTECTED]) wrote:
I'd expect high end NIC ASICs to implement rx steering based upon
some sort of hash (for load
Measure the channel change time with the
bcm43xx tsf timer and remove the guesswork constant. ;)
Tests on my 4306 show that the time comes damn
close to reality.
Signed-off-by: Michael Buesch [EMAIL PROTECTED]
Index: wireless-dev/drivers/net/wireless/d80211/bcm43xx/bcm43xx_main.c
Here is a new version that addresses some of the outstanding bugs.
* There was a race in receive processing that would cause hang
* Some more support for Yukon Ultra found in dual-core Centrino
laptops (I want one of these).
It does not fix the problems with dual port cards corrupting receive
From: Leonid Grossman [EMAIL PROTECTED]
Date: Wed, 3 May 2006 09:56:18 -0400
Do you have suggestions on potential hardware assists/offloads for
netfilter?
We don't know yet what things will look like, that's why we
shouldn't be defining APIs and I cannot give any such advice
yet.
-
To
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Wed, 3 May 2006 22:07:40 +0400
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler ([EMAIL PROTECTED])
wrote:
I'd expect high end NIC ASICs to implement rx steering based
upon some sort of hash (for load balancing), as well as
David S. Miller wrote:
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Wed, 3 May 2006 22:07:40 +0400
On Wed, May 03, 2006 at 08:56:23AM -0700, Caitlin Bestler
([EMAIL PROTECTED]) wrote:
I'd expect high end NIC ASICs to implement rx steering based upon
some sort of hash (for load
Hi Pekka,
On May 02 at 10:04:47, Pekka Enberg wrote:
No clear idea but it matches the significant part of the BAR register
for the 256 bytes of I/O space that the device uses.
OK. David David, would appreciate if either you could give the patch a
spin with Francois' changes. Thanks.
I
So I pushed out an update for Fedora Core 5 users yesterday
that moved the kernel from 2.6.16.9 to 2.6.16.13.
I've since heard My network performance is awful, and worse
yet, some apps seem broken as in the report below.
Anyone have any ideas ?
Dave
--
Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
family == AF_INET. For most purposes this is fine, since the two modules
each hold a pointer to their table and pass it into the neigh_* functions.
A problem arises in neigh_add, which is called by the rtnetlink code and
which
On Wed, 03 May 2006 22:32:39 +0100
Simon Kelley [EMAIL PROTECTED] wrote:
Both net/ipv4/arp.c and net/arm/clip.c create neighbour tables with
family == AF_INET. For most purposes this is fine, since the two modules
each hold a pointer to their table and pass it into the neigh_* functions.
A
Pekka J Enberg [EMAIL PROTECTED] :
[...]
maintain the tree, I can send you my patches so you can recreate the full
history. The first steps were produced by quilt on the original
out-of-tree driver, though, so they're probably not helpful.
It will be welcome.
I have added a few little
On Wed, May 03, 2006 at 05:19:15PM -0400, Dave Jones wrote:
So I pushed out an update for Fedora Core 5 users yesterday
that moved the kernel from 2.6.16.9 to 2.6.16.13.
I've since heard My network performance is awful, and worse
yet, some apps seem broken as in the report below.
Further
Dave Jones [EMAIL PROTECTED] wrote:
So I pushed out an update for Fedora Core 5 users yesterday
that moved the kernel from 2.6.16.9 to 2.6.16.13.
I've since heard My network performance is awful, and worse
yet, some apps seem broken as in the report below.
Anyone have any ideas ?
Try
Herbert Xu wrote:
Dave Jones [EMAIL PROTECTED] wrote:
So I pushed out an update for Fedora Core 5 users yesterday
that moved the kernel from 2.6.16.9 to 2.6.16.13.
I've since heard My network performance is awful, and worse
yet, some apps seem broken as in the report below.
Anyone have any
Begin forwarded message:
Date: Tue, 2 May 2006 13:28:22 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 6484] New: dropouts with user mode PPPoE
http://bugzilla.kernel.org/show_bug.cgi?id=6484
Summary: dropouts with user mode PPPoE
Kernel Version:
On Thursday 27 April 2006 16:25, you wrote:
So the idea in your scheme is to give the buffer pools to the NIC
in a per-channel way via a simple descriptor table? And the u32's
are arbitrary keys that index into this descriptor table, right?
yeah - it _was_... Although since having a play
57 matches
Mail list logo
