From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 29 06:49:41 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 375F7106566C for ; Sun, 29 Jul 2012 06:49:41 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id BC3468FC08 for ; Sun, 29 Jul 2012 06:49:40 +0000 (UTC) Received: by wibhm11 with SMTP id hm11so659636wib.13 for ; Sat, 28 Jul 2012 23:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=djj8OsIjk9h4DtoQYW7c9yjTyquy1Xqu2a6PDwEfh+w=; b=Ed5730vjCh3brmLIex5ruJ7F+qDy5mgjFePudYzvTo2mugPmTWf1yJ3X++PCS2TukR NXy91A2IBCVvn1+piIMtU1t5FB/TCbfEWfrCYoFyL0FtxGh7CFAzwUZl3YzTWqNmNc4i /iC2eWTIJpzUbwCMheugpVA1uO848yKicGgy01eUzmyo5wTcZGKshXQU82r63SVB3exh lPiCrhxPFnQlPBwz9ku982ETYLQ/SD3FOTH811tir0T8HlKBUEZiLS35g5eIExyPo/2W cybNZp4y3FS2xzMOmyNVL0KwTd8hg6DPJBARg+j/PNdqFPJr7aZJKPHlhwsyXLgmwxyV Qpng== Received: by 10.180.84.104 with SMTP id x8mr33641166wiy.20.1343544579628; Sat, 28 Jul 2012 23:49:39 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id b7sm12868662wiz.9.2012.07.28.23.49.38 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 Jul 2012 23:49:39 -0700 (PDT) Sender: Alexander Motin Message-ID: <5014DD00.3000307@FreeBSD.org> Date: Sun, 29 Jul 2012 09:49:36 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 06:49:41 -0000 Hi. With ACPI timer gradually becoming one of slowest in the system, is there some reason to use it directly in acpi_cpu_idle()? I've made a patch: http://people.freebsd.org/~mav/sleep_time.patch to use binuptime() instead. Using even HPET from system time counter (not even speaking about TSC) that significantly improves performance on some workloads if this code is not covered by MWAIT optimization in cpu_idle(). -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 29 08:38:01 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A0DD1065676; Sun, 29 Jul 2012 08:38:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id 18FC88FC0A; Sun, 29 Jul 2012 08:38:00 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6T8bpGw030794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2012 18:37:52 +1000 Date: Sun, 29 Jul 2012 18:37:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin In-Reply-To: <5014DD00.3000307@FreeBSD.org> Message-ID: <20120729175031.U2084@besplex.bde.org> References: <5014DD00.3000307@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@FreeBSD.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 08:38:01 -0000 On Sun, 29 Jul 2012, Alexander Motin wrote: > With ACPI timer gradually becoming one of slowest in the system, is there > some reason to use it directly in acpi_cpu_idle()? I've made a patch: > http://people.freebsd.org/~mav/sleep_time.patch > to use binuptime() instead. Using even HPET from system time counter (not > even speaking about TSC) that significantly improves performance on some > workloads if this code is not covered by MWAIT optimization in cpu_idle(). Does it work with a perverse timecounter like the i8254 work? The user is permitted to switch to any supported timecounter. There are other perverse ones: - ACPI. This seems to be unavailable if the system thinks ACPI-fast works. Bug. The user should be able to downgrade to it if ACPI-fast in fact doesn't work. Since it reads the hardware more than once, it is much slower than direct use of the hardware. - ACPI-fast. Even this is perverse. It only reads the hardware once, but goes through many software layers. binuptime() is more accurate than uncalibrated scaling. Is accuracy required? If not, the CPU ticker might work, and is faster than HPET, and and is not under user control for perverse settings. It normally reduces to readtsc() with no serializing instruction even in proposed changes. This is good enough for process times (not very good) and depends on the CPU not changing. Its calibration is very accurate (similar to timecounters) modulo bugs, but not always up to date. Bruce From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 29 10:14:17 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D3C31065670 for ; Sun, 29 Jul 2012 10:14:17 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BCD88FC0C for ; Sun, 29 Jul 2012 10:14:16 +0000 (UTC) Received: by weyx56 with SMTP id x56so3568576wey.13 for ; Sun, 29 Jul 2012 03:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0Xu7g11JGW8Ahz/LmGeCStecJAUE1idjsyPLhBtakrw=; b=dCOcnwXdLyzRiKRwEhRwk9/GFNHZKwd3QMUmJ4T4AiuFqg9XorRnTsAoMSlXxqasR9 4FEJrFBVcyN3LFJYBWCfjrmxbbSDTO2oI0IImnvPj7r8PB65EzB9VivZe4kmM0raJkqa rqdD+cWkwIMynHDj8+iTP+nhtAAOcj97ta0pxRZxDIX+cGqS2219YhAk193RsNWayPB2 lcQJO3cHNBviODs7CIn/NMnNitvXxpawxprK/6GfIrFLN5B967qh2+bxqP/HiiDxf69E xNa2NKcv9+sBbMos599xoHAOEulAAM80qIRHoVWwIjaYhsIc51BcadnJM42wHWUD11Y2 gJ9g== Received: by 10.180.100.37 with SMTP id ev5mr18568287wib.5.1343556856294; Sun, 29 Jul 2012 03:14:16 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id t7sm14195237wix.6.2012.07.29.03.14.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 03:14:15 -0700 (PDT) Sender: Alexander Motin Message-ID: <50150CF5.4070605@FreeBSD.org> Date: Sun, 29 Jul 2012 13:14:13 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> In-Reply-To: <20120729175031.U2084@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 10:14:17 -0000 On 29.07.2012 11:37, Bruce Evans wrote: > On Sun, 29 Jul 2012, Alexander Motin wrote: > >> With ACPI timer gradually becoming one of slowest in the system, is >> there some reason to use it directly in acpi_cpu_idle()? I've made a >> patch: >> http://people.freebsd.org/~mav/sleep_time.patch >> to use binuptime() instead. Using even HPET from system time counter >> (not even speaking about TSC) that significantly improves performance >> on some workloads if this code is not covered by MWAIT optimization in >> cpu_idle(). > > Does it work with a perverse timecounter like the i8254 work? At least on my test system it does, even though predictably much slower then the others. > The > user is permitted to switch to any supported timecounter. There are > other perverse ones: > - ACPI. This seems to be unavailable if the system thinks ACPI-fast > works. Bug. The user should be able to downgrade to it if ACPI-fast > in fact doesn't work. Since it reads the hardware more than once, > it is much slower than direct use of the hardware. > - ACPI-fast. Even this is perverse. It only reads the hardware once, > but goes through many software layers. > > binuptime() is more accurate than uncalibrated scaling. Is accuracy > required? Accuracy is not required at all. +-20% is not a problem. > If not, the CPU ticker might work, and is faster than HPET, > and and is not under user control for perverse settings. It normally > reduces to readtsc() with no serializing instruction even in proposed > changes. This is good enough for process times (not very good) and > depends on the CPU not changing. Its calibration is very accurate > (similar to timecounters) modulo bugs, but not always up to date. Problem with ticker that it may stop during idle periods, and idle is exactly what happens here. Unlike timecounter usage here we don't need CPU synchronicity, but we need it working during deep sleeps. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 29 12:26:21 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F317A106564A; Sun, 29 Jul 2012 12:26:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 339F78FC17; Sun, 29 Jul 2012 12:26:19 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6TCQFQm003777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2012 22:26:18 +1000 Date: Sun, 29 Jul 2012 22:26:15 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin In-Reply-To: <50150CF5.4070605@FreeBSD.org> Message-ID: <20120729221526.H2941@besplex.bde.org> References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 12:26:21 -0000 On Sun, 29 Jul 2012, Alexander Motin wrote: > On 29.07.2012 11:37, Bruce Evans wrote: > ... >> binuptime() is more accurate than uncalibrated scaling. Is accuracy >> required? > > Accuracy is not required at all. +-20% is not a problem. > >> If not, the CPU ticker might work, and is faster than HPET, >> and and is not under user control for perverse settings. It normally >> reduces to readtsc() with no serializing instruction even in proposed >> changes. This is good enough for process times (not very good) and >> depends on the CPU not changing. Its calibration is very accurate >> (similar to timecounters) modulo bugs, but not always up to date. > > Problem with ticker that it may stop during idle periods, and idle is exactly > what happens here. Unlike timecounter usage here we don't need CPU > synchronicity, but we need it working during deep sleeps. The ticker is the same as the timecounter in many cases of interest. If the TSC stops then it cannot be used for timecounting unless timecounting is reinitialized. Timecounting should be reinitialized after deep sleeps, but you say you need it to work during deep sleeps. I wouldn't trust timecounters for some time after waking up after a deep sleep. If their clock stopped then the times read might only be very out of date. If their clock didn't stop, then they might have wrapped or otherwise overflowed and the times read would be garbage. Is there any locking or ordering to prevent them being used before they are reinitialized? Bruce From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 29 14:44:51 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29868106566B for ; Sun, 29 Jul 2012 14:44:51 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A1CF68FC16 for ; Sun, 29 Jul 2012 14:44:50 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so3937091wgb.31 for ; Sun, 29 Jul 2012 07:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FvlgUY90zpkQng2oNl/wGgF8e0bb5eN8KZ4GNOwZ0vQ=; b=0MNgfMRDMKli/XWnNmxKCHnhnPJx1YL7+ifRO7+U8JR2HOUMF8fr6G70fq8VEg38bg /rY2DpvkB9vwmo+gbQu7SgTVCi2ngFAJ8kgY8fWvy6GqwGJD/A39UMcwYw7pfGQCStkI hfftSpNgHkMnAQ3LCkjImVzDPy1DB1aWILdvA9jdsCzfjjzvCQHS6RyQ1bwlGL3qa22q EQ+fvaghKmslCUUO72nFQtJlFRBuGeDtb84a0dGEhsdWaTCBvzOIZHEQ38riV+WI6O+1 byu5ookAanonFE8n4C7vDDrY/nhqEbwPmebaQ+GW+ErU6ZhLxBy8kJoZjs83cZgxsO2C zCKg== Received: by 10.180.98.138 with SMTP id ei10mr19745342wib.1.1343573083470; Sun, 29 Jul 2012 07:44:43 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id t8sm10947334wiy.3.2012.07.29.07.44.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 07:44:42 -0700 (PDT) Sender: Alexander Motin Message-ID: <50154C58.4060408@FreeBSD.org> Date: Sun, 29 Jul 2012 17:44:40 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@FreeBSD.org> <20120729221526.H2941@besplex.bde.org> In-Reply-To: <20120729221526.H2941@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 14:44:51 -0000 On 29.07.2012 15:26, Bruce Evans wrote: > On Sun, 29 Jul 2012, Alexander Motin wrote: > >> On 29.07.2012 11:37, Bruce Evans wrote: >> ... >>> binuptime() is more accurate than uncalibrated scaling. Is accuracy >>> required? >> >> Accuracy is not required at all. +-20% is not a problem. >> >>> If not, the CPU ticker might work, and is faster than HPET, >>> and and is not under user control for perverse settings. It normally >>> reduces to readtsc() with no serializing instruction even in proposed >>> changes. This is good enough for process times (not very good) and >>> depends on the CPU not changing. Its calibration is very accurate >>> (similar to timecounters) modulo bugs, but not always up to date. >> >> Problem with ticker that it may stop during idle periods, and idle is >> exactly what happens here. Unlike timecounter usage here we don't need >> CPU synchronicity, but we need it working during deep sleeps. > > The ticker is the same as the timecounter in many cases of interest. If > the TSC stops then it cannot be used for timecounting unless timecounting > is reinitialized. Timecounting should be reinitialized after deep sleeps, > but you say you need it to work during deep sleeps. Timecounter already has detection logic to disable TSC in cases where it is unreliable. I don't want to replicate it here. I need not precise and not synchronized by reliable and fast time source. > I wouldn't trust timecounters for some time after waking up after a > deep sleep. If their clock stopped then the times read might only be > very out of date. If their clock didn't stop, then they might have > wrapped or otherwise overflowed and the times read would be garbage. > Is there any locking or ordering to prevent them being used before they > are reinitialized? I am not sure what reinitialization are you talking about. IIRC, there is no any waking up code for TSC. None other time counters have problems with C-states. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 30 04:39:48 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C01D2106566C; Mon, 30 Jul 2012 04:39:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx06.syd.optusnet.com.au (fallbackmx06.syd.optusnet.com.au [211.29.132.8]) by mx1.freebsd.org (Postfix) with ESMTP id 52B348FC0A; Mon, 30 Jul 2012 04:39:47 +0000 (UTC) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by fallbackmx06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6U4XbZ7024170; Mon, 30 Jul 2012 14:33:37 +1000 Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6U4XSbX017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 14:33:29 +1000 Date: Mon, 30 Jul 2012 14:33:28 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin In-Reply-To: <50154C58.4060408@FreeBSD.org> Message-ID: <20120730141426.D1219@besplex.bde.org> References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@FreeBSD.org> <20120729221526.H2941@besplex.bde.org> <50154C58.4060408@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@FreeBSD.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 04:39:48 -0000 On Sun, 29 Jul 2012, Alexander Motin wrote: > On 29.07.2012 15:26, Bruce Evans wrote: >> On Sun, 29 Jul 2012, Alexander Motin wrote: >> >>> On 29.07.2012 11:37, Bruce Evans wrote: >>> ... >>>> binuptime() is more accurate than uncalibrated scaling. Is accuracy >>>> required? >>> >>> Accuracy is not required at all. +-20% is not a problem. >>> >>>> If not, the CPU ticker might work, and is faster than HPET, >>>> and and is not under user control for perverse settings. It normally >>>> reduces to readtsc() with no serializing instruction even in proposed >>>> changes. This is good enough for process times (not very good) and >>>> depends on the CPU not changing. Its calibration is very accurate >>>> (similar to timecounters) modulo bugs, but not always up to date. >>> >>> Problem with ticker that it may stop during idle periods, and idle is >>> exactly what happens here. Unlike timecounter usage here we don't need >>> CPU synchronicity, but we need it working during deep sleeps. >> >> The ticker is the same as the timecounter in many cases of interest. If >> the TSC stops then it cannot be used for timecounting unless timecounting >> is reinitialized. Timecounting should be reinitialized after deep sleeps, >> but you say you need it to work during deep sleeps. > > Timecounter already has detection logic to disable TSC in cases where it is > unreliable. I don't want to replicate it here. I need not precise and not > synchronized by reliable and fast time source. Yes, this logic gives exactly what you don't want (an inefficient timecounter), by preventing use of the TSC for the timecounter, although the TSC is perfectly usable for the ticker and here. >> I wouldn't trust timecounters for some time after waking up after a >> deep sleep. If their clock stopped then the times read might only be >> very out of date. If their clock didn't stop, then they might have >> wrapped or otherwise overflowed and the times read would be garbage. >> Is there any locking or ordering to prevent them being used before they >> are reinitialized? > > I am not sure what reinitialization are you talking about. IIRC, there is no > any waking up code for TSC. None other time counters have problems with > C-states. It is the timecounter code that needs reinitializing. If the TSC stops, or wraps mod 2**32, then its counts become garbage for the purpose of timecounting. Maybe it is not used for timecounting in either of these cases. But these cases shouldn't prevent its use for timecounting. The 2**32 number is because timecounters only use 32 bits of hardware counters (for efficiency). So even if the hardware has some magic to not stop the TSC while sleeping (maybe it fakes not stopping it be reloading on wakeup), it is still unusable by timecounters after sleeping for a second or 2 so that it wraps. The software needs similar faking to reload the timecounter on wakeup. This makes use of timecounters in sleep/wakeup code fragile. At boot time there is a dummy timecounter that returns bogo-times. Apparently sleeping doesn't occur before the timecounter is switched to a real one. The dummy timecounter isn't switched back to after boot time. But it probably should be, since the hardware timecounter may have stopped or wrapped. Sleeping could just set a flag to indicate this state, but then you would have to provide a fake time anyway on finding the flag set. Boot time just points to the dummy timecounter so as not to check this flag in all early timecounter "hardware" calls. Bruce From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 30 06:25:27 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4999106566B for ; Mon, 30 Jul 2012 06:25:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 272588FC16 for ; Mon, 30 Jul 2012 06:25:26 +0000 (UTC) Received: by weyx56 with SMTP id x56so4013427wey.13 for ; Sun, 29 Jul 2012 23:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/X1bUd9kFHP354cOIxk10bzWgIKidU3ao2C5oHg85CY=; b=A9mUdoCD1XURnQCFhgTJQB+RqAAEy6Bi295ZLq60ScHLgTRsddWlWUqKiqqF5CvMas eb/0CgFN9J2gQMs3l2ort6f/tEg7BBQmrTflogxFfsp92LiPkLZlQARwR7pb+NuX2feE giIJBiIqD6Bl6h42fsTggjXNyKgHad2K2eLUxyr7vsZkLxN2ZR8O6KFtnfCltFzW2j6X IzxAXMqfW2EmSWrshNb4JlddVFyPM5PdJQBvlLIR2EQz0FskkgwgwusMX0oY1V3RUPGS 4nEP2ZqbgZclb0jm7vSCQtH488dQfbPaxAwW2tM4EAnkdIQ76dDx1GOnY+EHxoeb9dpx n59Q== Received: by 10.180.100.133 with SMTP id ey5mr23999157wib.4.1343629526071; Sun, 29 Jul 2012 23:25:26 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id h9sm14883468wiz.1.2012.07.29.23.25.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Jul 2012 23:25:25 -0700 (PDT) Sender: Alexander Motin Message-ID: <501628D2.2090507@FreeBSD.org> Date: Mon, 30 Jul 2012 09:25:22 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@FreeBSD.org> <20120729221526.H2941@besplex.bde.org> <50154C58.4060408@FreeBSD.org> <20120730141426.D1219@besplex.bde.org> In-Reply-To: <20120730141426.D1219@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 06:25:27 -0000 On 30.07.2012 07:33, Bruce Evans wrote: > On Sun, 29 Jul 2012, Alexander Motin wrote: > >> On 29.07.2012 15:26, Bruce Evans wrote: >>> On Sun, 29 Jul 2012, Alexander Motin wrote: >>> >>>> On 29.07.2012 11:37, Bruce Evans wrote: >>>> ... >>>>> binuptime() is more accurate than uncalibrated scaling. Is accuracy >>>>> required? >>>> >>>> Accuracy is not required at all. +-20% is not a problem. >>>> >>>>> If not, the CPU ticker might work, and is faster than HPET, >>>>> and and is not under user control for perverse settings. It normally >>>>> reduces to readtsc() with no serializing instruction even in proposed >>>>> changes. This is good enough for process times (not very good) and >>>>> depends on the CPU not changing. Its calibration is very accurate >>>>> (similar to timecounters) modulo bugs, but not always up to date. >>>> >>>> Problem with ticker that it may stop during idle periods, and idle is >>>> exactly what happens here. Unlike timecounter usage here we don't need >>>> CPU synchronicity, but we need it working during deep sleeps. >>> >>> The ticker is the same as the timecounter in many cases of interest. If >>> the TSC stops then it cannot be used for timecounting unless >>> timecounting >>> is reinitialized. Timecounting should be reinitialized after deep >>> sleeps, >>> but you say you need it to work during deep sleeps. >> >> Timecounter already has detection logic to disable TSC in cases where >> it is unreliable. I don't want to replicate it here. I need not >> precise and not synchronized by reliable and fast time source. > > Yes, this logic gives exactly what you don't want (an inefficient > timecounter), by preventing use of the TSC for the timecounter, although > the TSC is perfectly usable for the ticker and here. Can you teach me how to use ticker that is not ticking? If TSC was considered unusable for timecounter for reasons unrelated to SMP, how can I use it as ticker. >>> I wouldn't trust timecounters for some time after waking up after a >>> deep sleep. If their clock stopped then the times read might only be >>> very out of date. If their clock didn't stop, then they might have >>> wrapped or otherwise overflowed and the times read would be garbage. >>> Is there any locking or ordering to prevent them being used before they >>> are reinitialized? >> >> I am not sure what reinitialization are you talking about. IIRC, there >> is no any waking up code for TSC. None other time counters have >> problems with C-states. > > It is the timecounter code that needs reinitializing. If the TSC stops, > or wraps mod 2**32, then its counts become garbage for the purpose of > timecounting. Maybe it is not used for timecounting in either of these > cases. But these cases shouldn't prevent its use for timecounting. > > The 2**32 number is because timecounters only use 32 bits of hardware > counters (for efficiency). So even if the hardware has some magic to > not stop the TSC while sleeping (maybe it fakes not stopping it be > reloading on wakeup), it is still unusable by timecounters after sleeping > for a second or 2 so that it wraps. The software needs similar faking > to reload the timecounter on wakeup. This makes use of timecounters in > sleep/wakeup code fragile. At this moment I am not talking about S-states sleeping for hours. I am talking about C-states for milliseconds. It means that TSC may stop and start 10K times each second or even more. Attempt to save and restore its state will consume so much resources, that probably make it useless. What's about wrap after 2 seconds, I would be happy to make CPU sleep for so long, but now 100ms is all I can hope even on idle system. > At boot time there is a dummy timecounter that returns bogo-times. > Apparently sleeping doesn't occur before the timecounter is switched to > a real one. The dummy timecounter isn't switched back to after boot > time. But it probably should be, since the hardware timecounter may > have stopped or wrapped. Sleeping could just set a flag to indicate > this state, but then you would have to provide a fake time anyway on > finding the flag set. Boot time just points to the dummy timecounter > so as not to check this flag in all early timecounter "hardware" calls. And how dummy timecounter that counts something, but not time, can help me to measure sleep time? -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 30 07:14:44 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B35CB1065687 for ; Mon, 30 Jul 2012 07:14:44 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 399C58FC19 for ; Mon, 30 Jul 2012 07:14:44 +0000 (UTC) Received: by weyx56 with SMTP id x56so4042006wey.13 for ; Mon, 30 Jul 2012 00:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kRJ+9n3bVlp8XRY/xqEU/2RKghoDSvLt6i0nzvvELP0=; b=WzvX/Sqh1ue+ljudjmCWT3qhAmTYrgOPcggUmmjoHIu4tfUbFsrgUHCEE/eAnFUrY0 sLJkI2n+jUgLzhq6QC0F8rJLKJHDjfz3p20dvTw9cuvsZJ9caMr3M+ACvBHyPrEMkp+V EDn07RULuk2AdhCD77jEP40c9YU8oHZKP+gHmKFOUpClIAU9GkRbYu2K9XXKsU+96Pd3 c6dVuWMDrQBho8rQy6Ko7BmP24alIdNbxfQF9SyS9Ziu241kZtNYhBw2qhTG9RKen2qm 0qTadLmyuhW7zfVRHC0fa593oKuRmluk4cdm4bt2kmAq3YnhVCb2G2eN/f9T5VNJu3am mrhQ== Received: by 10.180.98.138 with SMTP id ei10mr24238827wib.1.1343632483392; Mon, 30 Jul 2012 00:14:43 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id l5sm22164363wix.5.2012.07.30.00.14.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Jul 2012 00:14:42 -0700 (PDT) Sender: Alexander Motin Message-ID: <50163460.6070508@FreeBSD.org> Date: Mon, 30 Jul 2012 10:14:40 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120628 Thunderbird/13.0.1 MIME-Version: 1.0 To: Bruce Evans References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@FreeBSD.org> <20120729221526.H2941@besplex.bde.org> <50154C58.4060408@FreeBSD.org> <20120730141426.D1219@besplex.bde.org> <501628D2.2090507@FreeBSD.org> In-Reply-To: <501628D2.2090507@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 07:14:44 -0000 On 30.07.2012 09:25, Alexander Motin wrote: > On 30.07.2012 07:33, Bruce Evans wrote: >> On Sun, 29 Jul 2012, Alexander Motin wrote: >> >>> On 29.07.2012 15:26, Bruce Evans wrote: >>>> On Sun, 29 Jul 2012, Alexander Motin wrote: >>>> >>>>> On 29.07.2012 11:37, Bruce Evans wrote: >>>>> ... >>>>>> binuptime() is more accurate than uncalibrated scaling. Is accuracy >>>>>> required? >>>>> >>>>> Accuracy is not required at all. +-20% is not a problem. >>>>> >>>>>> If not, the CPU ticker might work, and is faster than HPET, >>>>>> and and is not under user control for perverse settings. It normally >>>>>> reduces to readtsc() with no serializing instruction even in proposed >>>>>> changes. This is good enough for process times (not very good) and >>>>>> depends on the CPU not changing. Its calibration is very accurate >>>>>> (similar to timecounters) modulo bugs, but not always up to date. >>>>> >>>>> Problem with ticker that it may stop during idle periods, and idle is >>>>> exactly what happens here. Unlike timecounter usage here we don't need >>>>> CPU synchronicity, but we need it working during deep sleeps. >>>> >>>> The ticker is the same as the timecounter in many cases of >>>> interest. If >>>> the TSC stops then it cannot be used for timecounting unless >>>> timecounting >>>> is reinitialized. Timecounting should be reinitialized after deep >>>> sleeps, >>>> but you say you need it to work during deep sleeps. >>> >>> Timecounter already has detection logic to disable TSC in cases where >>> it is unreliable. I don't want to replicate it here. I need not >>> precise and not synchronized by reliable and fast time source. >> >> Yes, this logic gives exactly what you don't want (an inefficient >> timecounter), by preventing use of the TSC for the timecounter, although >> the TSC is perfectly usable for the ticker and here. > > Can you teach me how to use ticker that is not ticking? If TSC was > considered unusable for timecounter for reasons unrelated to SMP, how > can I use it as ticker. > >>>> I wouldn't trust timecounters for some time after waking up after a >>>> deep sleep. If their clock stopped then the times read might only be >>>> very out of date. If their clock didn't stop, then they might have >>>> wrapped or otherwise overflowed and the times read would be garbage. >>>> Is there any locking or ordering to prevent them being used before they >>>> are reinitialized? >>> >>> I am not sure what reinitialization are you talking about. IIRC, there >>> is no any waking up code for TSC. None other time counters have >>> problems with C-states. >> >> It is the timecounter code that needs reinitializing. If the TSC stops, >> or wraps mod 2**32, then its counts become garbage for the purpose of >> timecounting. Maybe it is not used for timecounting in either of these >> cases. But these cases shouldn't prevent its use for timecounting. >> >> The 2**32 number is because timecounters only use 32 bits of hardware >> counters (for efficiency). So even if the hardware has some magic to >> not stop the TSC while sleeping (maybe it fakes not stopping it be >> reloading on wakeup), it is still unusable by timecounters after sleeping >> for a second or 2 so that it wraps. The software needs similar faking >> to reload the timecounter on wakeup. This makes use of timecounters in >> sleep/wakeup code fragile. > > At this moment I am not talking about S-states sleeping for hours. I am > talking about C-states for milliseconds. It means that TSC may stop and > start 10K times each second or even more. Attempt to save and restore > its state will consume so much resources, that probably make it useless. > > What's about wrap after 2 seconds, I would be happy to make CPU sleep > for so long, but now 100ms is all I can hope even on idle system. > >> At boot time there is a dummy timecounter that returns bogo-times. >> Apparently sleeping doesn't occur before the timecounter is switched to >> a real one. The dummy timecounter isn't switched back to after boot >> time. But it probably should be, since the hardware timecounter may >> have stopped or wrapped. Sleeping could just set a flag to indicate >> this state, but then you would have to provide a fake time anyway on >> finding the flag set. Boot time just points to the dummy timecounter >> so as not to check this flag in all early timecounter "hardware" calls. > > And how dummy timecounter that counts something, but not time, can help > me to measure sleep time? Nevermind, let it be compromise solution -- ticker for C1 state where performance is the most important and where TSC works and ACPI timer for others. -- Alexander Motin From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 30 08:55:57 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53717106566B; Mon, 30 Jul 2012 08:55:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id BE2908FC08; Mon, 30 Jul 2012 08:55:56 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6U8tkcJ007031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 18:55:47 +1000 Date: Mon, 30 Jul 2012 18:55:46 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin In-Reply-To: <501628D2.2090507@FreeBSD.org> Message-ID: <20120730171246.Y1715@besplex.bde.org> References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@FreeBSD.org> <20120729221526.H2941@besplex.bde.org> <50154C58.4060408@FreeBSD.org> <20120730141426.D1219@besplex.bde.org> <501628D2.2090507@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@FreeBSD.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 08:55:57 -0000 On Mon, 30 Jul 2012, Alexander Motin wrote: > On 30.07.2012 07:33, Bruce Evans wrote: >> On Sun, 29 Jul 2012, Alexander Motin wrote: >>> ... >>> Timecounter already has detection logic to disable TSC in cases where >>> it is unreliable. I don't want to replicate it here. I need not >>> precise and not synchronized by reliable and fast time source. >> >> Yes, this logic gives exactly what you don't want (an inefficient >> timecounter), by preventing use of the TSC for the timecounter, although >> the TSC is perfectly usable for the ticker and here. > > Can you teach me how to use ticker that is not ticking? If TSC was considered > unusable for timecounter for reasons unrelated to SMP, how can I use it as > ticker. No :-). I can't teach you how to use either the ticker or the timecounter if their clock is not ticking. I'm just saying that if you use can blindly use a timecounter, then you can blindly use the ticker. The working of both depends on their clock not stopping ticking, and that in many cases their clock is the same (the TSC). The TSC is considered usable for the ticker under weak conditions: - it exists according to CPUID_TSC - it is not disabled by the machdep.disable_tsc tuneable - its dynamic probe finds that its frequency is nonzero. The probe has some more cpuid tests and other complications which may prevent it being fuly dynamic. There is another tuneable, machdep.disable_tsc_calibration which prevents the dynamic frequency determination. I think the frequency comes from a table then, and is never zero, so this doesn't prevent the TSC being used for the ticker. - the 2 tuneables are of course undocumented in /usr/share/man. There is hardly any useful documentation of the TSC there either. zgrep finds "TSC" mainly in timercounters(4) and hwpmc(4). In timecounters(4), the references to the TSC are useless since they are just literal output of $(sysctl kern.timecounter). In hwpmc(4), the READTSC instruction but not much more is mentioned. The TSC is considered usable for a timecounter under the above conditions, but its default quality is low so it rarely gets used. Its quality is changed under the following conditions: - APM enabled: reduce quality to nearly -infinity - CPU can deep sleep, and Intel CPU, and TSC not invariant: reduce quality to nearly -infinity, because (only) Intel CPUs are known to stop the TSC in deep sleeps under these conditions. This is what you should have told me to justify use of binuptime() :-). Users can still configure the TSC as a timecounter, but this would break more than your use of binuptime() if the TSC actually stops. - SMP configured, and > 1 CPU: - vm guest: reduce quality significantly, but not to nearly -infinity - else do cpuid and dynamic synchronization tests: - fail tests: reduce as for vm guest - pass tests: increase a little, to just above ACPI-fast IIRC - pass synchronization tests, but not invariant: keep default. - SMP not configured, or only 1 CPU: increase a little iff invariant. Invariant means P-state invariant. I forgot that the invariance flag was a tuneable. This tuneable, kern.timecounter.tsc_invariant, is of course undocumented. It conditionalizes more than this case. Other bugs in it are: - it is in a different namespace than the tuneables described above. - this different namespace is worse, since the flag applies to more than the timecounter decision. It also gives the ticker invariance, flag and controls whether there are event handlers for frequency changes. - you can force the flag on using the tuneable, but you can't force it off. - for SMP, there is also the kern.timecounter.smp tunable. This has much the same bugs as kern.timecounter.tsc_invariant: - it is of course undocumented - you can force it on, but you can't force it off - however, its namespace seems to be not incorrect, since it seems to only control timecounter quality (very indirectly now, by modifying the dynamic probes. It used to be a simple flag to modify the SMP config option). Stopping of the TSC in deep sleeps doesn't prevent its use as the ticker. This should mostly work for the main use of the ticker, for thread runtimes, because most threads never idle directly, but switch to the idle thread for some CPU. I think deep sleeps break runtime accounting for idle threads (if the ticker stops). Has anyone seen this (idle times near 0 on mostly-idle systems that have spent days idling)? >>>> I wouldn't trust timecounters for some time after waking up after a >>>> deep sleep. If their clock stopped then the times read might only be >>>> ... >>> I am not sure what reinitialization are you talking about. IIRC, there >>> is no any waking up code for TSC. None other time counters have >>> problems with C-states. >> >> It is the timecounter code that needs reinitializing. If the TSC stops, >> or wraps mod 2**32, then its counts become garbage for the purpose of >> timecounting. Maybe it is not used for timecounting in either of these >> cases. But these cases shouldn't prevent its use for timecounting. > ... > At this moment I am not talking about S-states sleeping for hours. I am > talking about C-states for milliseconds. It means that TSC may stop and start > 10K times each second or even more. Attempt to save and restore its state > will consume so much resources, that probably make it useless. You should have told me the lengths of the sleeps early in this thread :-). I only know enough about this to ask annoying questions. > What's about wrap after 2 seconds, I would be happy to make CPU sleep for so > long, but now 100ms is all I can hope even on idle system. Covered by the above, but future-proofing requires supporting arbitrary sleep lengths. Use a less efficient timer that works over long sleeps iff the sleep was long. The problems are to determine whether the sleep was long, and to switch timers. >> At boot time there is a dummy timecounter that returns bogo-times. >> Apparently sleeping doesn't occur before the timecounter is switched to >> a real one. The dummy timecounter isn't switched back to after boot >> time. But it probably should be, since the hardware timecounter may >> have stopped or wrapped. Sleeping could just set a flag to indicate >> this state, but then you would have to provide a fake time anyway on >> finding the flag set. Boot time just points to the dummy timecounter >> so as not to check this flag in all early timecounter "hardware" calls. > > And how dummy timecounter that counts something, but not time, can help me to > measure sleep time? It helps negatively. You can't use a dummy timecounter any more than you can used a stopped or wrapped timecounter if you actually need to know the time. In low-level code it is unclear whether timecounters can be used. Where binuptime() can be used is of course undocumented. binuptime() actually has a man page, but it is just a stub. Timecounters actually can be used in most low-level code, partly because they need to work in fast interrupt handlers for PPS timestamps, but I wouldn't want to make their normal use slower to support this. Bruce From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 30 09:15:10 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F05B106566C; Mon, 30 Jul 2012 09:15:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id D3B6D8FC14; Mon, 30 Jul 2012 09:15:09 +0000 (UTC) Received: from c122-106-171-246.carlnfd1.nsw.optusnet.com.au (c122-106-171-246.carlnfd1.nsw.optusnet.com.au [122.106.171.246]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q6U9F2Qt017581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 19:15:05 +1000 Date: Mon, 30 Jul 2012 19:15:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Motin In-Reply-To: <50163460.6070508@FreeBSD.org> Message-ID: <20120730190631.K2020@besplex.bde.org> References: <5014DD00.3000307@FreeBSD.org> <20120729175031.U2084@besplex.bde.org> <50150CF5.4070605@FreeBSD.org> <20120729221526.H2941@besplex.bde.org> <50154C58.4060408@FreeBSD.org> <20120730141426.D1219@besplex.bde.org> <501628D2.2090507@FreeBSD.org> <50163460.6070508@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-acpi@freebsd.org Subject: Re: Using bintime() in acpi_cpu_idle()? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 09:15:10 -0000 On Mon, 30 Jul 2012, Alexander Motin wrote: >[>...] ... > Nevermind, let it be compromise solution -- ticker for C1 state where > performance is the most important and where TSC works and ACPI timer for > others. I like that. Something similar should work for making the TSC usable in timecounters even if it stops during deep sleeps. The timecounter hardware would have to be switched or reinitalized if it might have stopped. Bruce From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 30 11:07:07 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2122106567F for ; Mon, 30 Jul 2012 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A262A8FC27 for ; Mon, 30 Jul 2012 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q6UB77Be001681 for ; Mon, 30 Jul 2012 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q6UB77F8001679 for freebsd-acpi@FreeBSD.org; Mon, 30 Jul 2012 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Jul 2012 11:07:07 GMT Message-Id: <201207301107.q6UB77F8001679@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 11:07:07 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o bin/126162 acpi [acpi] ACPI autoload failed : loading required module o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 31 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 30 18:04:36 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C62611065674; Mon, 30 Jul 2012 18:04:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8028FC08; Mon, 30 Jul 2012 18:04:36 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 07917B944; Mon, 30 Jul 2012 14:04:36 -0400 (EDT) From: John Baldwin To: freebsd-acpi@freebsd.org, sbruno@freebsd.org Date: Mon, 30 Jul 2012 08:07:20 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <1342730963.2656.5.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1342730963.2656.5.camel@powernoodle.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201207300807.20225.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 30 Jul 2012 14:04:36 -0400 (EDT) Cc: Subject: Re: Time to increase MAX_TASKS? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:04:36 -0000 On Thursday, July 19, 2012 4:49:23 pm Sean Bruno wrote: > The new Dell machines are doing a lot more of outstanding ACPI "things" > currently. So much in fact, that they are exceeding ACPI_MAX_TASKS and > are throwing errors indicating thing: > > > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on > isa0 > AcpiOsExecute: failed to enqueue task, consider increasing the > debug.acpi.max_tasks tunable > AcpiOsExecute: failed to enqueue task, consider increasing the > debug.acpi.max_tasks tunable > est0: on cpu0 > .....imecounters tick every 1.000 msec > smbios: System Management BIOS version 2.7 > Profiling kernel, textsize=6861200 [ffffffff8029b190..ffffffff80926320] > usbus0: 480Mbps High Speed USB v2.0 > usbus1: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ipmi0: IPMI device rev. 1, firmware rev. 1.10, version 2.0 > ipmi0: Number of channels 6 > ipmi0: Attached watchdog > AcpiOsExecute: failed to enqueue task, consider increasing the > debug.acpi.max_tasks tunable > mfid0 on mfi0 > > > the current value in sys/dev/acpica/acpivar.h of 32 is no longer > sufficient on the r420/r320 Sandybridge class of box. > > I am currently running with a value of 128 and doing a bit of testing. I think it should be something like MAX(32, MAXCPU). -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 31 03:19:57 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9BC13106566B; Tue, 31 Jul 2012 03:19:57 +0000 (UTC) (envelope-from takawata@init-main.com) Received: from sana.init-main.com (unknown [IPv6:2001:240:28::1]) by mx1.freebsd.org (Postfix) with ESMTP id 1B6488FC0C; Tue, 31 Jul 2012 03:19:56 +0000 (UTC) Received: from ns.init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.14.3/8.14.3) with ESMTP id q6V3JC6a014526; Tue, 31 Jul 2012 12:19:12 +0900 (JST) (envelope-from takawata@ns.init-main.com) Message-Id: <201207310319.q6V3JC6a014526@sana.init-main.com> To: freebsd-acpi@freebsd.org, freebsd-usb@freebsd.org Date: Tue, 31 Jul 2012 12:19:12 +0900 From: Takanori Watanabe Cc: Subject: USB ACPI namespace mapping. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 03:19:57 -0000 I'm trying to map USB devices and hub into acpi handle, and I want ideas to cope with a problem. The problem is that there is no easy way to get port number from child usb device in hub device. usb_attach_arg structure have one, but invalidate after probe and attach. And, furthermore, which device_t instance should I register to acpi device handle to cope with ACPI docking station framework. The code I wrote is as follows. Index: usb_hub.c =================================================================== --- usb_hub.c (revision 238557) +++ usb_hub.c (working copy) @@ -69,10 +69,11 @@ #include #include +#include #define UHUB_INTR_INTERVAL 250 /* ms */ -#define UHUB_N_TRANSFER 1 + #ifdef USB_DEBUG static int uhub_debug = 0; @@ -90,42 +91,15 @@ &usb_power_timeout, 0, "USB power timeout"); #endif -struct uhub_current_state { - uint16_t port_change; - uint16_t port_status; -}; - -struct uhub_softc { - struct uhub_current_state sc_st;/* current state */ - device_t sc_dev; /* base device */ - struct mtx sc_mtx; /* our mutex */ - struct usb_device *sc_udev; /* USB device */ - struct usb_xfer *sc_xfer[UHUB_N_TRANSFER]; /* interrupt xfer */ - uint8_t sc_flags; -#define UHUB_FLAG_DID_EXPLORE 0x01 - char sc_name[32]; -}; - #define UHUB_PROTO(sc) ((sc)->sc_udev->ddesc.bDeviceProtocol) #define UHUB_IS_HIGH_SPEED(sc) (UHUB_PROTO(sc) != UDPROTO_FSHUB) #define UHUB_IS_SINGLE_TT(sc) (UHUB_PROTO(sc) == UDPROTO_HSHUBSTT) #define UHUB_IS_MULTI_TT(sc) (UHUB_PROTO(sc) == UDPROTO_HSHUBMTT) #define UHUB_IS_SUPER_SPEED(sc) (UHUB_PROTO(sc) == UDPROTO_SSHUB) -/* prototypes for type checking: */ - -static device_probe_t uhub_probe; -static device_attach_t uhub_attach; -static device_detach_t uhub_detach; -static device_suspend_t uhub_suspend; -static device_resume_t uhub_resume; - -static bus_driver_added_t uhub_driver_added; -static bus_child_location_str_t uhub_child_location_string; -static bus_child_pnpinfo_str_t uhub_child_pnpinfo_string; - static usb_callback_t uhub_intr_callback; + static void usb_dev_resume_peer(struct usb_device *udev); static void usb_dev_suspend_peer(struct usb_device *udev); static uint8_t usb_peer_should_wakeup(struct usb_device *udev); @@ -164,7 +138,7 @@ {0, 0} }; -static driver_t uhub_driver = { +driver_t uhub_driver = { .name = "uhub", .methods = uhub_methods, .size = sizeof(struct uhub_softc) @@ -821,8 +795,7 @@ return (USB_ERR_NORMAL_COMPLETION); } -static int -uhub_probe(device_t dev) +int uhub_probe(device_t dev) { struct usb_attach_arg *uaa = device_get_ivars(dev); @@ -835,7 +808,7 @@ */ if (uaa->info.bConfigIndex == 0 && uaa->info.bDeviceClass == UDCLASS_HUB) - return (0); + return (BUS_PROBE_GENERIC); return (ENXIO); } @@ -900,8 +873,7 @@ return (err); } - -static int +int uhub_attach(device_t dev) { struct uhub_softc *sc = device_get_softc(dev); @@ -1204,7 +1176,8 @@ * Called from process context when the hub is gone. * Detach all devices on active ports. */ -static int + +int uhub_detach(device_t dev) { struct uhub_softc *sc = device_get_softc(dev); @@ -1241,7 +1214,7 @@ return (0); } -static int +int uhub_suspend(device_t dev) { DPRINTF("\n"); @@ -1249,7 +1222,7 @@ return (0); } -static int +int uhub_resume(device_t dev) { DPRINTF("\n"); @@ -1257,7 +1230,7 @@ return (0); } -static void +void uhub_driver_added(device_t dev, driver_t *driver) { usb_needs_explore_all(); @@ -1302,7 +1275,7 @@ res->portno = 0; } -static int +int uhub_child_location_string(device_t parent, device_t child, char *buf, size_t buflen) { @@ -1338,7 +1311,7 @@ return (0); } -static int +int uhub_child_pnpinfo_string(device_t parent, device_t child, char *buf, size_t buflen) { Index: usb_hub_acpi.c =================================================================== --- usb_hub_acpi.c (revision 0) +++ usb_hub_acpi.c (revision 0) @@ -0,0 +1,237 @@ +/*- + * Copyright (c) 2012 Takanori Watanabe + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include +#include + + +#define MAX_PORT 32 + +struct uhub_acpi_softc{ + struct uhub_softc base; /*must be first member*/ + ACPI_HANDLE hub_handle; + ACPI_HANDLE port_handle[MAX_PORT]; +}; + +static int +uhub_acpi_read_ivar(device_t dev, device_t child, int which, uintptr_t *result) +{ + struct uhub_acpi_softc *sc = device_get_softc(dev); + struct usb_attach_arg *ivars = device_get_ivars(child); + + switch (which) { + case ACPI_IVAR_HANDLE: +#if 0 /*XXX*/ + *result = (uintptr_t)sc->port_handle[ivars->port]; +#endif + return (0); + } + return ENXIO; +} + +static ACPI_STATUS uhub_acpi_port_probe(ACPI_HANDLE handle, UINT32 level, void *context, void **status) +{ + ACPI_DEVICE_INFO *devinfo; + device_t dev =(device_t)context; + struct uhub_acpi_softc *sc = device_get_softc(dev); + + + if(AcpiGetObjectInfo(handle, &devinfo)) + return AE_OK; + if(!(devinfo->Valid&ACPI_VALID_ADR)){ + return AE_OK; + } + if(devinfo->Address == 0){ + device_printf(dev, "port 0 is root hub only\n"); + return AE_OK; + } + + if(devinfo->Address > MAX_PORT){ + device_printf(dev, "Too high port in the hub %lld\n", + devinfo->Address); + return AE_OK; + } + device_printf(dev, "%s at port %lld\n", acpi_name(handle), + devinfo->Address); + sc->port_handle[devinfo->Address -1] = handle; + + return AE_OK; +} + +static ACPI_STATUS uhub_root_acpi_handle(ACPI_HANDLE handle, UINT32 level, void *context, void **status) +{ + ACPI_DEVICE_INFO *devinfo; + + *status = NULL; + + if(AcpiGetObjectInfo(handle, &devinfo)) + return AE_OK; + if(!(devinfo->Valid&ACPI_VALID_ADR)){ + return AE_OK; + } + if(devinfo->Address != 0){ + printf("Non zero Address for root hub %llx\n", + devinfo->Address); + return AE_OK; + } + *status = (void *)handle; + return AE_CTRL_TERMINATE; +} + +static ACPI_HANDLE uhub_acpi_my_handle(device_t dev) +{ + + ACPI_HANDLE h,childh; + + if(strcmp(device_get_name(device_get_parent(dev)), "usbus") ==0){ + h = acpi_get_handle(device_get_parent(device_get_parent(dev))); + AcpiWalkNamespace(ACPI_TYPE_DEVICE, h, 1, + uhub_root_acpi_handle, + NULL,dev, &childh); + + }else{ + childh = acpi_get_handle(dev); + } + + return childh; +} + +static int +uhub_acpi_probe(device_t dev) +{ + struct usb_attach_arg *uaa = device_get_ivars(dev); + + if (uaa->usb_mode != USB_MODE_HOST) + return (ENXIO); + + + if(uhub_acpi_my_handle(dev) == NULL){ + return ENXIO; + } + device_printf(dev, "ACPI capable\n"); + /* + * The subclass for USB HUBs is currently ignored because it + * is 0 for some and 1 for others. + */ + + if (uaa->info.bConfigIndex == 0 && + uaa->info.bDeviceClass == UDCLASS_HUB){ + return (0); + } + + return (ENXIO); +} +static int uhub_acpi_attach(device_t dev) +{ + struct uhub_acpi_softc *sc = device_get_softc(dev); + sc->hub_handle = uhub_acpi_my_handle(dev); + device_printf(dev, "PATH:%s\n", acpi_name(sc->hub_handle)); + + AcpiWalkNamespace(ACPI_TYPE_DEVICE, sc->hub_handle, 1, + uhub_acpi_port_probe, + NULL,dev, NULL); + + + return uhub_attach(dev); +} + + +static int +uhub_acpi_child_location_string(device_t parent, device_t child, + char *buf, size_t buflen) +{ + + int len = 0; +#if 0 /*XXX*/ + struct uhub_acpi_softc *sc = device_get_softc(child); + struct usb_attach_arg *uaa = device_get_ivars(child); + + len = snprintf(buf, buflen, + "handle=%s ", acpi_name(sc->port_handle[uaa->port])); +#endif + return uhub_child_location_string(parent, child, + buf + len, buflen - len); +} + + +static device_method_t uhub_acpi_methods[] = { + DEVMETHOD(device_probe, uhub_acpi_probe), + DEVMETHOD(device_attach, uhub_acpi_attach), + + DEVMETHOD(bus_read_ivar, uhub_acpi_read_ivar), + DEVMETHOD(bus_child_location_str, uhub_acpi_child_location_string), + + {0, 0} +}; + +static devclass_t uhub_devclass; +DECLARE_CLASS(uhub_driver); + +DEFINE_CLASS_1(uhub, uhub_acpi_driver, uhub_acpi_methods, + sizeof(struct uhub_acpi_softc),uhub_driver); + +DRIVER_MODULE(uhub_acpi, usbus, uhub_acpi_driver, uhub_devclass, 0, 0); +DRIVER_MODULE(uhub_acpi, uhub, uhub_acpi_driver, uhub_devclass, NULL, 0); Index: usb_hub_private.h =================================================================== --- usb_hub_private.h (revision 0) +++ usb_hub_private.h (revision 0) @@ -0,0 +1,59 @@ +/*- + * Copyright (c) 2012 Takanori Watanabe + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + */ + +#ifndef _USB_HUB_PRIVATE_H +#define _USB_HUB_PRIVATE_H + +#define UHUB_N_TRANSFER 1 +struct uhub_current_state { + uint16_t port_change; + uint16_t port_status; +}; + +struct uhub_softc { + struct uhub_current_state sc_st;/* current state */ + device_t sc_dev; /* base device */ + struct mtx sc_mtx; /* our mutex */ + struct usb_device *sc_udev; /* USB device */ + struct usb_xfer *sc_xfer[UHUB_N_TRANSFER]; /* interrupt xfer */ + uint8_t sc_flags; +#define UHUB_FLAG_DID_EXPLORE 0x01 + char sc_name[32]; +}; + + +device_probe_t uhub_probe; +device_attach_t uhub_attach; +device_detach_t uhub_detach; +device_suspend_t uhub_suspend; +device_resume_t uhub_resume; + +bus_driver_added_t uhub_driver_added; +bus_child_location_str_t uhub_child_location_string; +bus_child_pnpinfo_str_t uhub_child_pnpinfo_string; + +#endif From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 31 16:14:11 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E78A10657CC; Tue, 31 Jul 2012 16:14:11 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id C33AD8FC0C; Tue, 31 Jul 2012 16:14:10 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q6VGD8IN011508; Tue, 31 Jul 2012 09:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1343751189; bh=1gR2HVG3NgGA85pO/NEr+iniDP3r14z1kc3ts/U8Tr0=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=pXJSMEBGXtc7WM7O6pllPaJHsMBnH43bri2/nYrkrelcr1yZVYdnoncFDmjx4VD/s nvWIZYhN/1WibNjvXKPp7DvclMMzVwoHFXCJFb1EZ94iTe3G1FcA5DPQTB5C8kzCpd S3JM1o4Wl97JjhspUCJ1AnK1Z+rMftk/c6WnrBuw= From: Sean Bruno To: John Baldwin In-Reply-To: <201207300807.20225.jhb@freebsd.org> References: <1342730963.2656.5.camel@powernoodle.corp.yahoo.com> <201207300807.20225.jhb@freebsd.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 31 Jul 2012 09:13:07 -0700 Message-ID: <1343751187.2957.4.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 751188004 Cc: "freebsd-acpi@freebsd.org" Subject: Re: Time to increase MAX_TASKS? X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 16:14:11 -0000 On Mon, 2012-07-30 at 05:07 -0700, John Baldwin wrote: > > I am currently running with a value of 128 and doing a bit of > testing. > > I think it should be something like MAX(32, MAXCPU). Ah, that sounds WAY more reasonable. I shall test thusly. Sean From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 31 20:08:43 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8B8C1065670; Tue, 31 Jul 2012 20:08:43 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id 292F08FC1B; Tue, 31 Jul 2012 20:08:42 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 136265463; Tue, 31 Jul 2012 22:08:36 +0200 From: Hans Petter Selasky To: freebsd-acpi@freebsd.org Date: Tue, 31 Jul 2012 22:08:55 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201207310319.q6V3JC6a014526@sana.init-main.com> In-Reply-To: <201207310319.q6V3JC6a014526@sana.init-main.com> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201207312208.55871.hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: USB ACPI namespace mapping. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:08:43 -0000 On Tuesday 31 July 2012 05:19:12 Takanori Watanabe wrote: > I'm trying to map USB devices and hub into acpi handle, > and I want ideas to cope with a problem. > > The problem is that there is no easy way to get port number from > child usb device in hub device. > usb_attach_arg structure have one, but invalidate after probe and attach. > > And, furthermore, which device_t instance should I register to acpi > device handle to cope with ACPI docking station framework. > > The code I wrote is as follows. > Hi, In userspace there is: man libusb20_dev_get_parent_port Most of the information you need is supplied via either devd, or an IOCTL request on the ugen device: #define USB_DEVICEINFO _IOWR('U', 4, struct usb_device_info) ... uint8_t udi_hubaddr; /* parent HUB address */ uint8_t udi_hubindex; /* parent HUB device index */ uint8_t udi_hubport; /* parent HUB port */ ... Check how the DEVICEINFO IOCTL is implemented and you will see how the current port numbers are computed. Important: Don't forget that the USB stack is multithreaded! And that you need to lock resources before accessing them! Do you need more info than this? --HPS From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 1 17:07:33 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65217106564A for ; Wed, 1 Aug 2012 17:07:33 +0000 (UTC) (envelope-from honestqiao@gmail.com) Received: from mail-gg0-f182.google.com (mail-gg0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1520A8FC24 for ; Wed, 1 Aug 2012 17:07:32 +0000 (UTC) Received: by ggnk4 with SMTP id k4so807247ggn.13 for ; Wed, 01 Aug 2012 10:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:x-priority:x-has-attach:x-mailer :mime-version:message-id:content-type:content-transfer-encoding; bh=ALEWzqsTGQeMB4oX2LACX7J4xo0b5wdSu/YdoOn8VQg=; b=HxmCq/eKZ5JcdKaR3UImD2D1t5kttX9mRDf/04paqh5iSQAeAOSh8LEKw/mIBU5AiJ Nr6CQfxcA00zXyo+Tpaxq3pvGklytHWu3QZpwSAPrpNUopQk05IHG4k5yw9tOMmHrvta Neyvr/l1GNv2pXTajWBnldhnm4QOL4WXOLO76EQK8P10dbk3vo5/XRwSvFOAxlQpgLQ4 /U0Sl+FwhKry4Uacv2qsEcnIC6cRrFLqt1P2WqUlI6SCP1nd+tUiCUJCmcd6gxXy7RI4 RN7DG5VXR1bH3Q4IHCTrgWfxGA/BPIqQo2RHALYAkQudPGUQje8fygdvt9NZ/pBYLvPH M+5g== Received: by 10.66.83.65 with SMTP id o1mr41306535pay.17.1343840852107; Wed, 01 Aug 2012 10:07:32 -0700 (PDT) Received: from HonestQiaoNB ([123.115.11.229]) by mx.google.com with ESMTPS id qd10sm2933310pbb.38.2012.08.01.10.07.27 (version=SSLv3 cipher=OTHER); Wed, 01 Aug 2012 10:07:31 -0700 (PDT) Date: Thu, 2 Aug 2012 01:07:26 +0800 From: =?gb2312?B?x8ez/i9Ib25lc3RRaWFv?= To: "Zack Breckenridge" References: <201207021729413382845@gmail.com> <4FF2599B.6050409@gmail.com> <201207031411248300207@gmail.com> <1341437029.4017.5.camel@localhost> <2012072016090861869410@gmail.com> , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.91[en] Mime-Version: 1.0 Message-ID: <2012080201072126960020@gmail.com> Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Mailman-Approved-At: Wed, 01 Aug 2012 17:17:50 +0000 Cc: freebsd-acpi Subject: Re: Re: Resume failed after Suspend on Thinkpad x201i X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:07:33 -0000 MjAxMi0wNy0yMyAwNTo0NSwgWmFjayBCcmVja2VucmlkZ2U8emJyZGdlQGdtYWlsLmNvbT4gd3Jv dGU6DQo+QXR0YWNoZWQgaXMgdGhlIGtlcm5lbCBjb25maWd1cmF0aW9uIGZpbGUgSSB1c2VkIHRv IGJ1aWxkIG15IGtlcm5lbCB3aXRob3V0DQo+VkVTQS4NCj4NCj5JIHdlbnQgdGhyb3VnaCB0aGUg c2FtZSBwcm9jZXNzIGFzIHlvdTogc2V0dGluZyBzdXNwZW5kIGJvdW5jZSwgZXRjLiwgYW5kDQo+ bG9va2luZyBhdCB0aGUgZG1lc2cgb3V0cHV0LiBBZ2FpbiwgSSBhbHNvIGxvb2tlZCBhdCB0aGUg d2l0bmVzcyBvdXRwdXQNCj5mcm9tIG15IEludGVsIGRyaXZlciB3aGVuIHJlc3VtaW5nIFggLS0g YW5kIEkgbm90aWNlZCB0aGF0IGl0IHNpbXBseSB3YXNuJ3QNCj5hYmxlIHRvIHJlYWNoIHRoZSBH UFUuDQo+DQo+U28gSSB0aGluayBpdCBpcyBzb21lIHNvcnQgb2YgYnVzIGVycm9yIG9uIHJlc3Vt ZSBhbmQgaXMgcmVsYXRlZCB0byBvdXINCj5kaWZmZXJlbnQgQklPU2VzLiBTaW5jZSBpdCB3b3Jr ZWQgZm9yIG1lLCBwcm9iYWJseSBzb21lIGludCAxMCBjYWxsIGluIFZFU0ENCj53YXMgY2F1c2lu ZyB0aGUgZXJyb3IuIEluIHlvdXIgY2FzZSAtIG5vdCBiZWluZyBhYmxlIHRvIGlzc3VlIGNvbW1h bmRzIHRvDQo+YW4gQVRBIGRldmljZSBjb3VsZCBhbHNvIGJlIGEgYnVzIGlzc3VlLCBjYXVzZWQg YnkgTk9UIGNhbGxpbmcgdGhlIHByb3Blcg0KPklOVCAxMCBzZXR1cCBmdW5jdGlvbnMgb24gcmVz dW1lLg0KPg0KPkknbSBnb2luZyB0byBidWlsZCBhIGRlYnVnIGtlcm5lbCB0b2RheSBhbmQgc2Vl IGlmIEkgY2FuIHN0YXJ0IHRyYWNraW5nIHRoZQ0KPnByb2JsZW0gdG8gaXQncyByb290Lg0KPg0K Pi0gWmFjaw0KPg0KDQpBcmUgeW91IG5ldyBtZXNzYWdlcz8NCk15IGtlcm5lbCBjb25maWd1cmF0 aW9uIGZpbGUgaXMgc2ltaWxhciB0byB5b3VyLg0KQnV0IEkgcmVtb3ZlZCB0aGUgZGVidWdnaW5n IG9wdGlvbnMuDQoNCkNhbiB5b3UgbGlzdCBhIHN0ZXAgdG8gdGVzdD8NCiBJJ2xsIHRlc3QgZWFj aCBzaWRlIHRvIHByb3ZpZGUgeW91IHdpdGggZnVsbCBpbmZvcm1hdGlvbiwgd2hpY2ggbWFrZSBp dCBlYXN5IHRvIGZpbmQgdGhlIHByb2JsZW0/ From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 2 12:30:18 2012 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 634A41065688 for ; Thu, 2 Aug 2012 12:30:18 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 46A7A8FC1B for ; Thu, 2 Aug 2012 12:30:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q72CUIvn043962 for ; Thu, 2 Aug 2012 12:30:18 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q72CUICn043959; Thu, 2 Aug 2012 12:30:18 GMT (envelope-from gnats) Date: Thu, 2 Aug 2012 12:30:18 GMT Message-Id: <201208021230.q72CUICn043959@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Iasen Kostov Cc: Subject: Re: kern/162859: [acpi] ACPI battery/acline monitoring partialy working (switching) X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Iasen Kostov List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 12:30:18 -0000 The following reply was made to PR kern/162859; it has been noted by GNATS. From: Iasen Kostov To: bug-followup@FreeBSD.org, msuszko@gmail.com Cc: Subject: Re: kern/162859: [acpi] ACPI battery/acline monitoring partialy working (switching) Date: Thu, 2 Aug 2012 15:28:20 +0300 Same here - HP ProBook 4530s. FreeBSD HeadBanG 9.1-BETA1 FreeBSD 9.1-BETA1 #2: Sun Jul 15 08:27:11 EEST 2012 root@HeadBanG:/usr/obj/usr/src/sys/HEADBANG amd64 In ~99% of the battery events they are not registered (eg: charging, pulling/plugging the power cord). The laptop has the latest BIOS from HP and it came with SUSE where the battery indicator worked as it should. Now it has windows (because it's useless under FreeBSD in the current state) and of course it works under windows too. I'm way too far from the inner workings of ACPI to be able to easy investigate this :( . Regards, Iasen. From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 2 22:24:55 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8419E106564A for ; Thu, 2 Aug 2012 22:24:55 +0000 (UTC) (envelope-from zbrdge@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id F1AD88FC0A for ; Thu, 2 Aug 2012 22:24:54 +0000 (UTC) Received: by lbbgm13 with SMTP id gm13so1170677lbb.13 for ; Thu, 02 Aug 2012 15:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DWuZMEJEOTZAHmbwk+j4loDhEb1FnLKMErvtdI350Ko=; b=dXi+xOrAbFf5j+qQKu+2yRlrJLTCCMp9GZhM3w91A1+PgPiXsQg+bQ7OC6+tTpWE32 +aYlbsvI7563ErHS5ZsufsgByHYMhhOkaPsmQMxLA1iW5xeTVQMFMo1G4w7puxoMRK6S hElaxx0k+VcxCUh+uHP9rnb5SXjQG1CGRhDJ0Ih1rZyBoVjY5NVanTOVIa10KZFWWNCT KtSh5EPIPL9ukcFP3AxKwxA3s100hNcjwhmJjesnWj+imb9EWEugAg3ZPQg5OMDoJMFh Du8UiG8KoeboxiSuB9pYBFjmbe52tgJT2ETUda8P4uPUuxuDJGegO15/rxs9ta7j6gdy SOKg== MIME-Version: 1.0 Received: by 10.112.101.97 with SMTP id ff1mr10460474lbb.69.1343946293729; Thu, 02 Aug 2012 15:24:53 -0700 (PDT) Received: by 10.112.47.230 with HTTP; Thu, 2 Aug 2012 15:24:53 -0700 (PDT) In-Reply-To: <2012080201072126960020@gmail.com> References: <201207021729413382845@gmail.com> <4FF2599B.6050409@gmail.com> <201207031411248300207@gmail.com> <1341437029.4017.5.camel@localhost> <2012072016090861869410@gmail.com> <2012080201072126960020@gmail.com> Date: Thu, 2 Aug 2012 15:24:53 -0700 Message-ID: From: Zack Breckenridge To: =?UTF-8?B?5LmU5qWaL0hvbmVzdFFpYW8=?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi Subject: Re: Re: Resume failed after Suspend on Thinkpad x201i X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:24:55 -0000 First of all, let me note that the Kernel config file I posted was for 10.0-CURRENT (a few weeks back now though). I've been looking into it, but still haven't developed a patch yet. I have verified that the screen blanking issue, on my hardware, occurs somewhere in the vm86 mode emulation code (which is how VESA is implemented on amd64), ultimately called by vesa_bios_post(), which is called in turn by vesa_load_state() on resume [see: http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3D3#L1497]. vesa_bios_post() ultimately calls x86bios_call() [see: http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=3D10#L584] and emulates the real mode VESA "initialization" code with a call to x86emu_exec_call(). I think in order to figure out whats going on from here I will have to do some DDB scripting and capture the output. I don't believe remote debugging will be possible with my hardware (no serial, no firewire)... Anyway, I'm working on it. So to verify that we are having the same issue, you can take the following steps: 1) build a kernel with debugging and VESA enabled: options VESA options KDB options DDB 2) disable X, boot into the console and issue the following commands: # sysctl debug.acpi.suspend_bounce=3D1 # sysctl debug.kdb.enter=3D1 db> break x86emu_exec_call db> c # zzz [you should hit the breakpoint] db> bt x86emu_exec_call() ... vesa_bios_post() ... ... rest of backtrace ... db> c 3) after hitting that last c, your screen should go black. Then you should be able to type "reboot" and reboot cleanly I'm pretty sure that if you get the same results, we are having the same issue, though I can make no guarantees. On Wed, Aug 1, 2012 at 10:07 AM, =E4=B9=94=E6=A5=9A/HonestQiao wrote: > > 2012-07-23 05:45, Zack Breckenridge wrote: > >Attached is the kernel configuration file I used to build my kernel with= out > >VESA. > > > >I went through the same process as you: setting suspend bounce, etc., an= d > >looking at the dmesg output. Again, I also looked at the witness output > >from my Intel driver when resuming X -- and I noticed that it simply was= n't > >able to reach the GPU. > > > >So I think it is some sort of bus error on resume and is related to our > >different BIOSes. Since it worked for me, probably some int 10 call in V= ESA > >was causing the error. In your case - not being able to issue commands t= o > >an ATA device could also be a bus issue, caused by NOT calling the prope= r > >INT 10 setup functions on resume. > > > >I'm going to build a debug kernel today and see if I can start tracking = the > >problem to it's root. > > > >- Zack > > > > Are you new messages? > My kernel configuration file is similar to your. > But I removed the debugging options. > > Can you list a step to test? > I'll test each side to provide you with full information, which make it = easy to find the problem? From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 4 06:39:54 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5A1A106566C for ; Sat, 4 Aug 2012 06:39:54 +0000 (UTC) (envelope-from honestqiao@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 76F418FC0A for ; Sat, 4 Aug 2012 06:39:54 +0000 (UTC) Received: by qcsg15 with SMTP id g15so1100564qcs.13 for ; Fri, 03 Aug 2012 23:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mX6108D8mLkvLWiQ7idZTw7FFBrVEh0SJBLNitoaIqA=; b=pekqDDmtaqp0XpQWB837Q8L/5ndHETu3vjhxilvmhvgzlB78bFpMteIKYAU16PzEik w6CyVZt13RmW39mQcEAbMuqx3eigZTlyRDt7bEe5Nr+ZrIl9ca+YSSikjzsz5nAElc4J mGzhSnmWuXZxdOootc1GSNCSOftgPntU3rEatVYhpgTitBwMZyAn3u5fDJos9zFGw+xB N6ZBpvwdiEYJOcdv3HsYvndRDqhYD40+W0nxcfrkSuHf2v0186/YAfOBNRjwTvXgJKzC SrD1wle/v77qnyUW8aNvZsy3qekCTQvZ3MQiWfUWaqK54Jt8gQ7fncP4jbSL8zWTwGqH ybJQ== Received: by 10.224.216.7 with SMTP id hg7mr6939092qab.3.1344062393512; Fri, 03 Aug 2012 23:39:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.224 with HTTP; Fri, 3 Aug 2012 23:39:12 -0700 (PDT) In-Reply-To: References: <201207021729413382845@gmail.com> <4FF2599B.6050409@gmail.com> <201207031411248300207@gmail.com> <1341437029.4017.5.camel@localhost> <2012072016090861869410@gmail.com> <2012080201072126960020@gmail.com> From: =?UTF-8?B?5LmU5qWa?= Date: Sat, 4 Aug 2012 14:39:12 +0800 Message-ID: To: Zack Breckenridge Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi Subject: Re: Re: Resume failed after Suspend on Thinkpad x201i X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 06:39:54 -0000 2012/8/3 Zack Breckenridge : > First of all, let me note that the Kernel config file I posted was for > 10.0-CURRENT (a few weeks back now though). > > I've been looking into it, but still haven't developed a patch yet. I > have verified that the screen blanking issue, on my hardware, occurs > somewhere in the vm86 mode emulation code (which is how VESA is > implemented on amd64), ultimately called by vesa_bios_post(), which is > called in turn by vesa_load_state() on resume [see: > http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497]. > vesa_bios_post() ultimately calls x86bios_call() [see: > http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584] > and emulates the real mode VESA "initialization" code with a call to > x86emu_exec_call(). > > I think in order to figure out whats going on from here I will have to > do some DDB scripting and capture the output. I don't believe remote > debugging will be possible with my hardware (no serial, no > firewire)... Anyway, I'm working on it. > > So to verify that we are having the same issue, you can take the > following steps: > > 1) build a kernel with debugging and VESA enabled: > options VESA > options KDB > options DDB > 2) disable X, boot into the console and issue the following commands: > # sysctl debug.acpi.suspend_bounce=1 > # sysctl debug.kdb.enter=1 > db> break x86emu_exec_call > db> c > # zzz > [you should hit the breakpoint] > db> bt > x86emu_exec_call() ... > vesa_bios_post() ... > ... rest of backtrace ... > db> c > 3) after hitting that last c, your screen should go black. Then you > should be able to type "reboot" and reboot cleanly My screen go black, but type "reboot" no effect. I can be sure to type "reboot" and return. LED status: 1. Disk LED is light, and off at a moment. 2. "Z" LED is light, Battary and power LED is light. 3. Wifi LED is light. > > I'm pretty sure that if you get the same results, we are having the > same issue, though I can make no guarantees. > > When I shutdown from KDE, or type shutdown -p now from console, my laptor can't shutdown complete. The battary LED is light alawys, others LED is off, and vents of the laptor has been blowing hot air. From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 4 22:29:06 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0420A1065670 for ; Sat, 4 Aug 2012 22:29:06 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id BC9888FC0A for ; Sat, 4 Aug 2012 22:29:05 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so3599111pbb.13 for ; Sat, 04 Aug 2012 15:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3O3DWwZk8Zgh7mm43jvNu0tPVHwbbAx4MwauF/3V8Xs=; b=lpxShojZCOo2YCt82gamlAhk9WET62HTVJ3Hc1v9bMECPny08r1w3DdW4WiIclmNYy 9WHa6FvTiZ0/IsXiIwAuk6BfnijF7hHIkG9ByTZX1uLxKjX6oPhjwu9DENXG/wB+OxiS WGe0WiMkYpm+Z3sLg9EEeFDHskLXv9c7GQGu4wrTl/MUuTJjgblQSOftH2Apta09DPT1 OxVYkI5b/7n07MXW+cu0ydfS4mOz1Xqwg2xvFdb3ZhLLE/nDlXanKJHsgIL3Cy7Lvd1S oew32qwOXNAm1Whhn3VVKOQrv550xAO9x7PnBGFC4kMk6NdrBiOKIIZrz4vWwLqt5e9Q E/Rg== Received: by 10.68.221.10 with SMTP id qa10mr7752634pbc.154.1344119345108; Sat, 04 Aug 2012 15:29:05 -0700 (PDT) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id nv6sm5677471pbc.42.2012.08.04.15.29.02 (version=SSLv3 cipher=OTHER); Sat, 04 Aug 2012 15:29:04 -0700 (PDT) Message-ID: <501DA226.8000707@gmail.com> Date: Sat, 04 Aug 2012 15:28:54 -0700 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120731 Thunderbird/14.0 MIME-Version: 1.0 To: =?UTF-8?B?5LmU5qWa?= References: <201207021729413382845@gmail.com> <4FF2599B.6050409@gmail.com> <201207031411248300207@gmail.com> <1341437029.4017.5.camel@localhost> <2012072016090861869410@gmail.com> <2012080201072126960020@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-acpi Subject: Re: Resume failed after Suspend on Thinkpad x201i X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 22:29:06 -0000 On 08/03/12 23:39, 乔楚 wrote: > 2012/8/3 Zack Breckenridge : >> First of all, let me note that the Kernel config file I posted was for >> 10.0-CURRENT (a few weeks back now though). >> >> I've been looking into it, but still haven't developed a patch yet. I >> have verified that the screen blanking issue, on my hardware, occurs >> somewhere in the vm86 mode emulation code (which is how VESA is >> implemented on amd64), ultimately called by vesa_bios_post(), which is >> called in turn by vesa_load_state() on resume [see: >> http://fxr.watson.org/fxr/source/dev/fb/vesa.c?im=3#L1497]. >> vesa_bios_post() ultimately calls x86bios_call() [see: >> http://fxr.watson.org/fxr/source/compat/x86bios/x86bios.c?im=10#L584] >> and emulates the real mode VESA "initialization" code with a call to >> x86emu_exec_call(). >> >> I think in order to figure out whats going on from here I will have to >> do some DDB scripting and capture the output. I don't believe remote >> debugging will be possible with my hardware (no serial, no >> firewire)... Anyway, I'm working on it. >> >> So to verify that we are having the same issue, you can take the >> following steps: >> >> 1) build a kernel with debugging and VESA enabled: >> options VESA >> options KDB >> options DDB >> 2) disable X, boot into the console and issue the following commands: >> # sysctl debug.acpi.suspend_bounce=1 >> # sysctl debug.kdb.enter=1 >> db> break x86emu_exec_call >> db> c >> # zzz >> [you should hit the breakpoint] >> db> bt >> x86emu_exec_call() ... >> vesa_bios_post() ... >> ... rest of backtrace ... >> db> c >> 3) after hitting that last c, your screen should go black. Then you >> should be able to type "reboot" and reboot cleanly > My screen go black, but type "reboot" no effect. I can be sure to type > "reboot" and return. > LED status: > 1. Disk LED is light, and off at a moment. > 2. "Z" LED is light, Battary and power LED is light. > 3. Wifi LED is light. > >> I'm pretty sure that if you get the same results, we are having the >> same issue, though I can make no guarantees. >> >> > When I shutdown from KDE, or type shutdown -p now from console, my > laptor can't shutdown complete. > The battary LED is light alawys, others LED is off, and vents of the > laptor has been blowing hot air. > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > Honest Qiao: Regarding hot air, are you running powerd? Try "powerd -a adaptive -b adaptive" as root and wait 5 minutes to see if the hot air stops. If it works, try "man powerd" for installation instructions. Lenovo laptops are thermally designed for low CPU utilization. I can almost boil water on mine during buildworld. Without powerd, they run at full thermal profile and act as excellent hand warmers. Zack: Regarding remote debugging, do you have an expresscard/cardbus/etc slot? Although hard to find you may be able to find a firewire card for that. Not sure if that would work or not...same goes for a USB->Serial console, my guess is that it wouldn't work? Matt