From owner-svn-src-head@FreeBSD.ORG Sat Aug 1 02:58:50 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CB92106564A; Sat, 1 Aug 2009 02:58:50 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6048FC16; Sat, 1 Aug 2009 02:58:49 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n712whGn079744; Fri, 31 Jul 2009 20:58:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A73AF67.3010508@samsco.org> Date: Fri, 31 Jul 2009 20:58:47 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Dmitry Marakasov References: <200907300014.n6U0EZ77086341@svn.freebsd.org> <20090801022914.GB93222@hades.panopticon> In-Reply-To: <20090801022914.GB93222@hades.panopticon> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, Alfred Perlstein , Navdeep Parhar , src-committers@FreeBSD.org Subject: Re: svn commit: r195960 - in head/sys/dev/usb: . controller input X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 02:58:50 -0000 Dmitry Marakasov wrote: > * Navdeep Parhar (nparhar@gmail.com) wrote: > >> This has slowed down core dumps very significantly. What used to take 10-15s on >> my system now takes around 3 minutes. > > Same here. > Likely because prior to polling being implemented, each i/o was done blindly and completed immediately instead of waiting for actual confirmation from the hardware. Crashdumps have been slow for a number of years, thanks to a fundamental change in how they are done. Until now, USB was cheating and making them look fast. Scott