From owner-freebsd-current@FreeBSD.ORG Tue Sep 27 12:06:26 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33B83106566B for ; Tue, 27 Sep 2011 12:06:26 +0000 (UTC) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from gse-mta-27.emailfiltering.com (gse-mta-27-tx.emailfiltering.com [194.116.198.158]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA338FC14 for ; Tue, 27 Sep 2011 12:06:24 +0000 (UTC) Received: from mail-gw13.york.ac.uk ([144.32.129.163]) by gse-mta-27.emailfiltering.com with emfmta (version 4.8.3.54) by TLS id 1147681796 for adrian@freebsd.org; 7dc7738d27850f0f; Tue, 27 Sep 2011 13:06:23 +0100 Received: from buffy-128.york.ac.uk ([144.32.128.160]:26990) by mail-gw13.york.ac.uk with esmtpsa (SSL3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1R8WQY-0005jE-5W; Tue, 27 Sep 2011 13:06:22 +0100 X-Authenticated-User: ga9 From: Gavin Atkinson To: Adrian Chadd In-Reply-To: References: <8bce9b8a86d5c7a83095d8e58f794f64@i-pi.pl> <9e25323fa87abb93af1946c9ed2c399e@i-pi.pl> Content-Type: text/plain; charset="ASCII" Date: Tue, 27 Sep 2011 13:06:21 +0100 Message-ID: <1317125181.95805.13.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "crsnet.pl" , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [Solved] FreeBSD 9-Beta3 on X300 2 problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Sep 2011 12:06:26 -0000 On Tue, 2011-09-27 at 19:53 +0800, Adrian Chadd wrote: > Hans, > > Why haven't those patches been committed? This patch is an absolute hack, and shouldn't be committed as it is. I would, however, appreciate some help in determining the correct solution. The solution may well involve not suspending/resuming hpet(4) or the other timers on the normal DEVICE_SUSPEND()/DEVICE_RESUME() path but instead doing them as the last thing to be suspended, or it may instead involve reworking the USB code (and potentially other code) to not need to sleep during suspend/resume. I don't know the right solution, but would really like to work with somebody who does. Please also see the thread "Choosing between DELAY(useconds) and pause()" on -current. Gavin