login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2007
»
October
»
10
Re: sometimes very long response times on network interfaces since 2.6.22
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From: Eric Dumazet
Subject:
Re: sometimes very long response times on network interfaces since 2.6.22
Date: Wednesday, October 10, 2007 - 12:00 am
Ingo Freund a écrit :
quoted text
> Hello, > > since I switched to kernel 2.6.22 my dell 1750 server > with the two onboard BCM5704 network interfaces doesn't > work properly anymore. > TCP requests sometimes need more than 30 seconds to be answered > (or to get away) and the application stops with timeouts. > We are talking about two servers connected via Gigabit switch. > The timeouts happen up to ten times a day. > In the meantime I tried an old 3com 3c905c NIC which showed > the same behaviour. > I still couldn't figure out in which special situation the > communication stops. > The only solution ist to boot the old 2.6.21.5 kernel. > With this, all runs fine. > Did I miss a config issue in the migration to 2.6.22? > The machines run in a productive environment and there is > not much room (time) to debug, but if needed, I could try > if anyone would need more information for help. >
Hi 1) A tcpdump would help for sure... 2) Could you try 2.6.23 -
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to
majordomo@vger.kernel.org
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
sometimes very long response times on network interfaces s ...
, Ingo Freund
, (Tue Oct 9, 11:33 pm)
Re: sometimes very long response times on network interfac ...
, Eric Dumazet
, (Wed Oct 10, 12:00 am)
Re: sometimes very long response times on network interfac ...
, Ingo Freund
, (Wed Oct 10, 2:03 am)
Re: sometimes very long response times on network interfac ...
, Ingo Freund
, (Thu Oct 11, 10:57 pm)
Re: sometimes very long response times on network interfac ...
, Andrew Morton
, (Fri Oct 12, 5:39 pm)
Navigation
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Alexey Dobriyan
Re: [2.6.22.2 review 09/84] Fix rfkill IRQ flags.
Michael Moore
Re: underage models, pre teen models, lolita porn, young preteens, little lolitas
Alex Riesen
Re: [PATCH 4/7] lib: Introduce strnstr()
Thomas Gleixner
[ANNOUNCE] 2.6.31-rc6-rt2
Mathieu Desnoyers
Re: Linux 2.6.25-rc2
git
:
Blaisorblade
git-unpack-objects < pack file in repository doesn't work!
Matthieu Moy
Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
Linus Torvalds
Re: Untracked working tree files
Peter Karlsson
Re: CRLF problems with Git on Win32
Johannes Schindelin
Re: [PATCH 4/4] git-rebase -i: New option to support rebase with merges
linux-netdev
:
Alan Menegotto
Re: Linux networking implementation and packet capture
Andrew Morton
Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
Timo Teräs
ip xfrm policy semantics
Jarek Poplawski
Re: [PATCH]: Fix queueing return values...
David Miller
Re: [PATCH 1/2] netdev: bfin_mac: enable bfin_mac net dev driver for BF51x
git-commits-head
:
Linux Kernel Mailing List
Blackfin: don't give CPU its own line in traps output
Linux Kernel Mailing List
No need to do lock_super() for exclusion in generic_shutdown_super()
Linux Kernel Mailing List
x86, msr: Export the register-setting MSR functions via /dev/*/msr
Linux Kernel Mailing List
MIPS: SMTC: Fix lockup in smtc_distribute_timer
Linux Kernel Mailing List
powerpc: gamecube/wii: usbgecko bootwrapper console support
openbsd-misc
:
Aaron Mason
Re: Defending OpenBSD Performance
Henning Brauer
Re: Defending OpenBSD Performance
Henning Brauer
Re: Defending OpenBSD Performance
Christiano Farina Haesbaert
Re: Defending OpenBSD Performance
Nick Holland
Re: 1 out of 3 hunks failed--saving rejects to kerberosV/src/lib/krb5/crypto.c.rej
Colocation donated by:
Syndicate