On Thu, Aug 30, 2007 at 12:16:32AM +0400, [EMAIL PROTECTED] wrote:
> Quoting Jarek Poplawski <[EMAIL PROTECTED]>:
>
> >On Wed, Aug 29, 2007 at 04:53:52PM +0400, Badalian Vyacheslav wrote:
> >...
> >>we have this kernel panic (then delete HTB) at all 2.6.18-x versions.
> >>on older kernel (2.6.x) w
On Wed, 2007-08-29 at 16:47 -0700, Joe Perches wrote:
> On Wed, 2007-08-29 at 16:41 -0700, David Miller wrote:
> > From: Joe Perches <[EMAIL PROTECTED]>
> > Date: Wed, 29 Aug 2007 16:34:00 -0700
> >
> > > On Tue, 2007-08-28 at 17:59 -0700, David Miller wrote:
> > > > I pushed this fix into net-2.6
Vlad Yasevich wrote:
Wei Yongjun wrote:
Vlad Yasevich wrote:
NACK
Section 8.4:
An SCTP packet is called an "out of the blue" (OOTB) packet if it is
correctly formed (i.e., passed the receiver's CRC32c check; see
Section 6.8), but the receiver is not able to identify the
as
Hi Rick,
> > From: Rick Jones <[EMAIL PROTECTED]>
> >>The trace I've been sent shows clean RTTs ranging from ~200
milliseconds
> >>to ~7000 milliseconds.
> >
> >
> > Thanks for the info.
> >
> > It's pretty easy to generate examples where we might have some sockets
> > talking over interfaces on s
From: Divy Le Ray <[EMAIL PROTECTED]>
Load the engine microcode when an interface
is brought up, instead of of doing it when the module
is loaded.
Loosen up tight binding between the driver and the
engine microcode version.
There is no need for microcode update with T3A boards.
Fix the file na
From: Divy Le Ray <[EMAIL PROTECTED]>
cxgb3 used netdev_priv() and dev->priv for different purposes.
In 2.6.23, netdev_priv() == dev->priv, cxgb3 needs a fix.
This patch is a partial backport of Dave Miller's changes in the
net-2.6.24 git branch.
Without this fix, cxgb3 crashes on 2.6.23.
Sign
Jeff,
I'm resubmitting the cxgb3 dev->priv issue.
I'm also submitting a patch fixing the engine microcode loading.
The first patch changes in both cxgb3 and iw_cxgb3 related to
the dev->priv issue.
The second patch allows the driver to load the engine microcode
at the right time - when a port is
2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>:
> On Tue, Aug 28, 2007 at 11:58:52AM -0400, Jiri Slaby wrote:
> > -ath5k-objs = ath5k_base.o ath5k_hw.o ath5k_regdom.o
> > +ath5k-objs = ath5k_base.o ath5k_hw.o ath5k_regdom.o \
> > + ath5k_hw_phy.o ath5k_hw
2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>:
> On Tue, Aug 28, 2007 at 12:01:30PM -0400, Jiri Slaby wrote:
> > +config ATH5K_AR5210
> > + bool "Support AR5210"
> > + depends on ATH5K
> > + default y
> > +
> > +config ATH5K_AR5211
> > + bool "Support AR5211"
> > + depends on
On Wed, 2007-08-29 at 16:41 -0700, David Miller wrote:
> From: Joe Perches <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 16:34:00 -0700
>
> > On Tue, 2007-08-28 at 17:59 -0700, David Miller wrote:
> > > I pushed this fix into net-2.6.24 just now, thanks again.
> >
> > This tree doesn't compile for
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 16:06:27 -0700
I belive the biggest component comes from link-layer retransmissions.
There can also be some short outtages thanks to signal blocking,
tunnels, people with big hats and whatnot that the link-layer
r
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
The trace I've been sent shows clean RTTs ranging from ~200 milliseconds
to ~7000 milliseconds.
Thanks for the info.
It's pretty easy to generate examples where we might have some sockets
talking over interfaces on such a network and o
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 16:06:27 -0700
> I belive the biggest component comes from link-layer retransmissions.
> There can also be some short outtages thanks to signal blocking,
> tunnels, people with big hats and whatnot that the link-layer
> retransmissions
All of this seems to suggest that the RTO calculation is wrong.
That is a possiblity. Or at least could be enhanced.
It seems that packets in this network can be delayed several orders of
magnitude longer than the usual round trip as measured by TCP.
What exactly causes such a huge delay?
On Wed, Aug 29, 2007 at 03:35:03PM -0700, David Miller wrote:
> From: Rick Jones <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 15:29:03 -0700
>
> > David Miller wrote:
> > > None of the research folks want to commit to saying a lower value is
> > > OK, even though it's quite clear that on a local 1
Stephen Hemminger wrote:
On Wed, 29 Aug 2007 15:28:12 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
And reading NCR some more, we already have something similar in the
form of Alexey's reordering detection, in fact it handles exactly the
case NCR supposedly deals with. We do not trigger l
From: John Heffner <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 18:58:12 -0400
> I don't believe this was the case. NCR is substantially different, and
> came out of work at Texas A&M. The original (only) implementation was
> in Linux IIRC. Its goal was to do better. Their papers say it does.
John Heffner wrote:
What exactly causes such a huge delay? What is the TCP measured RTO
in these circumstances where spurious RTOs happen and a 3 second
minimum RTO makes things better?
I haven't done a lot of work on wireless myself, but my understanding is
that one of the biggest problems i
On Wed, 29 Aug 2007 15:28:12 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 15:13:01 -0700
>
> > There was some discussion about implementing TCP NCR (RFC4653)
> > and Narasimha Reddy said he might have something that cou
David Miller wrote:
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 15:29:03 -0700
David Miller wrote:
None of the research folks want to commit to saying a lower value is
OK, even though it's quite clear that on a local 10 gigabit link a
minimum value of even 200 is absolutely and
From: "Ian McDonald" <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 10:33:32 +1200
> Correct - they often have flaws in them, just like all documents. If
> that is the case we should try and get the RFCs fixed.
In many cases it is not the wording, but the actual concept or idea
the RFC itself is desc
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 15:29:03 -0700
> David Miller wrote:
> > None of the research folks want to commit to saying a lower value is
> > OK, even though it's quite clear that on a local 10 gigabit link a
> > minimum value of even 200 is absolutely and positivel
From what I've seen thusfar, the issue isn't so much actual loss, but
very variable RTTs leading to spurrious RTOs.
rick jones
-
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/majordom
On 8/30/07, David Miller <[EMAIL PROTECTED]> wrote:
> In fact this is a great example why we don't treat RFCs as dictations
> from the gods. They are often wrong, impractical, or full of fatal
> flaws.
>
Correct - they often have flaws in them, just like all documents. If
that is the case we shoul
David Miller wrote:
From: "Ian McDonald" <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 09:32:38 +1200
So I'm suspecting that the default should be changed to 1000 to match
the RFC which would solve this issue. I note that the RFC is a SHOULD
rather than a MUST. I had a quick look around and not s
On Tue, Aug 21, 2007 at 12:20:58AM -0700, David Miller wrote:
> From: Milan Kocian <[EMAIL PROTECTED]>
> Date: Wed, 15 Aug 2007 16:33:22 +0200
>
> > ipv6 sends a RTM_DELLINK netlink message on both events: NETDEV_DOWN,
> > NETDEV_UNREGISTER. Corrected by sending RTM_NEWLINK on NETDEV_DOWN event
>
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 15:13:01 -0700
> There was some discussion about implementing TCP NCR (RFC4653)
> and Narasimha Reddy said he might have something that could be used.
Although this looks interesting, I'm unsure it will help these
cell folks. Act
From: "Ian McDonald" <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 10:10:37 +1200
> Understand what you are saying. That is why I questioned as 200 msecs
> makes no sense on a LAN with < 1 msec RTT. So if the current is
> ridiculous and 1000 is even more so, why do we use? Just because that
> is how
From: Rick Jones <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 15:09:58 -0700
> If nothing else, 200 ms is a "principle of least surprise" thing since
> that is the current value (in MS) for TCP_RTO_MIN.
And Solaris and MacOS-X and...
In fact this is a great example why we don't treat RFCs as dict
On Wed, 29 Aug 2007 14:46:56 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: "Ian McDonald" <[EMAIL PROTECTED]>
> Date: Thu, 30 Aug 2007 09:32:38 +1200
>
> > So I'm suspecting that the default should be changed to 1000 to match
> > the RFC which would solve this issue. I note that the
I am sure you can use CTL_UNNUMBERED instead of adding yet another
sysctl value, as advised in include/linux/sysctl.h
** For new interfaces unless you really need a binary number
** please use CTL_UNNUMBERED.
fair enough. i was just repeating past behaviour :)
rick jones
-
To unsubscribe
On 8/30/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: "Ian McDonald" <[EMAIL PROTECTED]>
> Date: Thu, 30 Aug 2007 09:32:38 +1200
>
> > So I'm suspecting that the default should be changed to 1000 to match
> > the RFC which would solve this issue. I note that the RFC is a SHOULD
> > rather tha
Ian McDonald wrote:
Hmmm... RFC2988 says:
(2.4) Whenever RTO is computed, if it is less than 1 second then the
RTO SHOULD be rounded up to 1 second.
Traditionally, TCP implementations use coarse grain clocks to
measure the RTT and trigger the RTO, which imposes a la
On Wed, Aug 29, 2007 at 05:27:39PM +0200, Michal Piotrowski wrote:
> FS
>
> Subject : [NFSD OOPS] 2.6.23-rc1-git10
> References : http://lkml.org/lkml/2007/8/2/462
> Last known good : ?
> Submitter : Andrew Clayton <[EMAIL PROTECTED]>
> Caused-By : ?
> Handled-By : ?
Pavel Emelianov [EMAIL PROTECTED] wrote:
| The sync_master_pid and sync_backup_pid are set in set_sync_pid()
| and are used later for set/not-set checks and in printk. So it
| is safe to use the global pid value in this case.
|
| Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Acked-by: Sukade
From: "Ian McDonald" <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 09:32:38 +1200
> So I'm suspecting that the default should be changed to 1000 to match
> the RFC which would solve this issue. I note that the RFC is a SHOULD
> rather than a MUST. I had a quick look around and not sure why Linux
> ov
Pavel Emelianov [EMAIL PROTECTED] wrote:
| The pktgen_thread.pid is set to current->pid and is never used
| after this. So remove this at all.
|
| Found during isolating the explicit pid/tgid usage.
|
| Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Good observation that its not being used :
On 8/30/07, Rick Jones <[EMAIL PROTECTED]> wrote:
> Enable configuration of the minimum TCP Retransmission Timeout via
> a new sysctl "tcp_rto_min" to help those who's networks (eg cellular)
> have quite variable RTTs avoid spurrious RTOs.
>
> Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
> Signed-
Arnaldo Carvalho de Melo wrote:
Em Wed, Aug 29, 2007 at 11:23:16AM -0700, David Miller escreveu:
From: [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 18:41:14 +0200
When a socket is created it is sometime useful to store a specific information
for this socket.
This information can be for examples:
Rick Jones a écrit :
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl "tcp_rto_min" to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
Signed-off-by: Lamont Jones <[EMAIL PROTECTED
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl "tcp_rto_min" to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
Signed-off-by: Lamont Jones <[EMAIL PROTECTED]>
---
diff -r 1559df8
Quoting Jarek Poplawski <[EMAIL PROTECTED]>:
On Wed, Aug 29, 2007 at 04:53:52PM +0400, Badalian Vyacheslav wrote:
...
we have this kernel panic (then delete HTB) at all 2.6.18-x versions.
on older kernel (2.6.x) we have another panic (then delete tc filter)...
summary we have TC panics 1 year a
Avoid divide (modulus) in receive buffer handling path.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-29 11:41:23.0 -0700
+++ b/drivers/net/sky2.c2007-08-29 11:45:00.0 -0700
@@ -2140,7 +2140,8 @@ static struct sk_buff *sky2_r
Use the kernel interfaces for advanced error reporting.
This should be cleaner and clear up errors on boot.
For those systems with busted BIOS's that don't correctly
support mmconfig, advanced error reporting will be disabled.
The PCI registers for advanced error reporting start at 0x100 which
is
Add macro/function to subtract constant nanoseconds.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/include/linux/ktime.h 2007-08-29 11:31:59.0 -0700
+++ b/include/linux/ktime.h 2007-08-29 11:41:19.0 -0700
@@ -102,6 +102,13 @@ static inline ktime_t ktime_set(c
Add documentation of GPHY_CTRL register bits even if driver
is not using them (yet).
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.h2007-08-29 11:38:37.0 -0700
+++ b/drivers/net/sky2.h2007-08-29 11:40:12.0 -0700
@@ -1846,6 +1846,28 @@
Since ther is new functionality (timestamping), increase
the version.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-29 11:45:00.0 -0700
+++ b/drivers/net/sky2.c2007-08-29 11:46:25.0 -0700
@@ -53,7 +53,7 @@
#include "sky2.h"
Use the PCI layer config access functions. The driver was using the
memory mapped window in device, to workaround issues accessing the
advanced error reporting registers.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c | 91 +-
Need this in later sky2 code.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/lib/reciprocal_div.c 2007-06-25 09:03:23.0 -0700
+++ b/lib/reciprocal_div.c 2007-08-29 11:30:38.0 -0700
@@ -1,5 +1,6 @@
#include
#include
+#include
u32 reciprocal_value(u32
Use hardware timestamp counter to stamp receive packets.
It allows for higher resolution values without the hardware overhead
of doing gettimeofday.
Even though the network stack is smart enough to not stamp
packets unless needed, any installation with dhcpd ends up
using af_packet and that turn
Use debugfs rename to handle device neame changes.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-29 11:36:04.0 -0700
+++ b/drivers/net/sky2.c2007-08-29 11:40:09.0 -0700
@@ -3712,42 +3712,34 @@ static int sky2_device_event(stru
Take out the code that protects driver from accessing the
PCI config space.
We are old enough to run with scissors now.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |9 -
1 file changed, 9 deletions(-)
--- a/drivers/net/sky2.c2007-08-29 11:40:
This driver can just use the internal network stats block.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-29 11:41:10.0 -0700
+++ b/drivers/net/sky2.c2007-08-29 11:41:16.0 -0700
@@ -1606,8 +1606,8 @@ static void sky2_tx_comple
Add support for new Marvell 100mbit chips.
This code is ported from the SysKonnect 10.20.3.3 driver.
It is *untested* because I don't have access to this hardware.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-08-29 11:31:59.0 -0700
+++ b/driv
Moni Shoua <[EMAIL PROTECTED]> wrote:
>Jay Vosburgh wrote:
>> Moni Shoua <[EMAIL PROTECTED]> wrote:
>>
>>> When bonding enslaves non Ethernet devices it takes pointers to functions
>>> in the module that owns the slaves. In this case it becomes unsafe
>>> to keep the bonding master registered af
This version includes some new features:
* support for new FE+ chips (not tested)
* use PCI functions. The only reason the driver
wasn't doing it was the advanced error bits weren't
accessbile on busted AMD chipsets without MMCONFIG
access.
* use PCI error recovery functions to
On Wednesday 29 August 2007 21:33:43 Jon Smirl wrote:
> What if a patch spans both code that is pure GPL and code imported
> from BSD, how do you license it?
I think it's a valid assumption, if we say that the author
of the patch read the license header of a file and agreed with it.
So the patch i
> Aren't patches made against the kernel GPL'd if the author doesn't
> explicitly grant them more liberal BSD license in addition?
That would be the normal assumption.
> The problem then comes in taking the patches that were only made
> available against GPL code and reshipping them under the BSD
On 8/29/07, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > to remove the BSD/other license. Jiri can release *his* code as GPLv2
> > > only, but I suspect the files as a whole really should be dual BSD/GPLv2,
> > > due to the numerous other stakeholders in those files.
> >
> > This mess has been occur
Em Wed, Aug 29, 2007 at 11:23:16AM -0700, David Miller escreveu:
> From: [EMAIL PROTECTED]
> Date: Wed, 29 Aug 2007 18:41:14 +0200
>
> > When a socket is created it is sometime useful to store a specific
> > information
> > for this socket.
> >
> > This information can be for examples:
> >
From: [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 18:41:14 +0200
> When a socket is created it is sometime useful to store a specific information
> for this socket.
>
> This information can be for examples:
> * a creation time
> * a pid
> * a uid/gid
> * a container identif
> > to remove the BSD/other license. Jiri can release *his* code as GPLv2
> > only, but I suspect the files as a whole really should be dual BSD/GPLv2,
> > due to the numerous other stakeholders in those files.
>
> This mess has been occurring in the kernel for years. The DRM graphics
> drivers
From: OBATA Noboru <[EMAIL PROTECTED]>
Date: Wed, 29 Aug 2007 21:26:13 +0900 (JST)
> From: David Miller <[EMAIL PROTECTED]>
> Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
> Date: Tue, 28 Aug 2007 13:30:57 -0700 (PDT)
>
> > From: OBATA Noboru <[EMAIL PROTECTED]>
> > Date:
On Wed, Aug 29, 2007 at 06:41:15PM +0200, [EMAIL PROTECTED] wrote:
> From: Daniel Lezcano <[EMAIL PROTECTED]>
>
> Store private information for a socket
>
> This patch adds a field to the common socket structure. This field
> is a anonymous pointer which allow to store an information about
> the
On 8/29/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> The heck with "good idea" - it's unclear to me if Jiri is even *allowed*
> to remove the BSD/other license. Jiri can release *his* code as GPLv2
> only, but I suspect the files as a whole really should be dual BSD/GPLv2,
> due to the nume
Roland Dreier wrote:
Looks OK to me but I would just roll up the second patch into the
first patch and let Jeff merge it as one commit. There's no point in
creating an intermediate tree that doesn't build -- it just breaks git
bisect for no useful purpose.
Okay, Jeff agrees too, I'll do so.
On Wednesday 29 August 2007 00:54:19 David Miller wrote:
> From: Michael Buesch <[EMAIL PROTECTED]>
> Date: Tue, 28 Aug 2007 16:48:44 +0200
>
> > On Monday 27 August 2007 23:11:50 David Miller wrote:
> > > From: Joe Perches <[EMAIL PROTECTED]>
> > > Date: Mon, 27 Aug 2007 13:57:42 -0700
> > >
> >
On Tue, 28 Aug 2007 18:11:55 BST, Christoph Hellwig said:
> On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
> > ath5k, license is GPLv2
> >
> > The files are available only under GPLv2 since now.
>
> Is this really a good idea? Most of the reverse-engineering was
> done by the OpenBS
On 8/29/07, jamal <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
>
> > I interpret this to mean that the interrupt gets generates after a packet
> > is transferred to the TFIFO on the NIC and the next packet in the ring is
> > NULL.
>
> iow, when tx tran
When a socket is created it is sometime useful to store a specific information
for this socket.
This information can be for examples:
* a creation time
* a pid
* a uid/gid
* a container identifier
* a pointer to a more specific structure
* ...
The
From: Daniel Lezcano <[EMAIL PROTECTED]>
Store private information for a socket
This patch adds a field to the common socket structure. This field
is a anonymous pointer which allow to store an information about
the socket
Signed-off-by: Daniel Lezcano <[EMAIL PROTECTED]>
---
include/net/inet_
> From: Krishna Kumar2 <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 10:43:23 +0530
>
> > The reason was to run parallel copies, not for buffer limitations.
>
> Oh, I see.
>
> I'll note in passing that current lmbench-3 has some
> parallelization features you could play with, you might want
> t
jamal writes:
> On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
> I think its a good thing pktgen caught this; i am unsure however if it
> is doing the right thing. Hoping Robert would respond.
> One thing pktgen could do is restrict the amount of outstanding buffers
> by usin
On 8/29/07, Mandeep Baines <[EMAIL PROTECTED]> wrote:
...
> Unfortunately, the TxIdle interrupt would not free the last odd packet.
> However, if we want to quiet interrupts couldn't the driver just be
> converted NAPI. If this seems reasonable I could work on a patch.
It seems reasonable and that
Am Mittwoch, 29. August 2007 schrieb James Chapman:
> Can you provide more information about the problem, please? Are you
> using a simple DSL modem with PPPoE, such that the ppp0 interface is
> that of the pppd started by a local PPPoE server? Is this a problem only
> with packet capture or ar
OBATA Noboru wrote:
What about another option to let TCP have a notification?
Can it be a solution if it is standardized?
It would at best be a partial solution which would only work when the
link failover/whatnot happened on the same system/node as the TCP
endpoint. Then it can be some sor
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 and I apologise for being a pain ;-)
-
To unsubscribe from this l
Hi all,
Here is a list of some known regressions in 2.6.23-rc4
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk9
Hi all,
Here is a list of some known regressions in 2.6.23-rc4.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk9
Andi Kleen
Wei Yongjun wrote:
> Vlad Yasevich wrote:
>>
>> NACK
>>
>> Section 8.4:
>>
>>An SCTP packet is called an "out of the blue" (OOTB) packet if it is
>>correctly formed (i.e., passed the receiver's CRC32c check; see
>>Section 6.8), but the receiver is not able to identify the
>>associat
Jay Vosburgh wrote:
> Moni Shoua <[EMAIL PROTECTED]> wrote:
>
>> When bonding enslaves non Ethernet devices it takes pointers to functions
>> in the module that owns the slaves. In this case it becomes unsafe
>> to keep the bonding master registered after last slave was unenslaved
>> because we
On Tue, 2007-28-08 at 21:43 -0700, Mandeep Singh Baines wrote:
> I interpret this to mean that the interrupt gets generates after a packet
> is transferred to the TFIFO on the NIC and the next packet in the ring is
> NULL.
iow, when tx transits to idle ..
> This interrupt gets generates less of
Jay Vosburgh wrote:
> Moni Shoua <[EMAIL PROTECTED]> wrote:
>
>> bonding sometimes uses Ethernet constants (such as MTU and address length)
>> which
>> are not good when it enslaves non Ethernet devices (such as InfiniBand).
>>
>> Signed-off-by: Moni Shoua <[EMAIL PROTECTED]>
>> ---
>> drivers/ne
The sync_master_pid and sync_backup_pid are set in set_sync_pid()
and are used later for set/not-set checks and in printk. So it
is safe to use the global pid value in this case.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/ipv4/ipvs/ip_vs_sync.c b/net/ipv4/ipvs/ip_vs
On Wed, Aug 29, 2007 at 04:53:52PM +0400, Badalian Vyacheslav wrote:
...
> we have this kernel panic (then delete HTB) at all 2.6.18-x versions.
> on older kernel (2.6.x) we have another panic (then delete tc filter)...
> summary we have TC panics 1 year ago ;) Sysctl option "reboot on panic"
I'
The pktgen_thread.pid is set to current->pid and is never used
after this. So remove this at all.
Found during isolating the explicit pid/tgid usage.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 3a3154e..93695c2 100644
--- a/ne
On Wed, 2007-08-29 at 08:35 -0200, Jiri Slaby wrote:
> On 8/29/07, Johannes Berg <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-08-28 at 12:00 -0400, Jiri Slaby wrote:
> >
> > > The files are available only under GPLv2 since now.
> >
> > Since the BSD people are already getting upset about (for variou
Jarek Poplawski пишет:
On Wed, Aug 29, 2007 at 01:34:47PM +0200, Jarek Poplawski wrote:
On 29-08-2007 11:34, Badalian Vyacheslav wrote:
Again crash. Need more posts of panic or this message have full info
that needed to fix bug?
...
If it's possible you can try it shortly w
From: David Miller <[EMAIL PROTECTED]>
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Tue, 28 Aug 2007 13:30:57 -0700 (PDT)
> From: OBATA Noboru <[EMAIL PROTECTED]>
> Date: Tue, 28 Aug 2007 22:04:47 +0900 (JST)
>
> > (1) Make the application timeouts longer. (Steve h
On Wed, Aug 29, 2007 at 01:34:47PM +0200, Jarek Poplawski wrote:
> On 29-08-2007 11:34, Badalian Vyacheslav wrote:
> > Again crash. Need more posts of panic or this message have full info
> > that needed to fix bug?
...
> If it's possible you can try it shortly without e.g. netconsole or
> even w
On 29-08-2007 11:34, Badalian Vyacheslav wrote:
> Again crash. Need more posts of panic or this message have full info
> that needed to fix bug?
Hi,
Please, try to not create new threads each time: reply to the previous
one if you have something new. And this one doesn't seem to show more.
You
On Sun, 26 Aug 2007, Geert Uytterhoeven wrote:
> What I mean is that probably there used to be a printk() call starting with
> `\n'. Then someone added a `KERN_ERR' in front of it.
I gather '\n' at the beginning is to assure the following line is output
on a separate line rather than as a conti
Roland Dreier wrote:
Looks OK to me but I would just roll up the second patch into the
first patch and let Jeff merge it as one commit. There's no point in
creating an intermediate tree that doesn't build -- it just breaks git
bisect for no useful purpose.
Agreed -- this needs to be in a singl
On 8/29/07, Johannes Berg <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-08-28 at 12:00 -0400, Jiri Slaby wrote:
>
> > The files are available only under GPLv2 since now.
>
> Since the BSD people are already getting upset about (for various
> reasons among which seem to be a clear non-understanding) I'd
From: Ursula Braun <[EMAIL PROTECTED]>
Exclusive usage of OSA-cards has been introduced. Even though Linux
does not make use of it, qeth should be prepared to receive a bad RC
for some initialization steps. A meaningful message is now given,
if an OSA-device is set online, even though the OSA-adap
From: Klaus D. Wacker <[EMAIL PROTECTED]>
A network interface can get ARP packets even when the interface has
NOARP specified. In a HiperSockets environment this disturbs receiving
systems when packets are sent on the multicast queue. (E.g. TCP/IP on
z/VM issues messages reporting invalid data on
From: Frank Blaschka <[EMAIL PROTECTED]>
TSO requires tx checksumming. For non GSO frames in TSO/EDDP mode we
have to manually calculate the checksum.
Signed-off-by: Frank Blaschka <[EMAIL PROTECTED]>
Signed-off-by: Ursula Braun <[EMAIL PROTECTED]>
---
Subject: [patch 4/7] [PATCH] qeth: Announ
From: Ursula Braun <[EMAIL PROTECTED]>
Online setting of a qeth device may fail for instance because of:
- out-of-memory condition when allocating qdio queues
- IDX ACTIVATE problem
- ...
Such a device is still returned in a driver_for_each_device loop
processed in qeth_reboot_event(), which calls
From: Ursula Braun <[EMAIL PROTECTED]>
Problem:
A recovery thread must not be active when device is removed.
In qeth_remove_device() an interruptible wait operation is used
to wait until a qeth recovery thread is finished. If a user really
interrupts the ungroup operation of a qeth device while a
From: Frank Blaschka <[EMAIL PROTECTED]>
under memory pressure scatter gather mode switching messages must be
rate limited.
Signed-off-by: Frank Blaschka <[EMAIL PROTECTED]>
Signed-off-by: Ursula Braun <[EMAIL PROTECTED]>
---
drivers/s390/net/qeth_main.c | 13 -
1 file changed, 8
1 - 100 of 114 matches
Mail list logo
