On Fri, 07 Sep 2007, Jay Vosburgh wrote:
> Rick Jones <[EMAIL PROTECTED]> wrote:
> [...]
> >> Note that this out of order delivery occurs when both the
> >> sending and receiving systems are utilizing a multiple
> >> interface bond. Consider a configuration in which a
> >>
On Thu, 2007-09-06 at 12:50 -0700, David Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Thu, 06 Sep 2007 12:05:30 -0700
>
> > The HT1000 bridge may very well have an MSI issue. I'm checking with
> > ServerWorks and I will do some testing to confirm. If confirmed, we can
> > dis
Rick Jones <[EMAIL PROTECTED]> wrote:
[...]
>> If bonding is the only feeder of the devices, then for a continuous
>> flow of traffic, all the slaves will generally receive packets (from
>> the kernel, for transmission) at pretty much the same rate, and so
>> they won't tend to get ahead or behind.
Auke Kok wrote:
This incorporates the new napi_struct changes into e1000e. Included
bugfix for ifdown hang from Krishna Kumar for e1000.
Disabling polling is no longer needed at init time, so remove
napi_disable() call from _probe().
david,
while testing this patch I noticed that the poll ro
This incorporates the new napi_struct changes into e1000e. Included
bugfix for ifdown hang from Krishna Kumar for e1000.
Disabling polling is no longer needed at init time, so remove
napi_disable() call from _probe().
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/e1000.h |
Luca wrote:
On 9/8/07, Chris Snook <[EMAIL PROTECTED]> wrote:
From: Chris Snook <[EMAIL PROTECTED]>
Make certain problematic optimizations build-time configurable.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
Acked-by: Jay Cliburn <[EMAIL PROTECTED]>
--- a/drivers/net/atl1/atl1_main.c
On 9/8/07, Chris Snook <[EMAIL PROTECTED]> wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Make certain problematic optimizations build-time configurable.
>
> Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
> Acked-by: Jay Cliburn <[EMAIL PROTECTED]>
>
> --- a/drivers/net/atl1/atl1_main.c 20
Jeff Garzik wrote:
Chris Snook wrote:
The atl1 driver is currently marked EXPERIMENTAL, because a few
supposedly performance-enhancing features still have problems. When
these features are disabled, the driver is completely stable, fully
functional, and performs well.
Patch 1/2 Creates the
Chris Snook wrote:
The atl1 driver is currently marked EXPERIMENTAL, because a few
supposedly performance-enhancing features still have problems. When
these features are disabled, the driver is completely stable, fully
functional, and performs well.
Patch 1/2 Creates the kconfig option CONFI
Jeff Garzik wrote:
Kok, Auke wrote:
Jeff Garzik wrote:
Kok, Auke wrote:
David Miller wrote:
From: Jiri Slaby <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 09:19:30 +0200
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e
driver.
napi_disable(&adapter->napi) in e1000_probe freeze
From: Chris Snook <[EMAIL PROTECTED]>
Make certain problematic optimizations build-time configurable.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
Acked-by: Jay Cliburn <[EMAIL PROTECTED]>
--- a/drivers/net/atl1/atl1_main.c 2007-09-04 10:12:38.0 -0400
+++ b/drivers/net/atl1/atl1_m
Kok, Auke wrote:
Jeff Garzik wrote:
Kok, Auke wrote:
David Miller wrote:
From: Jiri Slaby <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 09:19:30 +0200
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e
driver.
napi_disable(&adapter->napi) in e1000_probe freezes the kernel on
boo
Hi Mark,
[Adding netdev to CC]
On 07/09/2007, Mark Nipper <[EMAIL PROTECTED]> wrote:
> I've received two oopses now from my kernel while running
> the 2.6.22 series. The first was with 2.6.22.1 back in July and
> the second which happened just within the last day is 2.6.22.5.
> They both
That said, it's certainly plausible that, for a given set of N
ethernets all enslaved to a single bonding balance-rr, the individual
ethernets could get out of sync, as it were (e.g., one running a fuller
tx ring, and thus running "behind" the others).
That is the scenario of which I wa
From: Chris Snook <[EMAIL PROTECTED]>
Introduce Kconfig ATL1_EXPERIMENTAL to separate mature code from less mature
code in the atl1 driver, and remove EXPERIMENTAL designation for ATL1.
Signed-off-by: Chris Snook <[EMAIL PROTECTED]>
Acked-by: Jay Cliburn <[EMAIL PROTECTED]>
--- a/drivers/net/Kco
Reyk Floeter wrote:
I'm still waiting for an answer. Your process is taking too long.
Speaking as a person through which these changes flow upstream into the
official kernel (ath5k maintainers -> linville -> me -> linus)...
The most important thing for today is that no ath5k stuff has been
The atl1 driver is currently marked EXPERIMENTAL, because a few supposedly
performance-enhancing features still have problems. When these features are
disabled, the driver is completely stable, fully functional, and performs well.
Patch 1/2 Creates the kconfig option CONFIG_ATL1_EXPERIMENTAL,
Jeff Garzik wrote:
Kok, Auke wrote:
David Miller wrote:
From: Jiri Slaby <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 09:19:30 +0200
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e
driver.
napi_disable(&adapter->napi) in e1000_probe freezes the kernel on boot.
Yes, the seman
Kok, Auke wrote:
David Miller wrote:
From: Jiri Slaby <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 09:19:30 +0200
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e
driver.
napi_disable(&adapter->napi) in e1000_probe freezes the kernel on boot.
Yes, the semantics changed slight
Rick Jones <[EMAIL PROTECTED]> wrote:
[...]
>> Note that this out of order delivery occurs when both the
>> sending and receiving systems are utilizing a multiple
>> interface bond. Consider a configuration in which a
>> balance-rr bond feeds into a single higher ca
David Acker wrote:
Let me know if there is any other information I can provide you. I will
look through the code to see what could be going on with your machine.
I will also look into reproducing these results with a newer kernel.
This may be tricky since compulab's patches are pretty stale
Just so I understand you correctly,
1) IP100A support requires modified sundance.c
2) IP1000A support requires new driver
Is this correct?
If so, please resend the IP1000A driver, I don't have it in my email.
Jeff
-
To unsubscribe from this list: send the line "unsu
Micah Gruber wrote:
This patch fixes a potential null dereference bug where we dereference dev
before a null check. This patch simply moves the dereferencing after the null
check.
Signed-off-by: Micah Gruber <[EMAIL PROTECTED]>
---
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli
Matteo Croce wrote:
Il Friday 07 September 2007 00:30:25 Andrew Morton ha scritto:
On Thu, 6 Sep 2007 17:34:10 +0200 Matteo Croce <[EMAIL PROTECTED]> wrote:
Driver for the cpmac 100M ethernet driver.
It works fine disabling napi support, enabling it gives a kernel panic
when the first IPv6 packe
Updated the multiqueue.txt document to call out the correct kernel options
to select to enable multiqueue.
Signed-off-by: Peter P Waskiewicz Jr <[EMAIL PROTECTED]>
---
Documentation/networking/multiqueue.txt | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/Docume
David Miller wrote:
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Thu, 06 Sep 2007 11:31:47 -0700
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch.bz2
(git-am for
Some quick comments that got cut out of the original mail.
+
+/*
+ * map single buffer
+ */
+static int bnx2i_map_single_buf(struct bnx2i_hba *hba,
+ struct bnx2i_cmd *cmd)
+{
+ struct scsi_cmnd *sc = cmd->scsi_cmd;
+ struct iscsi_bd *bd = cmd->b
Anil Veerabhadrappa wrote:
+
+/* iSCSI stages */
+#define ISCSI_STAGE_SECURITY_NEGOTIATION (0)
+#define ISCSI_STAGE_LOGIN_OPERATIONAL_NEGOTIATION (1)
+#define ISCSI_STAGE_FULL_FEATURE_PHASE (3)
+/* Logout response codes */
+#define ISCSI_LOGOUT_RESPONSE_CONNECTION_CLOSED (0)
+#define ISCSI_LOGO
In gmane.linux.network, you wrote:
> But the CPU has done more work. The flood ping will always show
> increased CPU with these changes because the driver always stays in the
> NAPI poll list. For typical LAN traffic, the average CPU usage doesn't
> increase as much, though more measurements wou
I was perusing Documentation/networking/bonding.txt in a 2.6.23-rc5 tree
and came across the following discussing the round-robin scheduling:
Note that this out of order delivery occurs when both the
sending and receiving systems are utilizing a multiple
interface bond.
Kok, Auke wrote:
David Acker wrote:
Kok, Auke wrote:
first impressions are not good: pings are erratic and shoot up to 3
seconds. In an overnight stress test, the receive unit went offline and
never came back up (TX still working).
it sounds like something in the logic is suspending the ru t
David Acker wrote:
Kok, Auke wrote:
first impressions are not good: pings are erratic and shoot up to 3
seconds. In an overnight stress test, the receive unit went offline and
never came back up (TX still working).
it sounds like something in the logic is suspending the ru too much, but
I ha
Kok, Auke wrote:
first impressions are not good: pings are erratic and shoot up to 3
seconds. In an overnight stress test, the receive unit went offline and
never came back up (TX still working).
it sounds like something in the logic is suspending the ru too much, but
I haven't had time to lo
On Fri, 2007-09-07 at 18:01 +0200, Michael Buesch wrote:
> What's the problem with trying to lock it?
I think I had a problem with it once when I inserted it into some code
that was atomic and it all blew up badly ;) Nothing important really but
it sort of made me not like it much.
johannes
si
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
This all looks fine except for one nit (well, request for extra
detail, really):
>@@ -802,15 +802,20 @@ BROADCAST=192.168.1.255
> ONBOOT=yes
> BOOTPROTO=none
> USERCTL=no
>+BONDING_OPTS="mode=balance-alb miimon=100"
>
> Be sure to change th
Am Freitag, 7. September 2007 18:19 schrieben Sie:
> On Fri, Sep 07, 2007 at 05:49:55PM +0200, Wolfgang Walter wrote:
> > Hello,
> >
> > we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since
> > then we get the message
> >
> > lockd: too many open TCP sockets, consider increasing
On Wed, 2007-08-29 at 17:56 +0200, Erik Slagter wrote:
> Never mind, I plugged the adapter into a windows machine once more
> (another one) and now it acts exactly like it's plugged into my linux
> laptop, so I guess it's actually broken. I will send it back for repair.
>
> Thanks for your effort
The first issue, requires a large timeout, and
the TIME_WAIT timeout is currently 60 seconds on linux.
That timeout effectively limits the connection rate between
local TCP clients and a server to 32k/60s or around 500 connections/second.
Actually, it would be more like 60k/60s if the applicatio
Hi,
I originally reported this bug to the Debian BTS:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441232
There I was told to talk directly to upstream.
I am pasting the original bug report below. The referenced text files
can be found at the mentioned BTS URL.
Additionally, I have just trie
David Acker wrote:
On the systems that have cache incoherent DMA, including ARM, there is a
race condition between software allocating a new receive buffer and hardware
writing into a buffer. The two race on touching the last Receive Frame
Descriptor (RFD). It has its el-bit set and its next li
David Miller wrote:
From: Jiri Slaby <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 09:19:30 +0200
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e driver.
napi_disable(&adapter->napi) in e1000_probe freezes the kernel on boot.
Yes, the semantics changed slightly in the net-2.6.2
On Fri, Sep 07, 2007 at 05:49:55PM +0200, Wolfgang Walter wrote:
> Hello,
>
> we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since then
> we get the message
>
> lockd: too many open TCP sockets, consider increasing the number of nfsd
> threads
> lockd: last TCP connect from
Hi there!
Below is a fix for this:
http://bugzilla.kernel.org/show_bug.cgi?id=8876
Applies to any version since 2.6.22 to latest: 2.6.23-rc5-git1
please apply :)
-CUT-
diff -urN a/net/ipv4/devinet.c b/net/ipv4/devinet.c
--- a/net/ipv4/devinet.c
On Friday 07 September 2007, Johannes Berg wrote:
> On Thu, 2007-09-06 at 08:46 -0700, Paul E. McKenney wrote:
>
> > Looks good to me from an RCU viewpoint. I cannot claim familiarity with
> > this code. I therefore especially like the indications of where RTNL
> > is held and not!!!
>
> :)
>
Hello,
we upgraded the kernel of a nfs-server from 2.6.17.11 to 2.6.22.6. Since then
we get the message
lockd: too many open TCP sockets, consider increasing the number of nfsd threads
lockd: last TCP connect from ^\\236^\É^D
1) These random characters in the second line are caused by a bug in
Florian Lohoff noticed a bug in mac80211: when bringing the
master interface down while other virtual interfaces are up
we call dev_close() under a spinlock which is not allowed.
This patch removes the sub_if_lock used by mac80211 in favour
of using an RCU list. All list manipulations are already d
On Fri, 2007-09-07 at 07:25 -0700, Paul E. McKenney wrote:
> > > > @@ -226,22 +225,22 @@ void ieee80211_if_reinit(struct net_devi
> > > > /* Remove all virtual interfaces that use this BSS
> > > > * as their sdata->bss */
> > > > struct ieee80211_su
On Fri, 2007-09-07 at 07:25 -0700, Paul E. McKenney wrote:
> > I don't like ASSERT_RTNL() much because it actually tries to lock it.
> > I'd be much happer if it was WARN_ON(!mutex_locked(&rtnl_mutex)) or
> > something equivalent.
>
> Ah! It would indeed be nice to have a lower-overhead ASSERT_R
On Fri, Sep 07, 2007 at 03:27:15PM +0200, Johannes Berg wrote:
> On Thu, 2007-09-06 at 08:46 -0700, Paul E. McKenney wrote:
>
> > Looks good to me from an RCU viewpoint. I cannot claim familiarity with
> > this code. I therefore especially like the indications of where RTNL
> > is held and not!!
On Thu, 2007-09-06 at 08:46 -0700, Paul E. McKenney wrote:
> Looks good to me from an RCU viewpoint. I cannot claim familiarity with
> this code. I therefore especially like the indications of where RTNL
> is held and not!!!
:)
> Some questions below based on a quick scan. And a global questi
On Fri, 2007-07-09 at 10:31 +0100, James Chapman wrote:
> Not really. I used 3-year-old, single CPU x86 boxes with e100
> interfaces.
> The idle poll change keeps them in polled mode. Without idle
> poll, I get twice as many interrupts as packets, one for txdone and one
> for rx. NAPI is contin
From: Denis V. Lunev <[EMAIL PROTECTED]>
addrconf_dad_failure calls addrconf_dad_stop which takes referenced address
and drops the count. So, in6_ifa_put perrformed at out: is extra. This
results in message: "Freeing alive inet6 address" and not released dst entries.
Signed-off-by: Denis V. Lunev
Update last_rx in registered device struct instead of
in the dummy device.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/ehea/ehea_main.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
i
Introduces a module parameter to decide whether the physical
port link state is propagated to the network stack or not.
It makes sense not to take the physical port state into account
on machines with more logical partitions that communicate
with each other. This is always possible no matter what t
* Milan Kocian <[EMAIL PROTECTED]> 2007-09-06 23:05
> I agree but ipv6 sends on device change (NETDEV_DOWN) RTM_DELLINK message.
> BTW when ipv6 send LINK message on NETDEV_UNREGISTER event, why doesn't
> send message on NETDEV_REGISTER event? No symmetry ?
You should be seeing two RTM_DELLINK up
Hi Mandeep,
Mandeep Singh Baines wrote:
Hi James,
I like the idea of staying in poll longer.
My comments are similar to what Jamal and Stephen have already said.
A tunable (via sysfs) would be nice.
A timer might be preferred to jiffy polling. Jiffy polling will not increase
latency the way
Hi Stephen,
I saw that you developed most of the new NAPI interface.
I already addressed this issue a while ago. Please correct me if I got
it wrong. I think there is still a serious problem with the NAPI
changes to make NAPI polling independent of struct net_device objects.
Its about the question
As I see it, TIME_WAIT state is required for 2 reasons:
to handle wandering duplicate packets
(so a reincarnation of a connection will not be corrupted by these packets)
To handle last ack from active closer (client) not being received by remote.
If that happened, the server which is in L
jamal wrote:
On Thu, 2007-06-09 at 15:16 +0100, James Chapman wrote:
>> First, do we need to encourage consistency in NAPI poll drivers?
not to stiffle the discussion, but Stephen Hemminger is planning to
write a new howto; that would be a good time to bring up the topic. The
challenge is th
From: Jiri Slaby <[EMAIL PROTECTED]>
Date: Fri, 07 Sep 2007 09:19:30 +0200
> I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e driver.
> napi_disable(&adapter->napi) in e1000_probe freezes the kernel on boot.
Yes, the semantics changed slightly in the net-2.6.24 tree the
other wee
I'm trevelling otherwise I would have reviewed and integrated
or given feedback for changes.
I'll be back late next week.
-
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
Hi there,
I cannot get my AMD64 working with forcedeth network chip and Netkey.
While recompiling kernel to get iptables and OpenSWAN working, I cannot
anymore boot my computer, it freeze on network setup.
After some reboots / recompile, I've traced the problem arround NetKEY.
If I enable it in
Hi,
I found a regression in 2.6.23-rc4-mm1 (since -rc3-mm1) in e1000e driver.
napi_disable(&adapter->napi) in e1000_probe freezes the kernel on boot.
regards,
--
Jiri Slaby ([EMAIL PROTECTED])
Faculty of Informatics, Masaryk University
-
To unsubscribe from this list: send the line "unsubscribe
On Thu, 6 Sep 2007, Andrew Morton wrote:
> > On Thu, 6 Sep 2007 17:34:10 +0200 Matteo Croce <[EMAIL PROTECTED]> wrote:
> > Driver for the cpmac 100M ethernet driver.
> > It works fine disabling napi support, enabling it gives a kernel panic
> > when the first IPv6 packet has to be forwarded.
> > Ot
64 matches
Mail list logo
