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
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 port_carrier_ch
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 for
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 messing
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
+++ b/net/tipc/s
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 throu
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 P
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
@@
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
+++ sky2-dev/drivers/net/s
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 11:4
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
+++ sky2-dev/drive
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
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 deletion(
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 at
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
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
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
--- a/net/ipv4/multipath_
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 immediatel
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 trans
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 dr
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
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
---
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]>
---
drive
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,
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
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 at
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
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 tha
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
> caus
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 phy
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 itse
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, s
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 is
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
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 f
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 confi
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 -
drivers/infiniband/hw/cxgb3/cxi
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 -
drivers/ne
> 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
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 o
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 address
> 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
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 i
On Thu, Feb 15, 2007 at 04:19:13PM +0100, Johannes Berg wrote:
> 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
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).
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
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
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
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
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:/ho
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 at
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, 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, 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
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:[
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(+),
57 matches
Mail list logo
