the cur_state of the cooling device one-by-one
from max_state to what the cur_state was initially. The speed change
is confirmed by observing the current_link_speed for the corresponding
PCIe Port.
Signed-off-by: Ilpo Järvinen
---
MAINTAINERS | 1 +
tools
On Fri, 6 Sep 2024, Reinette Chatre wrote:
> On 9/6/24 3:00 AM, Ilpo Järvinen wrote:
> > On Thu, 5 Sep 2024, Reinette Chatre wrote:
> > > On 9/5/24 5:10 AM, Ilpo Järvinen wrote:
> > > > On Wed, 4 Sep 2024, Reinette Chatre wrote:
> > > > > On 9/4/24 4:5
On Fri, 6 Sep 2024, Reinette Chatre wrote:
> On 9/6/24 1:44 AM, Ilpo Järvinen wrote:
> > On Thu, 5 Sep 2024, Reinette Chatre wrote:
> > > On 9/5/24 4:45 AM, Ilpo Järvinen wrote:
> > > > On Wed, 4 Sep 2024, Reinette Chatre wrote:
> > > > > On 9/4/24 4:4
ftest.h:74:9: error: impossible constraint in ‘asm’
>74 | __asm__ __volatile__ ("cpuid\n\t"
> \
> | ^~~
> cat_test.c:306:17: note: in expansion of macro ‘__cpuid_count’
> 306 | __cpuid_count(0x10, 2, eax, ebx, ecx, edx);
>
> Reported-by: Muhamma
On Thu, 5 Sep 2024, Reinette Chatre wrote:
> On 9/5/24 5:10 AM, Ilpo Järvinen wrote:
> > On Wed, 4 Sep 2024, Reinette Chatre wrote:
> > > On 9/4/24 4:57 AM, Ilpo Järvinen wrote:
> > > > On Fri, 30 Aug 2024, Reinette Chatre wrote:
> > > > > On 8/30/24
On Thu, 5 Sep 2024, Reinette Chatre wrote:
> On 9/5/24 4:45 AM, Ilpo Järvinen wrote:
> > On Wed, 4 Sep 2024, Reinette Chatre wrote:
> > > On 9/4/24 4:43 AM, Ilpo Järvinen wrote:
> > > > On Fri, 30 Aug 2024, Reinette Chatre wrote:
> > > > > On 8/30/24
On Wed, 4 Sep 2024, Reinette Chatre wrote:
> On 9/4/24 4:57 AM, Ilpo Järvinen wrote:
> > On Fri, 30 Aug 2024, Reinette Chatre wrote:
> > > On 8/30/24 3:56 AM, Ilpo Järvinen wrote:
> > > > On Thu, 29 Aug 2024, Reinette Chatre wrote:
> > > > > @@ -69
On Wed, 4 Sep 2024, Reinette Chatre wrote:
> On 9/4/24 4:43 AM, Ilpo Järvinen wrote:
> > On Fri, 30 Aug 2024, Reinette Chatre wrote:
> > > On 8/30/24 4:42 AM, Ilpo Järvinen wrote:
> > > > On Thu, 29 Aug 2024, Reinette Chatre wrote:
> > > >
> > &
On Tue, 3 Sep 2024, Reinette Chatre wrote:
> On 9/3/24 7:45 AM, Ilpo Järvinen wrote:
> > The x86 selftests makefile clobbers CFLAGS preventing lib.mk from
> > making the necessary adjustments into CFLAGS. This would lead to a
> > build failure after upcoming change which want
On Wed, 4 Sep 2024, Shuah Khan wrote:
> On 9/4/24 06:18, Ilpo Järvinen wrote:
> > On Tue, 3 Sep 2024, Shuah Khan wrote:
> >
> > > On 9/3/24 08:45, Ilpo Järvinen wrote:
> > > > This series first generalizes resctrl selftest non-contiguous CAT check
> >
On Tue, 3 Sep 2024, Shuah Khan wrote:
> On 9/3/24 08:45, Ilpo Järvinen wrote:
> > This series first generalizes resctrl selftest non-contiguous CAT check
> > to not assume non-AMD vendor implies Intel. Second, it improves
> > selftests such that the use of __cpuid_count()
On Fri, 30 Aug 2024, Reinette Chatre wrote:
>
> Thank you for taking a look.
>
> On 8/30/24 3:56 AM, Ilpo Järvinen wrote:
> > On Thu, 29 Aug 2024, Reinette Chatre wrote:
> >
>
> ...
>
> > > @@ -684,11 +622,13 @@ int resctrl_val(const struct resctrl
On Fri, 30 Aug 2024, Reinette Chatre wrote:
> On 8/30/24 4:42 AM, Ilpo Järvinen wrote:
> > On Thu, 29 Aug 2024, Reinette Chatre wrote:
> >
> > > The MBA test incrementally throttles memory bandwidth, each time
> > > followed by a comparison between the memor
uire it using uname -m.
Provide a stub for __cpuid_count() if HAVE_CPUID is not present to
allow build to succeed. The stub casts its arguments to void to avoid
causing "unused variable" or "set but not used" warnings.
Fixes: ae638551ab64 ("selftests/resctrl: Add non-contig
initialization before inclusion of lib.mk but leave adding
KHDR_INCLUDES into CFLAGS into the existing position because
KHDR_INCLUDES might be generated inside lib.mk.
Signed-off-by: Ilpo Järvinen
---
v4:
- New patch
tools/testing/selftests/x86/Makefile | 4 +++-
1 file changed, 3 insertions
To avoid warnings when __cpuid_count() is an empty stub, always
initialize ecx because it is used in the return statement.
Signed-off-by: Ilpo Järvinen
Reviewed-by: Muhammad Usama Anjum
---
tools/testing/selftests/resctrl/cat_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
vendors.
Signed-off-by: Ilpo Järvinen
Reviewed-by: Muhammad Usama Anjum
---
tools/testing/selftests/resctrl/cat_test.c | 26 +-
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/tools/testing/selftests/resctrl/cat_test.c
b/tools/testing/selftests/resctrl
reason for void casts in the stub
Ilpo Järvinen (4):
selftests/resctrl: Generalize non-contiguous CAT check
selftests/resctrl: Always initialize ecx to avoid build warnings
selftests/x86: don't clobber CFLAGS
kselftest: Provide __cpuid_count() stub on non-x86 archs
tools/testing
On Thu, 29 Aug 2024, Ilpo Järvinen wrote:
> Building resctrl selftest fails on ARM because it uses __cpuid_count()
> that fails the build with error:
>
> CC resctrl_tests
> In file included from resctrl.h:24,
> from cat_test.c:11:
> In function '
developed and should apply cleanly at least on top the
benchmark cleanup series (might apply cleanly also w/o the benchmark
series, I didn't test).
Ilpo Järvinen (5):
selftests/resctrl: Extend signal handler coverage to unmount on
receiving signal
selftests/resctrl: Remove duplicate fe
On Sat, 23 Feb 2008, Andi Kleen wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
>
> >> -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
> >
> > This is a surprise. I expect that the -mm-only
> > profile-likely-unlikely-macros.patch is the cause of this and mainline
> > doesn't have t
On Sat, 23 Feb 2008, Andrew Morton wrote:
> On Wed, 20 Feb 2008 15:47:10 +0200 "Ilpo J__rvinen" <[EMAIL PROTECTED]> wrote:
>
> > -41525 2066 f, 3370 +, 44895 -, diff: -41525 IS_ERR
>
> This is a surprise.
It surprised me as well, there were something like 10 bytes I just
couldn't explain i
On Sat, 23 Feb 2008, Andrew Morton wrote:
> On Wed, 20 Feb 2008 15:47:18 +0200 "Ilpo Järvinen" <[EMAIL PROTECTED]> wrote:
>
> > vmlinux.o:
> > 62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
> >
> > ...+ these to lib/jh
On Wed, 20 Feb 2008, Vlad Yasevich wrote:
> Ilpo Järvinen wrote:
> > I added inline to sctp_add_cmd and appropriate comment there to
> > avoid adding another call into the call chain. This works at least
> > with "gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13)". Al
On Wed, 20 Feb 2008, Jan Engelhardt wrote:
>
> On Feb 20 2008 17:27, Patrick McHardy wrote:
> >> Striking. How can this even happen? A callsite which calls
> >>
> >> dev_alloc_skb(n)
> >>
> >> is just equivalent to
> >>
> >> __dev_alloc_skb(n, GFP_ATOMIC);
> >>
> >> which means there's like
Codiff stats:
-16420 187 funcs, 103 +, 16523 -, diff: -16420 --- dst_release
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/net/dst.h | 10 +-
net/core/dst.c| 10 ++
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/include/net/dst.h b/i
es removed, diff: -6593
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
Cc: Vlad Yasevich <[EMAIL PROTECTED]>
---
include/net/sctp/sm.h |8 ++--
net/sctp/command.c| 12 +++-
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/include/net/sctp/sm.h b
vmlinux.o:
62 functions changed, 66 bytes added, 10935 bytes removed, diff: -10869
...+ these to lib/jhash.o:
jhash_3words: 112
jhash2: 276
jhash: 475
select for networking code might need a more fine-grained approach.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
drivers/infi
-28162 354 funcs, 3005 +, 31167 -, diff: -28162 --- skb_pull
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 15 +--
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/include
-10976 209 funcs, 123 +, 11099 -, diff: -10976 --- skb_trim
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 16 +---
net/core/skbuff.c | 16
2 files changed, 17 insertions(+), 15 deletions(-)
diff --git a/include
-23668 392 funcs, 104 +, 23772 -, diff: -23668 --- dev_alloc_skb
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 17 +
net/core/skbuff.c | 18 ++
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/include
()
should be rethought but I don't have a clue how to do that.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 20 +---
net/core/skbuff.c | 21 +
2 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/in
-21593 356 funcs, 2418 +, 24011 -, diff: -21593 --- skb_push
Again, current_text_addr() needs to addressed.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/skbuff.h | 18 +-
net/core/skbuff.c | 19 +++
2 files changed, 20 inse
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2 20
Hi all,
I run some lengthy tests to measure cost of inlines in headers under
include/, simple coverage calculations yields to 89% but most of the
failed compiles are due to preprocessor cutting the tested block away
anyway. Test setup: v2.6.24-mm1, make allyesconfig, 32-bit x86,
gcc (GCC) 4.1.2 20
On Wed, 13 Feb 2008, linux-os (Dick Johnson) wrote:
>
> On Wed, 13 Feb 2008, [iso-8859-1] Ilpo Järvinen wrote:
>
> > They're defined later on in the same file with bodies and
> > nothingin between needs them.
> >
> > Signed-off-by: Ilpo Järvinen <[EM
They're defined later on in the same file with bodies and
nothingin between needs them.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
include/linux/coda_linux.h |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/include/linux/coda_linux.h b/in
On Fri, 8 Feb 2008, Jan Engelhardt wrote:
>
> On Feb 8 2008 22:34, ael wrote:
> >
> >Sure, I looked there in some depth. But some/most are special purpose or
> > 'locals'. One needs a map for the "main" repositories...
>
> Indeed, a page on kernelnewbies.org with the most important repositories
On Thu, 24 Jan 2008, Ilpo Järvinen wrote:
> And anyway, there were some fackets_out related
> problems reported as well and this doesn't help for that but I think I've
> lost track of who was seeing it due to large number of reports :-), could
> somebody refresh my memo
its which won't be set with it at all.
Effectively, NewReno should always exists after the first
iteration anyway (or immediately if there's already head in
lost_out.
This was fixed earlier in net-2.6.25 but got reverted among other
stuff and I didn't notice that this is still ne
On Wed, 23 Jan 2008, Ilpo Järvinen wrote:
> On Wed, 23 Jan 2008, Dave Young wrote:
>
> > On Jan 23, 2008 3:41 PM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > >
> > > On Tue, 22 Jan 2008, David Miller wrote:
> > >
> > > > From: "Dav
On Wed, 23 Jan 2008, Dave Young wrote:
> On Jan 23, 2008 3:41 PM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 22 Jan 2008, David Miller wrote:
> >
> > > From: "Dave Young" <[EMAIL PROTECTED]>
> > > Date: Wed, 23 Jan 20
On Tue, 22 Jan 2008, David Miller wrote:
> From: "Dave Young" <[EMAIL PROTECTED]>
> Date: Wed, 23 Jan 2008 09:44:30 +0800
>
> > On Jan 22, 2008 6:47 PM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > > [PATCH] [TCP]: debug S+L
> >
>
On Tue, 22 Jan 2008, Dave Young wrote:
> On Jan 22, 2008 12:37 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> >
> > On Jan 22, 2008 5:14 AM, Ilpo Järvinen <[EMAIL PROTECTED]> wrote:
> > >
> > > On Mon, 21 Jan 2008, Dave Young wrote:
> > >
>
On Mon, 21 Jan 2008, Dave Young wrote:
> Please see the kernel messages following,(trigged while using some qemu
> session)
> BTW, seems there's some e100 error message as well.
>
> PCI: Setting latency timer of device :00:1b.0 to 64
> e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
>
On Mon, 14 Jan 2008, Ilpo Järvinen wrote:
> On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
>
> > On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> > >
> > > As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
> > > regression is
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
> On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> > The regression is:
> > 1)stoakley with 2 qual-core processors: 11%;
> > 2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
> I have new update on this issue and also cc to netdev maillist.
On Thu, 20 Dec 2007, James Nichols wrote:
> > You'd probably should also investigate the Linux kernel,
> > especially the size and locks of the components of the Sack data
> > structures and what happens to those data structures after Sack is
> > disabled (presumably the Sack data structure is in
On Thu, 20 Dec 2007, James Nichols wrote:
> > I still dont understand.
> >
> > "tcpdump -p -n -s 1600 -c 1" doesnt reveal User data at all.
> >
> > Without any exact data from you, I am afraid nobody can help.
>
> Oh, I didn't see that you specified specific options. I'll still have
> to ano
On Wed, 19 Dec 2007, Eric Dumazet wrote:
> James Nichols a écrit :
> > On 12/19/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> > > James Nichols a écrit :
> > > > > So you see outgoing SYN packets, but no SYN replies coming from the
> > > > > remote
> > > > > peer ? (you mention ACKS, but the firs
On Fri, 14 Dec 2007, Ilpo Järvinen wrote:
> So, I might soon prepare a revert patch for most of the questionable
> TCP parts and ask Dave to apply it (and drop them fully during next
> rebase) unless I suddently figure something out soon which explains
> all/most of the problems,
On Thu, 13 Dec 2007, Cedric Le Goater wrote:
> I got this one while compiling on NFS.
>
> C.
>
> kernel BUG at /home/legoater/linux/2.6.24-rc4-mm1/include/net/tcp.h:1480!
I'm not exactly sure what patches you have applied and which patches are
not, with rc4-mm1 there are two patches (first one
On Mon, 10 Dec 2007, Ilpo Järvinen wrote:
> Dave, please include this one to net-2.6.25.
...
> --
> [PATCH] [TCP]: Fix fack_count miscountings (multiple places)
I've better version of this coming up, so Dave please don't put this one
into net-2.6.25 (noticed that both t
x27;t return it because it's on
the other list already). These manifest as fackets_out counting
error later on, the second-order effects are very hard to track,
so it may fix all out-standing TCP bug reports.
2) Prev == NULL check was wrong way around
3) Last skb's fack count was incorrectly
On Wed, 5 Dec 2007, David Miller wrote:
> From: Reuben Farrelly <[EMAIL PROTECTED]>
> Date: Thu, 06 Dec 2007 17:59:37 +1100
>
> > On 5/12/2007 4:17 PM, Andrew Morton wrote:
> > > - Lots of device IDs have been removed from the e1000 driver and moved
> > > over
> > > to e1000e. So if your e100
On Thu, 8 Nov 2007, Rainer Jochem wrote:
> @@ -620,6 +622,17 @@ ic_dhcp_init_options(u8 *options)
> *e++ = sizeof(ic_req_params);
> memcpy(e, ic_req_params, sizeof(ic_req_params));
> e += sizeof(ic_req_params);
> +
> + // Send it only if the ac
On Wed, 24 Oct 2007, Adrian Bunk wrote:
> tcp_match_skb_to_sack() can become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
[...snip...]
Thanks, I should have noticed that right from the beginning...
Added DaveM to recipients.
--
i.
-
To unsubscribe from this list: send the lin
On Thu, 18 Oct 2007, Ingo Molnar wrote:
>
> * Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
> > > it's perfectly legitimate, in fact more robust. So if checkpatch.pl
> > > wants to make any noise about such constructs it should warn about
> > > the _lack_ of curly braces in every multi-line cond
A good candidate to checkpatch.pl's check list, btw.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
drivers/char/watchdog/wdt.c |3 ++-
drivers/char/watchdog/wdt_pci.c |3 ++-
drivers/scsi/osst.c |6 --
3 files changed, 8 insertions(+), 4 deletio
On Sat, 13 Oct 2007, Willy Tarreau wrote:
> On Sat, Oct 13, 2007 at 07:50:36PM +0200, Adrian Bunk wrote:
> > On Sat, Oct 13, 2007 at 07:22:14PM +0200, Willy Tarreau wrote:
> > >...
> > > Thanks for your help, I really appreciate it. In fact, I've reviewed them
> > > four, but two of them did not ap
On Sat, 13 Oct 2007, Willy Tarreau wrote:
> It's possible that new SACK blocks that should trigger new LOST
> markings arrive with new data (which previously made is_dupack
> false). In addition, I think this fixes a case where we get
> a cumulative ACK with enough SACK blocks to trigger the fast
On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> On Wed, 3 Oct 2007, Frans Pop wrote:
>
> > The only change is in 2 consecutive columns: "2911 502" -> "2912 500".
> > Is processor usage calculated from those? Can someone explain how?
>
> The latte
On Wed, 3 Oct 2007, Frans Pop wrote:
> On Wednesday 03 October 2007, you wrote:
> > Try to capture the i/o log with the following command:
> > strace -o top.log top
>
> Thanks for the suggestion.
>
> > This will show for sure whether the kernel gives out incorrect data or
> > top misinterprets t
> On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
>
> > I'm currently out of ideas where it could come from...
Hmm, there seems to be off-by-one in tcp_retrans_try_collapse after
all, or in fact, two of them. I'll post patch for this tomorrow...
--
i.
On Tue, 2 Oct 2007, Ilpo Järvinen wrote:
> I'm currently out of ideas where it could come from... so lets try
> brute-force checking as your test case is not very high-speed... This
> could hide it though... :-(
>
> Please put the patch below on top of clean rc8-mm2 (it in
On Mon, 1 Oct 2007, Cedric Le Goater wrote:
> got it !
>
> r3-06.test.meiosys.com login: WARNING: at
> /home/legoater/linux/2.6.23-rc8-mm2/net/ipv4/tcp_input.c:2314
> tcp_fastretrans_alert()
>
> Call Trace:
>[] tcp_ack+0xcd6/0x18af
[...snip...]
>
> TCP 0
Hmm, so it's SACK then...
> I w
On Sat, 29 Sep 2007, Cedric Le Goater wrote:
> Ilpo Järvinen wrote:
> > On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> >> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
> >>
> >>> I just found that warning in my logs. It seems that it's
On Fri, 28 Sep 2007, Ilpo Järvinen wrote:
> On Fri, 28 Sep 2007, Cedric Le Goater wrote:
>
> > I just found that warning in my logs. It seems that it's been
> > happening since rc7-mm1 at least.
> >
> > WARNING: at /home/legoater/linux/2.6.2
On Fri, 28 Sep 2007, Cedric Le Goater wrote:
> Hello !
>
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc8/2.6.23-rc8-mm2/
>
> I just found that warning in my logs. It seems that it's been
> happening since rc7-mm1 at least.
>
> Thanks !
>
>
On Thu, 27 Sep 2007, Majumder, Rajib wrote:
> We have observed 40ms latency spikes in TCP connections in "burst" type of
> traffic.
> This affects regular TCP sockets.
Are segments being sent full-sized, or is there perhaps some Nagle
component in it as well? I.e., are the applications using TC
On Thu, 16 Aug 2007, Herbert Xu wrote:
> We've been through that already. If it's a busy-wait it
> should use cpu_relax.
I looked around a bit by using some command lines and ended up wondering
if these are equal to busy-wait case (and should be fixed) or not:
./drivers/telephony/ixj.c
6674:
...I guess those guys hunting for broken busyloops in the other thread
could also benefit from similar searching commands introduced in this
thread... ...Ccing Satyam to caught their attention too.
> On Wed, Aug 15, 2007 at 05:40:11PM -0700, Joe Perches wrote:
> >
> > There's more than a few
On Sun, 12 Aug 2007, Andrew Morton wrote:
> On Sun, 12 Aug 2007 20:15:51 +0300 (EEST) "Ilpo Järvinen" <[EMAIL PROTECTED]>
> wrote:
>
> > Hmm, it was really worth of it, I did:
> > $ git-fetch linus
> > $ git-reset --hard linus
> > [...make &
On Sun, 12 Aug 2007, Andrew Morton wrote:
> On Sun, 12 Aug 2007 14:20:46 +0300 (EEST) "Ilpo Järvinen" <[EMAIL PROTECTED]>
> wrote:
> > On Sun, 12 Aug 2007, Andrew Morton wrote:
> > > On Sat, 11 Aug 2007 15:39:30 +0300 (EEST) "Ilpo Järvinen" <
On Sun, 12 Aug 2007, Andrew Morton wrote:
> On Sat, 11 Aug 2007 15:39:30 +0300 (EEST) "Ilpo Järvinen" <[EMAIL PROTECTED]>
> wrote:
>
> > I noticed that v2.6.23-rc1 locks up during boot, same thing happens now
> > with the latest linus' tree (+net-2.6.2
I noticed that v2.6.23-rc1 locks up during boot, same thing happens now
with the latest linus' tree (+net-2.6.24 and tcp-2.6 tree stuff on top
of it; in -rc1 test they weren't though). The exact location of hang
varies a bit though. No OOPS, does not respond to sysrq or anything else
besides res
On Sat, 4 Aug 2007, Ingo Molnar wrote:
> * Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > People just need to know about the performance differences - very few
> > realise its more than a fraction of a percent. I'm sure Gentoo will
> > use relatime the moment anyone knows its > 5% 8)
>
> noatime,no
On Tue, 31 Jul 2007, Darryl L. Miles wrote:
> I've been able to capture a tcpdump from both ends during the problem and its
> my belief there is a bug in 2.6.20.1 (at the client side) in that it issues a
> SACK option for an old sequence which the current window being advertised is
> beyond it. T
On Sun, 29 Jul 2007, Willy Tarreau wrote:
> On Sun, Jul 29, 2007 at 12:28:04PM +0300, Ilpo Järvinen wrote:
>
> > [...snip...]
> >
> > > BTW, some information are missing. It would have been better if the trace
> > > had been read with tcpdump -Svv. W
On Sun, 29 Jul 2007, Willy Tarreau wrote:
> On Sun, Jul 29, 2007 at 11:26:00AM +0300, Ilpo Järvinen wrote:
> > On Sun, 29 Jul 2007, Willy Tarreau wrote:
> >
> > > On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> > > > CLIENT = Linux 2.6.20.1
On Sun, 29 Jul 2007, Willy Tarreau wrote:
> On Sun, Jul 29, 2007 at 06:59:26AM +0100, Darryl L. Miles wrote:
> > CLIENT = Linux 2.6.20.1-smp [Customer build]
> > SERVER = Linux 2.6.9-55.ELsmp [Red Hat Enterprise Linux AS release 4
> > (Nahant Update 5)]
> >
> > The problems start around time ind
otentially a
negative packets in flight (= large one) disturbing cwnd compares.
[PATCH] [TCP]: Use S+L catcher only with SACK for now
TCP has a transitional state when SACK is not in use during
which this invariant is temporarily broken. Without SACK,
tcp_clean_rtx_queue does not decrement sac
82 matches
Mail list logo
