The following reply was made to PR kern/35224; it has been noted by GNATS.

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, stephan.pietzko@uni-konstanz.de
Subject: Re: kern/35224: kernel hangs in mclpl after heavy net load in the sparc64 port (eventually also other ports)
Date: Sun, 10 Dec 2006 13:04:43 +0100

 On Sun, Dec 10, 2006 at 10:40:02AM +0000, Martin Husemann wrote:
 > The following reply was made to PR kern/35224; it has been noted by GNATS.
 > 
 > From: Martin Husemann <martin@duskware.de>
 > To: Stephan Pietzko <stephan.pietzko@uni-konstanz.de>
 > Cc: gnats-bugs@NetBSD.org
 > Subject: Re: kern/35224: kernel hangs in mclpl after heavy net load in the sparc64 port (eventually also other ports)
 > Date: Sun, 10 Dec 2006 11:37:09 +0100
 > 
 >  On Sun, Dec 10, 2006 at 10:01:18AM +0100, Stephan Pietzko wrote:
 >  > Can i do anything else to trace the problem?
 >  
 >  What does sysctl kern.mbuf.nmbclusters say? You could try increasing
 >  that (in case this is not a leak but just high mbuf cluster demand).
 
 Yes. I've noticed this with several public http servers. On occasions
 I have several connections with a full send-queue to the same client which
 don't make any progress. I think a combination of brocken ADSL setup and
 IE browser cause this: for some reasons the ADSL link can't pass some big
 packets, and IE opens a new connection and send the same request when
 it doesn't get the data fast enough (and the timeout is short).
 Fortunably such setups seems to be less and less frequents (maybe since
 ethernet/ADSL and USB/ADSL bridges are remplaced by ADSL NAT/routers).
 
 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --