I've recently been noticing nasty messages come out of FC5:
sony:/home/akpm# service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter[ OK ]
Unloading iptables modules:[
On Thu, Feb 15, 2007 at 02:45:07AM -0800, Andrew Morton wrote:
I've recently been noticing nasty messages come out of FC5:
sony:/home/akpm# service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: filter
On Thu, 15 Feb 2007 06:20:22 -0500 Dave Jones [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2007 at 02:45:07AM -0800, Andrew Morton wrote:
I've recently been noticing nasty messages come out of FC5:
sony:/home/akpm# service iptables stop
Flushing firewall rules:
On Thu, 2007-02-15 at 04:10 -0800, Andrew Morton wrote:
On Thu, 15 Feb 2007 06:20:22 -0500 Dave Jones [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2007 at 02:45:07AM -0800, Andrew Morton wrote:
I've recently been noticing nasty messages come out of FC5:
sony:/home/akpm# service
Hi,
While experimenting with netem and tbf, I ran into some strange results.
Experimental setup:
tc qdisc add dev eth2 root netem delay 10ms
Linux 2.6.20-rc6 ; HZ=250
I measured the latency using a modified ping implementation, to allow
for high frequency measurement (one measure every 0.1ms).
It was hardly necessary to repeat most of the code from gfar_error() in
gfar_interrupt(), especially having some inconsistencies between the two.
So, make the gfar_interrupt() just call gfar_error(), and not acknowledge
the interrupts itself as gfar_{receive/transmit/error}() do it anyway.
While
Andrew Morton wrote:
On Wed, 7 Feb 2007 09:18:30 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote:
Document planned removal of sk98lin driver.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
Documentation/feature-removal-schedule.txt |7 +++
1 files changed, 7 insertions(+), 0
Second, the probe and remove functions do not communicate whether an add
or remove was successful. Combine this with the lack of port
information in the adapter sysfs directory, and the userspace tool has
no way of verifying a dynamic add/remove.
One way to communicate a return code is by
Hi Steven,
I have problems using sky2 v1.10 with with bonding driver (802.3ad),
on 'Marvell 88E8053 PCI-E Gigabit Ethernet Controller'. I have attached
the full lspci output.
My test was to setup a bond of two physical links (both links same
hardware) and ping 192.168.11.10, which is the
Francois Romieu wrote:
Ben Greear [EMAIL PROTECTED] :
[...]
I seem to be able to trigger this within about 1 minute on a
particular 2.6.18.2 system with some 8139too devices, so if someone
has a patch that could be tested, I'll gladly test it. For
whatever reason, I haven't hit this problem on
I used both use_carrier=1 (default) as well as miimon=50 without luck.
use_carrier should work (since device reports carrier transistions).
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
Holger Eitzenberger [EMAIL PROTECTED] wrote:
I have tested v1.10 with kernel 2.6.19 and 2.6.16.36 (own backport),
which despite the bonding problem runs fine. Both, kernel 2.6.19 and
2.6.16.36 show the same behaviour. The 802.3ad aware switch is a Dell
PowerConnect 5324. VLAN is not configured
Stephen Hemminger [EMAIL PROTECTED] writes:
I used both use_carrier=1 (default) as well as miimon=50 without luck.
use_carrier should work (since device reports carrier transistions).
As you can see in the script I used both use_carrier and miimon (in
combinations) without success. In fact
On Tue, Feb 13, 2007 at 06:11:15PM -0800, Jay Vosburgh wrote:
Andy Gospodarek [EMAIL PROTECTED] wrote:
This is exactly the problem I've got, Jay. I'd love to come up with
something that will be a smaller patch to solve this in the near term
and then focus on a larger set of changes down the
Hi,
I got the following message:
Class: Hardware failure
Nr: 0x270
Msg: 2 Pair Downshift detected
It is from the sk98lin driver and my research indicated that it may be
caused by bad Ethernet cable. The gigabit port is now became 100Mbps.
My questions are:
1. What
Jay Vosburgh [EMAIL PROTECTED] writes:
I'm unfamiliar with your particular switch, but usually this
kind of problem with bonding 802.3ad is in the switch interaction. The
switches I have (Cisco) require that 802.3ad mode be explicitly enabled
on whichever ports it is desired on, so it
On Thu, Feb 15, 2007 at 07:55:42PM +0100, Holger Eitzenberger wrote:
Hi Steven,
I have problems using sky2 v1.10 with with bonding driver (802.3ad),
on 'Marvell 88E8053 PCI-E Gigabit Ethernet Controller'. I have attached
the full lspci output.
My test was to setup a bond of two physical
On Thu, 15 Feb 2007 12:49:26 -0800
Tony Chung [EMAIL PROTECTED] wrote:
Hi,
I got the following message:
Class: Hardware failure
Nr: 0x270
Msg: 2 Pair Downshift detected
It is from the sk98lin driver and my research indicated that it may be
caused by bad
On Thu, Feb 15, 2007 at 10:09:40PM +0100, Holger Eitzenberger wrote:
Jay Vosburgh [EMAIL PROTECTED] writes:
I'm unfamiliar with your particular switch, but usually this
kind of problem with bonding 802.3ad is in the switch interaction. The
switches I have (Cisco) require that 802.3ad
On Thu, Feb 15, 2007 at 04:31:36PM -0500, Andy Gospodarek wrote:
On Thu, Feb 15, 2007 at 07:55:42PM +0100, Holger Eitzenberger wrote:
Hi Steven,
I have problems using sky2 v1.10 with with bonding driver (802.3ad),
on 'Marvell 88E8053 PCI-E Gigabit Ethernet Controller'. I have attached
Andy Gospodarek [EMAIL PROTECTED] writes:
I get the impression that sky2 has never worked for you. Is that
correct? There was an skge problem I noticed a while ago where on reset
the multicast membership list was cleared.
Well, when it comes to bonding: yes, almost :). When I noticed the
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
drivers/net/sis190.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/sis190.c b/drivers/net/sis190.c
index 45d91b1..b08508b 100644
--- a/drivers/net/sis190.c
+++ b/drivers/net/sis190.c
@@ -909,6 +909,9
flush_scheduled_work() in net_device-close has a slight tendency
to deadlock with tasks on the workqueue that hold RTNL.
rtl8169_close/down simply need the recovery tasks to not meddle
with the hardware while the device is going down.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
Mantra: don't use flush_scheduled_work with RTNL held.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
drivers/net/s2io.c | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index e8e0d94..fd85648 100644
---
Your usual dont-flush_scheduled_work-with-RTNL-held stuff.
It is a bit different here since the thread runs permanently
or is only occasionally kicked for recovery depending on the
hardware revision.
Signed-off-by: Francois Romieu [EMAIL PROTECTED]
---
drivers/net/8139too.c | 40
I have encountered a strange behaviour with the pcnet32.
I am transfering data from a server to a client routing it through my
router. The router has 2 ethernet ports, both of which are amd 972
chips (pcnet32). The transfer has so far been either http or ftp (both
see the same problem). I
Andy Gospodarek [EMAIL PROTECTED] wrote:
[...]
That might be the case, but I feel like the code is in a place where it
*could* work tomorrow with just some small tweaks (getting everything
into process context). I'm reluctant to cram a whole bunch of changes
down someone's throat immediately
Einar Lueck's email addresses bounce
[EMAIL PROTECTED][EMAIL PROTECTED]
Removed local random number generator function
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/net/ipv4/multipath_random.c b/net/ipv4/multipath_random.c
index b8c289f..6448e6c 100644
---
Someone want to take a stab at fixing this??
Begin forwarded message:
Date: Wed, 14 Feb 2007 19:32:52 -0800
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bug 8013] New: select for write hangs on a socket after write
returned ECONNRESET
http://bugzilla.kernel.org/show_bug.cgi?id=8013
This set of patches fixes all the problems observed so far on
my machines. The biggest one was not doing transmit flow control
correctly.
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More
Don't mark pause frames as errors. This problem caused transmitter not
to pause and would effectively take out a gigabit switch because the
it can't handle overrun.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
drivers/net/sky2.h |2 +-
1 file changed, 1 insertion(+), 1
The Yukon-FE chip doesn't do gigabit and has a differen PHY internally.
On this chip, phy status register doesn't properly reflect the result
of flow control negotiation. To workaround the problem and avoid having
to have so much chip dependent code; compute the result of flow control
by looking
Resetting the pause bits on shutdown is not necessary.
The code was inherited from the vendor driver, and it is currently #ifdef'd
out there as well.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-dev.orig/drivers/net/sky2.c2007-02-13 15:08:31.0 -0800
+++
New version.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-dev.orig/drivers/net/sky2.c2007-02-15 15:00:38.0 -0800
+++ sky2-dev/drivers/net/sky2.c 2007-02-15 15:00:56.0 -0800
@@ -49,7 +49,7 @@
#include sky2.h
#define DRV_NAME sky2
-#define
The transmit timeout code could hang, and it would not clear out
problems if the hardware was stuck. Change the code to effectively do
a device down/up similar to the suspend/resume code.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-dev.orig/drivers/net/sky2.c2007-02-15
Don't drop oversize frame it might be a VLAN (untagged).
Use different counter for fifo overrun vs fifo error.
Print error on fifo overrrun.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-dev.orig/drivers/net/sky2.c2007-02-15 14:33:52.0 -0800
+++
On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
It's likely that old cards still work with v4 firmware,
No, it's absolutely impossible. Rev 2/4 cores have a
On Thursday 15 February 2007 16:07, Johannes Berg wrote:
On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
It's likely that old cards still work with v4 firmware,
On Thu, 2007-02-15 at 16:13 +0100, Michael Buesch wrote:
On Thursday 15 February 2007 16:07, Johannes Berg wrote:
On Wed, 2007-02-14 at 22:40 +0100, Michael Buesch wrote:
On Wednesday 14 February 2007 14:18, Johannes Berg wrote:
On Sat, 2007-02-10 at 06:55 +0100, Michael Buesch wrote:
On Thu, 2007-02-15 at 17:51 +0100, Martin Langer wrote:
Yep. We have all kinds of firmware with the new instruction set. It's
only ucode2 (old instruction set) that's missing. But the later ucode4
which also uses the old instruction set is available in v4.
OTOH, ucode13 isn't available in
remove local random function, use random32() instead
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/drivers/net/hamradio/baycom_epp.c
b/drivers/net/hamradio/baycom_epp.c
index 153b6dc..84aa211 100644
--- a/drivers/net/hamradio/baycom_epp.c
+++ b/drivers/net/hamradio/baycom_epp.c
@@
On Feb 15, 2007, at 07:56, Sergei Shtylyov wrote:
It was hardly necessary to repeat most of the code from gfar_error
() in
gfar_interrupt(), especially having some inconsistencies between
the two.
So, make the gfar_interrupt() just call gfar_error(), and not
acknowledge
the interrupts
Hi all,
I have been comparing bridging performance for 2.6.20 and 2.6.19
kernels. The kenel configurations are identical for both the kernels.
I use D-Link cards (8139too driver) for the Malta 4Kc board.
The setup is:
netperf client --- malta 4Kc - netperf server.
The
Fixes an oops in the non-blocking mode.
Signed-off-by: Max Krasnyansky [EMAIL PROTECTED]
---
net/tipc/socket.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 2a6a5a6..767f791 100644
--- a/net/tipc/socket.c
+++
TIPC code is a bit inconsistent in masking out upper bits of various
message fields when packing them into the headers. For the most part
things seem to be ok but we happened to hit a corner case in our labs
when broadcast counter reached certain value (don't remember exact
details) and was
On 14-02-2007 22:27, Stephen Hemminger wrote:
Ben found this but the problem seems pretty widespread.
The following places are subject to deadlock between flush_scheduled_work
and the RTNL mutex. What can happen is that a work queue routine (like
bridge port_carrier_check) is waiting forever
Jarek Poplawski wrote:
On 14-02-2007 22:27, Stephen Hemminger wrote:
Ben found this but the problem seems pretty widespread.
The following places are subject to deadlock between flush_scheduled_work
and the RTNL mutex. What can happen is that a work queue routine (like
bridge
On 15-02-2007 23:37, Francois Romieu wrote:
Your usual dont-flush_scheduled_work-with-RTNL-held stuff.
It is a bit different here since the thread runs permanently
or is only occasionally kicked for recovery depending on the
hardware revision.
Signed-off-by: Francois Romieu [EMAIL
Fix copyrights in the cxgb3 driver.
Remove the Open Grid Computing copyright. It shouldn't be there.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/net/cxgb3/cxgb3_defs.h|1 -
drivers/net/cxgb3/cxgb3_offload.c |1 -
drivers/net/cxgb3/cxgb3_offload.h |1 -
Koushik, Raju,
Please review, comment, and if you find this acceptable,
please forward upstream. This patch incorporates all of
fixes resulting from the last set of discussions, circa
November 2006.
--linas
This patch adds PCI error recovery support to the
s2io 10-Gigabit ethernet device
From: Steve Wise [EMAIL PROTECTED]
Fail posts synchronously when in TERMINATE state.
For T3B devices, mark user qp in error once we transition
to TERMINATE.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_qp.c |2 ++
1 files changed, 2 insertions(+), 0
Fix copyrights in the iw_cxgb3 driver.
Remove the Open Grid Computing copyright. It shouldn't be there.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/cxio_dbg.c |1 -
drivers/infiniband/hw/cxgb3/cxio_hal.c |1 -
thanks, applied.
-
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
thanks, applied
-
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
The network device frontend driver allows the kernel to access network
devices exported exported by a virtual machine containing a physical
network device driver.
Signed-off-by: Ian Pratt [EMAIL PROTECTED]
Signed-off-by: Christian Limpach [EMAIL PROTECTED]
Signed-off-by: Chris Wright [EMAIL
55 matches
Mail list logo
