On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote:
diff --git a/arch/s390/lib/Makefile b/arch/s390/lib/Makefile
index 7a44fed..59aea65 100644
--- a/arch/s390/lib/Makefile
+++ b/arch/s390/lib/Makefile
@@ -5,6 +5,6 @@
EXTRA_AFLAGS := -traditional
lib-y +=
(added netdev)
On Wed, 11 Apr 2007 09:57:33 +0400 Yuriy N. Shkandybin [EMAIL PROTECTED]
wrote:
I've tested 2.6.21-rc6-mm1
Linux vpn1 2.6.21-rc6-mm1 #4 SMP Wed Apr 11 03:34:26 MSD 2007 x86_64
Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux
warn appeares upon first pppoe
Hi:
[NET]: Get rid of NETIF_F_INTERNAL_STATS
The recently added NETIF_F_INTERNAL_STATS isn't very useful. If the
device driver needs to set it then it can always override get_stats
instead. All existing drivers that have stats (which should be every
one) will override get_stats anyway. Those
On 4/11/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote:
I think this means that if CONFIG_32BIT=y, s390 networking gets the whizzy
assembly version and if CONFIG_32BIT=n, it gets to use the generic version.
Possibly the
From: Martin Schwidefsky [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 10:15:42 +0200
On 4/11/07, Andrew Morton [EMAIL PROTECTED] wrote:
On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller [EMAIL PROTECTED]
wrote:
I think this means that if CONFIG_32BIT=y, s390 networking gets the whizzy
On Tue, 10 Apr 2007, Jan Engelhardt wrote:
(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
ArcNet is old. Almost nobody is using it anymore. I used it at my former
job, since we used it as control network. A lot of companies still does
quitely, but not in combination
On Apr 11 2007 10:30, Esben Nielsen wrote:
On Tue, 10 Apr 2007, Jan Engelhardt wrote:
(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
ArcNet is old. Almost nobody is using it anymore. I used it at my
former job, since we used it as control network. A lot of companies
(added netdev)
On Wed, 11 Apr 2007 09:57:33 +0400 Yuriy N. Shkandybin [EMAIL PROTECTED]
wrote:
I've tested 2.6.21-rc6-mm1
Linux vpn1 2.6.21-rc6-mm1 #4 SMP Wed Apr 11 03:34:26 MSD 2007 x86_64
Intel(R) Pentium(R) D CPU 2.80GHz GenuineIntel GNU/Linux
warn appeares upon first pppoe
On Tue, 10 Apr 2007, David Miller wrote:
As the merge window approaches I've made a decision about how to
handle the TCP RB-Tree work since it's getting really close.
First, I'm going to rebase the net-2.6.22 tree after making a quick
run through my patch backlog looking for low hanging
On Wed, 11 Apr 2007 12:52:28 +0400 Yuriy N. Shkandybin [EMAIL PROTECTED]
wrote:
(added netdev)
On Wed, 11 Apr 2007 09:57:33 +0400 Yuriy N. Shkandybin [EMAIL
PROTECTED]
wrote:
I've tested 2.6.21-rc6-mm1
Linux vpn1 2.6.21-rc6-mm1 #4 SMP Wed Apr 11 03:34:26 MSD 2007 x86_64
On Wed, 11 Apr 2007, Jan Engelhardt wrote:
On Apr 11 2007 10:30, Esben Nielsen wrote:
On Tue, 10 Apr 2007, Jan Engelhardt wrote:
(Wow, not a single MODULE_AUTHOR line in drivers/net/arcnet/ ...)
ArcNet is old. Almost nobody is using it anymore. I used it at my
former job, since we used
No new data is needed until the first ACK comes, so no need to
check for application limitedness until then.
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
net/ipv4/tcp_input.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_input.c
This is a corner case where less than MSS sized new data thingie
is awaiting in the send queue. For F-RTO to work correctly, a
new data segment must be sent at certain point or F-RTO cannot
be used at all. RFC4138 allows overriding of Nagle at that
point.
Implementation uses frto_counter states 2
On Tue, 10 Apr 2007, Samuel Ortiz wrote:
The patch below schedules irnet_flow_indication() asynchronously. Could
you please give it a try (it builds, but I couldn't test it...) ? :
I'm afraid, your patch makes it worse - with my patch to ppp_generic it
worked 5 hours before Ir stopped,
Waskiewicz Jr, Peter P [EMAIL PROTECTED] wrote:
True, but the assignment for dev above also casts this void * to
struct net_device *:
dev = (struct net_device *)
(((long)p + NETDEV_ALIGN_CONST) ~NETDEV_ALIGN_CONST);
dev-padded = (char *)dev - (char *)p;
On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
Same way as the current RTM_SETLINK message works, but with creating
a new link in advance. It works fine in other subsystems, so I don't
see why it would in this case as well. Some subsystems do it in an
atomic fashion (network
On Wed, 2007-04-11 at 17:56 +1000, Herbert Xu wrote:
Hi:
[NET]: Get rid of NETIF_F_INTERNAL_STATS
The recently added NETIF_F_INTERNAL_STATS isn't very useful. If the
device driver needs to set it then it can always override get_stats
instead. All existing drivers that have stats (which
On Wed, Apr 11, 2007 at 10:15:51PM +1000, Rusty Russell wrote:
Actually, I did this precisely because I really didn't want to start
exposing bogus stats in /proc/net/dev. An audit might clarify if this
is an actual issue.
Fair enough. Still returning zeros when get_stats isn't available
Rusty Russell wrote:
On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
Nope. Being async is critical for copyless networking:
- in the transmit path, so need to stop the sender (guest) from touching
the memory until it's on the wire. This means 100% of packets sent will
be blocked.
Hi Oscar
Isaula Oscar-QOI000 wrote:
I ran into a problem where LKSCTP is reporting a SCTM_COMM_UP indication
to the User application but is giving back a value of zero for the
assoc_id.
Attached are the SCTP debugs for the period in question.
A couple of things that I would like to note
Well, I found that with CentOS/Fedora/RHEL, I could use their standard
network-scripts to create VLAN devices.
I got VLAN devices running OK, but then ended up in the same boat as
before.
Also, it might be nice if keepalived/LVS had the option of entering a
VLAN device in keepalived.conf? (might
+ skb-queue_mapping =
+
q-prio2band[q-band2queue[bandTC_PRIO_MAX]];
Does this needs to be cleared at some point again? TC actions might
redirect or mirror packets to other (multiqueue) devices.
If an skb is redirected to another device,
Brice Goglin wrote:
Add the Intel 5000 southbridge (aka Intel 6310/6311/6321ESB) PCIe ports
and the Intel E30x0 chipsets to the whitelist of aligned PCIe completion.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c | 17 +
1 file changed, 17
Stephen Hemminger wrote:
Driver needs to turn off carrier when down, otherwise it can
confuse bonding and bridging and looks like carrier is on immediately
when it is brought back up.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- netdev-2.6.orig/drivers/net/skge.c 2007-04-07
[EMAIL PROTECTED] wrote:
From: Divy Le Ray [EMAIL PROTECTED]
Fix a deadlock when the interface s configured down and
the watchdog tack is sleeping on rtnl_lock.
Signed-off-by: Divy Le Ray [EMAIL PROTECTED]
---
drivers/net/cxgb3/cxgb3_main.c |4 +++-
1 files changed, 3 insertions(+), 1
Brice Goglin wrote:
Simpler way of dealing with the firmware 4KB boundary crossing
restriction for rx buffers. This fixes a variety of memory
corruption issues when using an uncommon MTU with a 16KB
page size.
Signed-off-by: Brice Goglin [EMAIL PROTECTED]
---
drivers/net/myri10ge/myri10ge.c |
Johannes Berg wrote:
On Tue, 2007-04-10 at 02:06 +0200, Patrick McHardy wrote:
Same way as the current RTM_SETLINK message works, but with creating
a new link in advance. It works fine in other subsystems, so I don't
see why it would in this case as well. Some subsystems do it in an
atomic
On Wed, 2007-04-11 at 18:15 +0200, Patrick McHardy wrote:
No, generic netlink avoids allocating netlink families.
Well, yes, I thought that was pretty much the point. :)
br_netlink
uses the same netlink family as the other network configuration stuff
(NETLINK_ROUTE), but a different
On Wed, 11 Apr 2007 02:37:01 -0700 [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8320
Summary: replacing route in kernel doesn't send netlink message
Kernel Version: 2.6.20.6
Status: NEW
Severity: low
Owner: [EMAIL
Johannes Berg wrote:
On Wed, 2007-04-11 at 18:15 +0200, Patrick McHardy wrote:
But you have a valid point, if we want to use
this for things like bonding or VLAN that aren't actually address
families, we should consider introducing rtnetlink families to
avoid adding AF_BONDING, AF_8021Q etc.
Thanks.
However, the PRIO qdisc still uses the priority in the bands for
dequeueing priority, and will feed the queues on the NIC.
The e1000, and any other multiqueue NIC, will schedule Tx
based on how
the PRIO qdisc feeds the queues. So the only priority here is the
dequeuing
On Wed, 2007-04-11 at 18:52 +0200, Patrick McHardy wrote:
I'm not sure I'm following. I was under the impression that the
conclusion of yesterdays discussion was that its probably not
worth using rtnetlink for wireless so it will continue to use
generic netlink exclusively, but even if that
Waskiewicz Jr, Peter P wrote:
Packets will only be dequeued from a band if the associated
subqueue is active, which moves the decision from prio to the
driver, no?
What policy does e1000 use for scheduling its internal queues?
E1000 is handed the skb's from PRIO to whichever queue the PRIO
On Wed, 11 Apr 2007 07:19:46 +0200
Patrick McHardy [EMAIL PROTECTED] wrote:
Stephen Hemminger wrote:
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index a260679..8a55276 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
if (unlikely(is_link_local(dest))) {
Andrew Morton wrote:
On Wed, 11 Apr 2007 02:37:01 -0700 [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8320
Summary: replacing route in kernel doesn't send netlink message
Kernel Version: 2.6.20.6
Status: NEW
Severity: low
Jeff Garzik wrote:
@@ -2526,6 +2530,18 @@
PCI_DEVICE_ID_SERVERWORKS_HT2100_PCIE_FIRST
bridge-device =
PCI_DEVICE_ID_SERVERWORKS_HT2100_PCIE_LAST)
+/* All Intel E3000/E3010 PCIE ports */
+|| (bridge-vendor ==
Back in May of last year, I reported this problem, but worked
around it at the time by changing the kernel memory settings
in the networking stack. I reproduced the problem again today
with the previously working kernel memory settings..which is not
supprising since I just papered over the bug
This is a note to let you know that we have just queued up the patch titled
Subject: 8139too: RTNL and flush_scheduled_work deadlock
to the 2.6.20-stable tree. Its filename is
8139too-rtnl-and-flush_scheduled_work-deadlock.patch
A git repo of this tree can be found at
This is a note to let you know that we have just queued up the patch titled
Subject: 8139too: RTNL and flush_scheduled_work deadlock
to the 2.6.20-stable tree. Its filename is
8139too-rtnl-and-flush_scheduled_work-deadlock.patch
A git repo of this tree can be found at
These patches build on the patchset labelled AF_RXRPC socket family and AFS
rewrite. The patches are also available for http download.
Firstly, the patches fix a number of bugs in AF_RXRPC:
http://people.redhat.com/~dhowells/rxrpc/09-af_rxrpc-own-workqueues.diff
Fix a deadlock in the give-up-callback aggregator dispatcher work item whereby
the aggregator runs on keventd as does timed autounmount, thus leading to the
unmount blocking keventd whilst waiting for keventd to run the aggregator when
the give-up-callback buffer is full.
Signed-Off-By: David
Make the AF_RXRPC module use its own workqueues with their own per-CPU threads.
Currently it uses keventd to do the following tasks, amongst others:
(*) Security negotiation
(*) Packet encryption and decryption
(*) Packet resending
(*) ACK, abort and busy packet generation
(*) Timeout
Make a couple of fixes to AF_RXRPC:
(1) The dead call timeout is shortened to 2 seconds. Without this, each
completed call sits around eating up resources for 10 seconds. The calls
need to hang around for a little while in case duplicate packets appear,
but 10 seconds is
Permit a key to be cached in the nameidata struct so that it only needs to be
looked up once when doing the sequence of d_revalidate(), permission(),
follow_link() and lookup() calls involved in a pathwalk.
This is used by the AFS filesystem to avoid repeatedly having to call
request_key(). Once
Handle multiple mounts of an AFS superblock correctly, checking to see whether
the superblock is already initialised after calling sget() rather than just
unconditionally stamping all over it.
Also delete the silent parameter to afs_fill_super() as it's not used and
can, in any case, be obtained
Make two changes to the AF_RXRPC key handling to make it easier for AFS to
use:
(1) Export key_type_rxrpc so that AFS can request keys of this type.
(2) Make it possible to have keys that represent no security. These are
created by instantiating the keys with no data.
Signed-Off-By:
Correctly alter the relocation state after update is complete by switching it
from Updating to Valid.
Also display the record state in the vlocation database proc file.
Signed-Off-By: David Howells [EMAIL PROTECTED]
---
fs/afs/proc.c | 15 +--
fs/afs/vlocation.c |4 +++-
On Wed, Apr 11, 2007 at 08:10:37PM +0100, David Howells wrote:
Add security support to the AFS filesystem. Kerberos IV tickets are
added as RxRPC keys are added to the session keyring with the klog
program. open() and other VFS operations then find this ticket with
request_key() and either
J. Bruce Fields [EMAIL PROTECTED] wrote:
Just curious--when is the actual crypto done? There doesn't seem to be
any in this patch.
See AF_RXRPC patch:
http://people.redhat.com/~dhowells/rxrpc/04-af_rxrpc.diff
You turn on CONFIG_RXKAD and load the rxkad module thus built (assuming
On Wed, Apr 11, 2007 at 09:10:32PM +0100, David Howells wrote:
J. Bruce Fields [EMAIL PROTECTED] wrote:
Just curious--when is the actual crypto done? There doesn't seem to be
any in this patch.
See AF_RXRPC patch:
http://people.redhat.com/~dhowells/rxrpc/04-af_rxrpc.diff
You
Ben Greear wrote:
Back in May of last year, I reported this problem, but worked
around it at the time by changing the kernel memory settings
in the networking stack. I reproduced the problem again today
with the previously working kernel memory settings..which is not
supprising since I just
From: Ben Greear [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 11:50:18 -0700
So, I would like to dig into this problem myself since no one else
is reporting this type of problem, but I am quite ignorant of the TCP
stack implementation. Based on the dup-acks I see on the wire, I assume
the TCP
From: Ben Greear [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 13:26:36 -0700
Interestingly, I found this page mentioning a SACK problem in Linux:
http://www-didc.lbl.gov/TCP-tuning/linux.html
Don't read that page, it is the last place in the world your should
take hints and advice from, most of
David Miller wrote:
From: Ben Greear [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 13:26:36 -0700
Interestingly, I found this page mentioning a SACK problem in Linux:
http://www-didc.lbl.gov/TCP-tuning/linux.html
Don't read that page, it is the last place in the world your should
take hints and
From: Ben Greear [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 14:06:31 -0700
Does the CWND == 1 count as solid? Any idea how/why this would go
to 1 in conjunction with the dup acks?
For the dup acks, I see nothing *but* dup acks on the wire...going in
both directions interestingly, at greater
David Miller wrote:
From: Ben Greear [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 14:06:31 -0700
Does the CWND == 1 count as solid? Any idea how/why this would go
to 1 in conjunction with the dup acks?
For the dup acks, I see nothing *but* dup acks on the wire...going in
both directions
On Wed, 11 Apr 2007 03:01:58 +0200
Lennert Buytenhek [EMAIL PROTECTED] wrote:
On Tue, Apr 10, 2007 at 04:57:23PM -0500, Kim Phillips wrote:
also adds RX TX delay bits to help boards with clock skew
problems.
snip
[...]
+
+ temp |= (MII_M_RX_DELAY |
From: Ben Greear [EMAIL PROTECTED]
Date: Wed, 11 Apr 2007 14:31:00 -0700
I've spent solid weeks tracking down obscure races.
I've spent solid weeks tracking down kernel stack corruption and scsi
problems on sparc64, as well as attending to my network maintainer
duties, what is your point?
I'm
On Wed, 11 Apr 2007 03:03:56 +0200
Lennert Buytenhek [EMAIL PROTECTED] wrote:
On Tue, Apr 10, 2007 at 05:20:52PM -0500, Kim Phillips wrote:
(note I'm coming from an embedded world here.)
Please read this:
http://marc.info/?l=linux-netdevm=116527863300952w=2
Not sure how to
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.21.orig/drivers/net/sky2.c 2007-04-11 14:41:09.0 -0700
+++ sky2-2.6.21/drivers/net/sky2.c 2007-04-11 14:44:24.0 -0700
@@ -49,7 +49,7 @@
#include sky2.h
#define DRV_NAME sky2
-#define DRV_VERSION
This device is having all sorts of problems that lead to data corruption
and system instability. It gets receive status and data out of order,
it generates descriptor and TSO errors, etc.
Until the problems are resolved, it should not be used by anyone
who cares about there system.
These address issues found testing EC-U (88E8056 and 88E8055) chips.
--
Stephen Hemminger [EMAIL PROTECTED]
-
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
Need to make sure and disable ASF on all chip types. Otherwise, there may be
random reboots.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.c | 18 --
1 files changed, 8 insertions(+), 10 deletions(-)
--- sky2-2.6.21.orig/drivers/net/sky2.c 2007-04-11
The Yukon FE (100mbit only) chips do not support large packets.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-2.6.21.orig/drivers/net/sky2.c 2007-04-11 14:40:42.0 -0700
+++ sky2-2.6.21/drivers/net/sky2.c 2007-04-11 14:41:09.0 -0700
@@ -1899,6 +1899,9 @@ static
There should never be descriptor error unless hardware or driver is buggy.
But if an error occurs, print useful information, clear irq, and recover.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.c | 67
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger [EMAIL PROTECTED]
Driver needs to turn off carrier when down, otherwise it can
confuse bonding and bridging and looks like carrier is on immediately
when it is brought back up.
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger [EMAIL PROTECTED]
Driver needs to turn off carrier when down.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger [EMAIL PROTECTED]
Some of these chips are disabled until clock is enabled.
This fixes:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404107
Signed-off-by: Stephen
-stable review patch. If anyone has any objections, please let us know.
--
From: Stephen Hemminger [EMAIL PROTECTED]
The workaround Yukon EC-U wasn't comparing with correct
version and wasn't doing correct setup. Without it, 88e8056
throws all sorts of errors.
Signed-off-by:
On Wed, 2007-04-11 at 17:28 +0300, Avi Kivity wrote:
Rusty Russell wrote:
On Wed, 2007-04-11 at 07:26 +0300, Avi Kivity wrote:
Nope. Being async is critical for copyless networking:
With async operations, the saga continues like this: the host-side
driver allocates an skb,
On Wed, Apr 11, 2007 at 04:36:49PM -0500, Kim Phillips wrote:
On Tue, Apr 10, 2007 at 04:57:23PM -0500, Kim Phillips wrote:
also adds RX TX delay bits to help boards with clock skew
problems.
snip
[...]
+
+ temp |= (MII_M_RX_DELAY | MII_M_TX_DELAY);
On Wed, Apr 11, 2007 at 02:06:31PM -0700, Ben Greear wrote:
For the dup acks, I see nothing *but* dup acks on the wire...going in
both directions interestingly, at greater than 100,000 packets per second.
I don't mind adding printks...and I've started reading through the code,
but there is a
On Wed, 2007-04-11 at 19:03 +0200, Patrick McHardy wrote:
You bring up a good point, it would be good to hear the opinion from
one of the wireless people on this since they have their own
multiqueue scheduler in the wireless-dev tree.
The one in the wireless-dev is pretty much like this
Bartek wrote:
Hopefully, this time it my bug report should be ok :):
Apr 11 23:53:38 localhost pppd[31289]: rcvd [proto=0x7689] e1 cd 33 f6
fd f7 52 e6 58 c9 73 98 bc ff ad d5 b5 a3 e5 d9 1e 77 76 0a 1c 87 59
bf 44 cc ac 3b ...
Apr 11 23:53:38 localhost pppd[31289]: Unsupported protocol
74 matches
Mail list logo
