From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 14 07:40:43 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E665BF97; Sun, 14 Jul 2013 07:40:43 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 42645856; Sun, 14 Jul 2013 07:40:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r6E7eXY7019443; Sun, 14 Jul 2013 17:40:34 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 14 Jul 2013 17:40:33 +1000 (EST) From: Ian Smith To: Warren Block Subject: Re: Hyper mode for powerd In-Reply-To: Message-ID: <20130714161717.Y12860@sola.nimnet.asn.au> References: <20130707003651.Y26496@sola.nimnet.asn.au> <20130709145722.U61164@sola.nimnet.asn.au> <20130710200113.J23480@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 07:40:44 -0000 On Wed, 10 Jul 2013 13:43:56 -0600, Warren Block wrote: > On Wed, 10 Jul 2013, Ian Smith wrote: [..] > > > Interesting point. 100mS is a perceptible lag. > > > > Maybe just. On that beast I think you could use 50ms with no noticeable > > powerd CPU usage, maybe even 25ms. In fact I think doing just that with > > hadp mode might get you all the interactive responsiveness you want, and > > still let powerd use a range of freqs as required. Playing with -r and > > -i will also alter the responsiveness curve quite a bit. > > > > With it then testing load and increasing frequency 5 times as often, on > > full load it should shift up 5 times more quickly, and hadp mode already > > shifts freq up by a factor of 4 on each poll_interval, so it should get > > from 1600 to 3601 in one! iteration, and even if using p4tcc/throttling, > > from 200 to 3601 in only two or three steps (200 x 4 = 800, 800 x 4 = > > 3200) with even three steps then taking only 150ms, well inside your > > current 250ms interval. Maybe give that a try? > > Wow! -r 50 with either hadp or hyper mode feels fine interactively. You sound surprised, but I'm not. Nate Lawson introduced powerd at FreeBSD 6.0, using a Thinkpad T23 at that time, 1133/733 MHz, and 250mS was a reasonable default for laptops then. In fact, I bought my first 2ndhand T23 around 6.1-RELEASE precisely because Nate was working on ACPI and cpufreq etc, and the T23 was then one of the few machines that reliably suspended and resumed (and still is!), a must for me. What powerd(8) could really use is an update to its man page (or a page in the handbook, or wiki?) suggesting some reasonable defaults for the range of hardware nowadays running it. When mav@ added hiadaptive mode I was quite skeptical at first, and of course it proved useless for the two-speed T23, which would jump to max speed at the drop of a hat but then take forever to shuffle back down to lower speed, but is clearly advantageous for more modern machines - esp. with more frequent polling. I guess powerd(8) would be also a good place to mention the advantage of turning off p4tcc and acpi_throttle in loader.conf, as at least a step towards deprecating their use with powerd? [Kevin, what do you think?] > > > Timing 'periodic daily' now with a full cache and powerd not running: > > > 995.53 real 28.15 user 132.17 sys > > > > > > With 'powerd -a hyper -n hyper -v > /tmp/powerd.log': > > > 2322.06 real 58.72 user 305.22 sys > > > > > > Load varied enough that it would drop to 200MHz quite often. Picking a > > > random part of the log: [..] > > > changing clock speed from 3601 MHz to 200 MHz > > > load 4%, current freq 200 MHz (26), wanted freq 200 MHz > > > now operating on AC power; changing frequency to 3601 MHz > > > load 20%, current freq 200 MHz (26), wanted freq 3601 MHz > > > changing clock speed from 200 MHz to 3601 MHz > > > now operating on AC power; changing frequency to 200 MHz > > > load 3%, current freq 3601 MHz ( 0), wanted freq 200 MHz > > > Hunting away. > > Is that a bad thing, though? Effectively, it's just PWM, if you see what I > mean. I do, but to extend that analogy, compare an inverter with squarewave output to one using a stepped pseudo-sine wave, as most non-pure-sine inverters do today, much smoother and more efficient too. I don't know the actual cost of changing freqs via sysctl, but suspect less often and smaller stepsizes are going to be more efficient and less likely to shift to a wildly inappropriate freq for load. Perhaps my mechanical engineering bent worries about wear and tear on the 'gearbox', as it were, which of course we know to be a non-issue electronically :) > > Over twice as long to run. Maybe now try at 50ms in hadp mode and you'll > > have a good idea how fast that runs, and how it feels. > > The same periodic daily test as before, again with the first run discarded to > load the cache. > > powerd -a hyper -n hyper -p 50 -v > /tmp/powerd.log > 977.44 real 47.79 user 238.48 sys > > powerd -a hadp -n hadp -p 50 -v > /tmp/powerd.log > 874.18 real 28.89 user 140.00 sys Well hadp here gets the job done more quickly at any rate, both absolutely and in terms of system and user time. If you're really burning up to hack on powerd :) a timestamp including milliseconds on the -v output lines (which might be cut to two lines max per change) would make it far easier to see what was happening, when .. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Sun Jul 14 16:31:33 2013 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 85D10EBC; Sun, 14 Jul 2013 16:31:33 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 37C17859; Sun, 14 Jul 2013 16:31:32 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id r6EGVWMv061872; Sun, 14 Jul 2013 10:31:32 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id r6EGVWAU061869; Sun, 14 Jul 2013 10:31:32 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 14 Jul 2013 10:31:32 -0600 (MDT) From: Warren Block To: Ian Smith Subject: Re: Hyper mode for powerd In-Reply-To: <20130714161717.Y12860@sola.nimnet.asn.au> Message-ID: References: <20130707003651.Y26496@sola.nimnet.asn.au> <20130709145722.U61164@sola.nimnet.asn.au> <20130710200113.J23480@sola.nimnet.asn.au> <20130714161717.Y12860@sola.nimnet.asn.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 14 Jul 2013 10:31:32 -0600 (MDT) Cc: acpi@freebsd.org, Kevin Oberman , wblock@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 16:31:33 -0000 On Sun, 14 Jul 2013, Ian Smith wrote: > What powerd(8) could really use is an update to its man page (or a page > in the handbook, or wiki?) suggesting some reasonable defaults for the > range of hardware nowadays running it. Difficulty: finding "reasonable" defaults. But given the values, I would be willing to add them to that page. > I guess powerd(8) would be also a good place to mention the advantage of > turning off p4tcc and acpi_throttle in loader.conf, as at least a step > towards deprecating their use with powerd? [Kevin, what do you think?] Before that, there should probably be some benchmarks, both for performance and power usage. Those last results I posted left both settings at the default (enabled). I don't know if they do any harm that way. Again, a power usage benchmark would be interesting. A heat level benchmark ought to be possible with the built-in temperature sensors. > > > Hunting away. > > > > Is that a bad thing, though? Effectively, it's just PWM, if you see what I > > mean. > > I do, but to extend that analogy, compare an inverter with squarewave > output to one using a stepped pseudo-sine wave, as most non-pure-sine > inverters do today, much smoother and more efficient too. I don't know > the actual cost of changing freqs via sysctl, but suspect less often and > smaller stepsizes are going to be more efficient and less likely to > shift to a wildly inappropriate freq for load. Perhaps my mechanical > engineering bent worries about wear and tear on the 'gearbox', as it > were, which of course we know to be a non-issue electronically :) I thought that was what Kevin was saying, that shifting to full idle or full throttle was the most efficient. Even if there is a higher cost to larger frequency changes, it may be more than offset by power savings or processing capacity. > > The same periodic daily test as before, again with the first run discarded to > > load the cache. > > > > powerd -a hyper -n hyper -p 50 -v > /tmp/powerd.log > > 977.44 real 47.79 user 238.48 sys > > > > powerd -a hadp -n hadp -p 50 -v > /tmp/powerd.log > > 874.18 real 28.89 user 140.00 sys > > Well hadp here gets the job done more quickly at any rate, both > absolutely and in terms of system and user time. Possibly due to the slower throttling down when the system is detected to be idle. > If you're really burning up to hack on powerd :) a timestamp including > milliseconds on the -v output lines (which might be cut to two lines max > per change) would make it far easier to see what was happening, when .. This really has me thinking more about benchmarks now. From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 15 11:06:39 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 971C7F2B for ; Mon, 15 Jul 2013 11:06:39 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 71016FB2 for ; Mon, 15 Jul 2013 11:06:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6FB6did084334 for ; Mon, 15 Jul 2013 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6FB6dRM084332 for freebsd-acpi@FreeBSD.org; Mon, 15 Jul 2013 11:06:39 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Jul 2013 11:06:39 GMT Message-Id: <201307151106.r6FB6dRM084332@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 Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 11:06:39 -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/174766 acpi [acpi] Random acpi panic o kern/174504 acpi [ACPI] Suspend/resume broken on Lenovo x220 o kern/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/165381 acpi [cpufreq] powerd(8) eats CPUs for breakfast o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v 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/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 i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not 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/73823 acpi [request] acpi / power-on by timer support 25 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 15 21:34:07 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 523DE9A2; Mon, 15 Jul 2013 21:34:07 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:470:fd92:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 0A67CC06; Mon, 15 Jul 2013 21:34:06 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id EE23D83C6; Tue, 16 Jul 2013 06:34:04 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id bXgCPpQpZiX0; Tue, 16 Jul 2013 06:34:00 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:470:fd92:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA; Tue, 16 Jul 2013 06:33:59 +0900 (JST) Date: Tue, 16 Jul 2013 06:35:12 +0900 From: Taku YAMAMOTO To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume Message-Id: <20130716063512.d48fcc385a64619952a52a66@tackymt.homeip.net> In-Reply-To: References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> <20130708140804.R26496@sola.nimnet.asn.au> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.17; i386-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Tue__16_Jul_2013_06_35_12_+0900_D2=g_ngqTKSdEOy3" Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:34:07 -0000 This is a multi-part message in MIME format. --Multipart=_Tue__16_Jul_2013_06_35_12_+0900_D2=g_ngqTKSdEOy3 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit This reminds me of my local patch which I wrote and forgot about deep in the git :) This hack was required to have working USB ports on X61 after resume, but I'm not sure whether it's still required because I don't have X61 handy anymore... On Mon, 8 Jul 2013 11:09:20 -0700 Adrian Chadd wrote: > On 7 July 2013 22:00, Ian Smith wrote: > > > Checking one more point .. do the USB ports come up ok if you originally > > boot with nothing plugged in? If so (or if not), does that local APIC > > Yes. > > > error message appear the same then too? > > > > > No > > > -adrian > _______________________________________________ > 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" -- -|-__ 山本　拓 / YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Tue__16_Jul_2013_06_35_12_+0900_D2=g_ngqTKSdEOy3 Content-Type: text/plain; name="acpi_psw-usb.patch" Content-Disposition: attachment; filename="acpi_psw-usb.patch" Content-Transfer-Encoding: 7bit commit 5df85bbf9a02f5bd116bc8520aba2d6b4ee1b2fb Author: Taku YAMAMOTO Date: Thu Feb 14 01:07:22 2013 +0900 Fix GPE handling on sleeping. (found on X61) diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c index da252c4..2ccf08a 100644 --- a/sys/dev/acpica/acpi.c +++ b/sys/dev/acpica/acpi.c @@ -2905,6 +2905,8 @@ acpi_wake_sleep_prep(ACPI_HANDLE handle, int sstate) if (acpi_parse_prw(handle, &prw) != 0) return (ENXIO); dev = acpi_get_device(handle); + if (dev == NULL || (acpi_get_flags(dev) & ACPI_FLAG_WAKE_ENABLED) == 0) + return (0); /* * The destination sleep state must be less than (i.e., higher power) @@ -2918,7 +2920,7 @@ acpi_wake_sleep_prep(ACPI_HANDLE handle, int sstate) if (bootverbose) device_printf(dev, "wake_prep disabled wake for %s (S%d)\n", acpi_name(handle), sstate); - } else if (dev && (acpi_get_flags(dev) & ACPI_FLAG_WAKE_ENABLED) != 0) { + } else { acpi_pwr_wake_enable(handle, 1); acpi_SetInteger(handle, "_PSW", 1); if (bootverbose) --Multipart=_Tue__16_Jul_2013_06_35_12_+0900_D2=g_ngqTKSdEOy3-- From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 15 22:06:06 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A0AB91B8 for ; Mon, 15 Jul 2013 22:06:06 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:470:fd92:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 6935DD8F for ; Mon, 15 Jul 2013 22:06:06 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id D398183C5 for ; Tue, 16 Jul 2013 07:06:05 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id 9GL6RZcyBnku for ; Tue, 16 Jul 2013 07:06:04 +0900 (JST) Received: from biotite.tackymt.homeip.net (biotite.tackymt.homeip.net [IPv6:2001:470:fd92:0:216:cfff:febc:1472]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA for ; Tue, 16 Jul 2013 07:06:04 +0900 (JST) Date: Tue, 16 Jul 2013 07:07:16 +0900 From: Taku YAMAMOTO To: freebsd-acpi@freebsd.org Subject: Revisiting FPU context resume on i386 Message-Id: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.17; i386-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Tue__16_Jul_2013_07_07_16_+0900_h+CNhL/Y5tSJPtQm" X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 22:06:06 -0000 This is a multi-part message in MIME format. --Multipart=_Tue__16_Jul_2013_07_07_16_+0900_h+CNhL/Y5tSJPtQm Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi all, sys/i386/i386/swtch.s have a big FIX ME in resumectx() and I have occationally got bitten by it; resulting in SIGFPE disasters. After cursory looking around FPU context, I think it's the simplest way to set CR0_TS on resumectx() and to let npxdna() DTRT lazilly. Attached is the mods that I'm currently using without a problem at the moment. It at least doesn't interact with normal resume operations badly. Ah, of cource, we have a choice to throw i386 away and get on amd64, but at least I won't because I'd miss VOCALOIDs running on wine/i386 :) -- -|-__ YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - --Multipart=_Tue__16_Jul_2013_07_07_16_+0900_h+CNhL/Y5tSJPtQm Content-Type: text/plain; name="i386-resumectx-fpu.patch" Content-Disposition: attachment; filename="i386-resumectx-fpu.patch" Content-Transfer-Encoding: 7bit commit 99a24d7c19d624654afbd574e604d8a011ed28b3 Author: Taku YAMAMOTO Date: Sun Jul 14 07:36:29 2013 +0900 i386: defer FPU context resume from resumectx() to npxdna() by CR0_TS. diff --git a/sys/i386/i386/swtch.s b/sys/i386/i386/swtch.s index 80aa6c4..71efae1 100644 --- a/sys/i386/i386/swtch.s +++ b/sys/i386/i386/swtch.s @@ -36,6 +36,7 @@ #include "opt_sched.h" #include +#include #include "assym.s" @@ -487,6 +488,10 @@ ENTRY(resumectx) movl PCB_CR3(%ecx),%eax movl %eax,%cr3 movl PCB_CR0(%ecx),%eax +#ifdef DEV_NPX + /* Let npxdna() restore the FPU context lazily. */ + orl $CR0_TS,%eax +#endif movl %eax,%cr0 jmp 1f 1: @@ -519,10 +524,6 @@ ENTRY(resumectx) movl PCB_DR7(%ecx),%eax movl %eax,%dr7 -#ifdef DEV_NPX - /* XXX FIX ME */ -#endif - /* Restore other registers */ movl PCB_EDI(%ecx),%edi movl PCB_ESI(%ecx),%esi --Multipart=_Tue__16_Jul_2013_07_07_16_+0900_h+CNhL/Y5tSJPtQm-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 16 05:26:48 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 59AF44D3 for ; Tue, 16 Jul 2013 05:26:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id C7AE8EDC for ; Tue, 16 Jul 2013 05:26:47 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6G5QhQA087230; Tue, 16 Jul 2013 08:26:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6G5QhQA087230 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6G5QflP087228; Tue, 16 Jul 2013 08:26:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Jul 2013 08:26:41 +0300 From: Konstantin Belousov To: Taku YAMAMOTO Subject: Re: Revisiting FPU context resume on i386 Message-ID: <20130716052641.GE91021@kib.kiev.ua> References: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6CSUTDM8zwHHEeSv" Content-Disposition: inline In-Reply-To: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 05:26:48 -0000 --6CSUTDM8zwHHEeSv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 07:07:16AM +0900, Taku YAMAMOTO wrote: > Hi all, >=20 > sys/i386/i386/swtch.s have a big FIX ME in resumectx() > and I have occationally got bitten by it; resulting in SIGFPE disasters. >=20 > After cursory looking around FPU context, I think it's the simplest way > to set CR0_TS on resumectx() and to let npxdna() DTRT lazilly. >=20 > Attached is the mods that I'm currently using without a problem at the mo= ment. > It at least doesn't interact with normal resume operations badly. >=20 > Ah, of cource, we have a choice to throw i386 away and get on amd64, > but at least I won't because I'd miss VOCALOIDs running on wine/i386 :) >=20 > --=20 > -|-__ YAMAMOTO, Taku > | __ < >=20 > - A chicken is an egg's way of producing more eggs. - > commit 99a24d7c19d624654afbd574e604d8a011ed28b3 > Author: Taku YAMAMOTO > Date: Sun Jul 14 07:36:29 2013 +0900 >=20 > i386: defer FPU context resume from resumectx() to npxdna() by CR0_TS. >=20 > diff --git a/sys/i386/i386/swtch.s b/sys/i386/i386/swtch.s > index 80aa6c4..71efae1 100644 > --- a/sys/i386/i386/swtch.s > +++ b/sys/i386/i386/swtch.s > @@ -36,6 +36,7 @@ > #include "opt_sched.h" > =20 > #include > +#include > =20 > #include "assym.s" > =20 > @@ -487,6 +488,10 @@ ENTRY(resumectx) > movl PCB_CR3(%ecx),%eax > movl %eax,%cr3 > movl PCB_CR0(%ecx),%eax > +#ifdef DEV_NPX > + /* Let npxdna() restore the FPU context lazily. */ > + orl $CR0_TS,%eax > +#endif > movl %eax,%cr0 > jmp 1f > 1: > @@ -519,10 +524,6 @@ ENTRY(resumectx) > movl PCB_DR7(%ecx),%eax > movl %eax,%dr7 > =20 > -#ifdef DEV_NPX > - /* XXX FIX ME */ > -#endif > - > /* Restore other registers */ > movl PCB_EDI(%ecx),%edi > movl PCB_ESI(%ecx),%esi If this works, fine. But I think that you also should make sure that invariants which are checked by npxdna() are met. E.g. see the checks for fpcurthread at the start of the routine. Might be, just clear the pcpu fpcurthread as part of the resume ? Is it done by suspend counterpart ? --6CSUTDM8zwHHEeSv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR5NmRAAoJEJDCuSvBvK1BMpYP/37GFsTkTCcZtWhOyhfuTNb3 4yuHI1VWQ25NM2RyTaER9OFscMDXNWOaLPmPsvZe1EAwdxknQ1f0SIhXuonxtbIB YYnLnFtwdwpHtrBUKqKT1JZ26CV4L4CSx5OfeS4YdKchlCcD6gHKUJ/EbVee6WtT h6felsDqwD7WjOuh8OYkndTcltC8BtcBfGpZMDjyL3zPltxGvoqRTt/238WuiKp+ yz3xhyyYmjWCIS7Y50g7XEc9BbVY5E0dPc+yvymPxyEIDfpsFSXBPd6zdKgnX4vv xGrYJr04rD4+G6b03VIrROLbWLXVpxuV8eK22M5gJ0b585U8LxYvkZEePgCEn5tT UtmIeJcwMYUvplj/K3EC9qmMvS/4Wgn94Qil8l7WSso2fKfu7IHQ9rr3jXEXiB+4 0VXe1oISPnjFKT9q8VDUEIPvn0PHvnpeIn6WrAV7rdWeHgszErMN4WAnoTQ5Ajfg MhptFGw+TkVWOq1j57ah8gY9kshEJ2MDd5GXygXBkLJ+FUrY6kQ+LYzTkov1ur62 qDkyVYGHAmX+5L56/x0N+I7ogIBx6seFQBey4Zf0XeRPLtXYPSxYafNyyaxuI2ec 1KjpPpyBZh6Ck5AFt/d7GY1l+Hn04q2PLSm9mkzEtJuZh5yd/NIEvArFDAIAm/wB s4yrJRLTINeDL5dsyTqv =Nymy -----END PGP SIGNATURE----- --6CSUTDM8zwHHEeSv-- From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 16 08:55:11 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F081AC17 for ; Tue, 16 Jul 2013 08:55:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 074D2856 for ; Tue, 16 Jul 2013 08:55:09 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 1B6223C6229; Tue, 16 Jul 2013 18:54:58 +1000 (EST) Date: Tue, 16 Jul 2013 18:54:57 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: Revisiting FPU context resume on i386 In-Reply-To: <20130716052641.GE91021@kib.kiev.ua> Message-ID: <20130716164612.P1088@besplex.bde.org> References: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> <20130716052641.GE91021@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=YYGEuWhf c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=IpbkEbG0bHYA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=T3l0V36KyEQA:10 a=CRyO6Jkz4opaHJ-Lv7kA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 08:55:11 -0000 On Tue, 16 Jul 2013, Konstantin Belousov wrote: > On Tue, Jul 16, 2013 at 07:07:16AM +0900, Taku YAMAMOTO wrote: >> sys/i386/i386/swtch.s have a big FIX ME in resumectx() >> and I have occationally got bitten by it; resulting in SIGFPE disasters. >> >> After cursory looking around FPU context, I think it's the simplest way >> to set CR0_TS on resumectx() and to let npxdna() DTRT lazilly. >> >> Attached is the mods that I'm currently using without a problem at the moment. >> It at least doesn't interact with normal resume operations badly. >> >> Ah, of cource, we have a choice to throw i386 away and get on amd64, >> but at least I won't because I'd miss VOCALOIDs running on wine/i386 :) amd64 uses npx and CR0_TS too. It just misspells npx as fpu and even misspells CR0_TS as TS0_CR in a comment in cpu_switch.S. The problem seems to be just that acpi is not fully supported on i386. The npx state is simpler on i386 (no AVX support), so this should be easy to fix by copying the suspend/resume logic from amd64. >> diff --git a/sys/i386/i386/swtch.s b/sys/i386/i386/swtch.s >> index 80aa6c4..71efae1 100644 >> --- a/sys/i386/i386/swtch.s >> +++ b/sys/i386/i386/swtch.s >> @@ -36,6 +36,7 @@ >> #include "opt_sched.h" >> >> #include >> +#include >> >> #include "assym.s" >> >> @@ -487,6 +488,10 @@ ENTRY(resumectx) >> movl PCB_CR3(%ecx),%eax >> movl %eax,%cr3 >> movl PCB_CR0(%ecx),%eax >> +#ifdef DEV_NPX >> + /* Let npxdna() restore the FPU context lazily. */ >> + orl $CR0_TS,%eax >> +#endif >> movl %eax,%cr0 >> jmp 1f >> 1: >> @@ -519,10 +524,6 @@ ENTRY(resumectx) >> movl PCB_DR7(%ecx),%eax >> movl %eax,%dr7 >> >> -#ifdef DEV_NPX >> - /* XXX FIX ME */ >> -#endif >> - >> /* Restore other registers */ >> movl PCB_EDI(%ecx),%edi >> movl PCB_ESI(%ecx),%esi > > If this works, fine. But I think that you also should make sure that > invariants which are checked by npxdna() are met. E.g. see the > checks for fpcurthread at the start of the routine. How can this possibly work? If the invariants are satisfied, then suspend would have saved a CR0_TS setting consistent with the invariants, so that there is nothing to fix. Actually, it seems to be necessary to save the state to the pcb and set CR0_TS on suspend, since if the state is not saved then, then nothing saves it before resume, and suspension can apparently lose it. If the state was saved on suspend, then CR0_TS in the pcb was set on suspend, so the patch has no effect. If the state wasn't saved on suspend, then the patch forces restoration of the last saved state, even when suspension didn't lose it. Thus in the latter case, a wrong (out of date) state is always restored, but usually the state is not very out of date so it sort of works. So the fix should be simply to save the state on suspend, or fix this if it is already supposed to be done. > Might be, just clear the pcpu fpcurthread as part of the resume ? Is it > done by suspend counterpart ? The state must be saved together with this to satisfy invariants. The bug is hard to understand by looking at only savectx(). Strangely, it is the i386 savectx() that saves the state. amd64 has a special routine ctx_fpusave() for saving the state. This is called from cpususpend_handler(). Its handling of CR0_TS seems to be worse than i386's too -- where i386's core routine npxsave() handles CR0_TS and returns with it set (as necessary for putting the state away for suspension), amd64's core routine fpusave() requires the caller to handle CR0_TS, and the ctx_fpusave() caller clears CR0_TS before the call but doesn't set it on return. ctx_fpusave() also doesn't maintained the invariant. So suspend/resume on amd64 already works unusually: more details: - the state saving for suspend/resume is completely independent of the pcb and the invariant. Suspendion just saves the current hardware npx^Wfpu state to a special save area. There would still be problems if any part of the state (hardware/pcb/invariant) changes before supend+resume completes. Apparently this doesn't happen. i386 would have similar problems with the state saved in the pcb if it changed during suspend+resume (now since the save area is not special, changes wouldn't invalidate the saved state, but if the changes result in the state becoming active again then suspension may lose the state). - since ctx_fpusave() is left clear by ctx_fpusave(), it will be clear when resume reloads CR0. ISTR disagreeing with jkim on using a special save area. i386 also has cpususpend_handler(). It has a special save area too, and the only significant difference is that the npx part of the save is done by savectx() instead of separately by ctx_fpusave(). The bug is now fairly obvious: savectx() uses npxsave(), and npxsave() breaks the invariant in various ways: % void % npxsave(addr) % union savefpu *addr; % { % % stop_emulating(); Already the invariant is not satisfied, but this is protected by interrupts being disabled. % fpusave(addr); If fpusave() is fxsave(), this leaves the state in the hardware. Otherwise, fpusave() is fnsave() and it initializes the state in the hardware. In the latter case, the invariant is transiently less satisfied than before. % % start_emulating(); This restores the part of the invariant that says that the state is not in the hardware (an npxdna() is needed to reload the state after fnsave(). % PCPU_SET(fpcurthread, NULL); % } This completes restoring the invariant, but only when 'addr' is in the PCB. When 'addr' is in the special save area, the invariant is very broken. We only call here if the state active to begin with (otherwise, it wouldn't be in the hardware so copying it from the hardware to the pcb would be very wrong). We record the state change in the pcb, but only saved the state in the special save area. fpcurthread in the special save area is either nonexistent or not initialized yet. This is not seriously broken provided we initialized fpcurthread in the special save area soon, and never touch the npx state again until resume completes. We must be careful with the CR0_TS part of the invariant too. When npxsave() was called, it should be clear (and the start_emulating() call should have no effect). When npxsave() returns, CR0_TS is set, and it must be saved somewhere soon. Since suspension is using a special save area, it presumably saves CR0 there too. So the pcb is not really used across suspend/resume. But the above write of fpcurthread to it is dangerous. Now for the inconsistencies in i386 savectx()/resumectx() related to the above: % /* % * savectx(pcb) % * Update pcb, saving current processor state. % */ Wrong comment. This saves in the special save area in most or all cases. It is important to understand that the normal pcb is not really used here and most updates to it are accidental. % ENTRY(savectx) % /* Fetch PCB. */ % movl 4(%esp),%ecx Wrong comment. As above, plus it spells pcb inconstently (capitalization is technically more correct, but we often spell it pcb). amd64 has the same wrong comments. I think the special save area consists mainly of a pcb, but it's very confusing when this pcb is not the usual one. % ... % movl %cr0,%eax % movl %eax,PCB_CR0(%ecx) It saves CR0 quite early. % #ifdef DEV_NPX % #ifdef DEV_NPX % /* % * If fpcurthread == NULL, then the npx h/w state is irrelevant and the % * state had better already be in the pcb. This is true for forks % * but not for dumps (the old book-keeping with FP flags in the pcb % * always lost for dumps because the dump pcb has 0 flags). % * % * If fpcurthread != NULL, then we have to save the npx h/w state to % * fpcurthread's pcb and copy it to the requested pcb, or save to the % * requested pcb and reload. Copying is easier because we would % * have to handle h/w bugs for reloading. We used to lose the % * parent's npx state for forks by forgetting to reload. % */ It saves npx as the very last step. The copying stuff avoids some consistency problems, but the comment about it is very out of date, and the copying is now incomplete. % pushfl % CLI % movl PCPU(FPCURTHREAD),%eax % testl %eax,%eax % je 1f The fpcurthread pointer (now in %eax) is not in the pcb. % % pushl %ecx % movl TD_PCB(%eax),%eax % movl PCB_SAVEFPU(%eax),%eax % pushl %eax % pushl %eax % call npxsave % addl $4,%esp % popl %eax % popl %ecx We first save to the pcb. Everything in the pcb is consistent now. fpcurthread is now 0. This is consistent too. % % pushl $PCB_SAVEFPU_SIZE % leal PCB_USERFPU(%ecx),%ecx % pushl %ecx % pushl %eax % call bcopy % addl $12,%esp The copy of the pcb in the special save area is not quite consistent. We only copied the very-npx-specific parts. CR0 wasn't copied, so it still has the old value for CR0_TS (clear when it should be set). fpcurthread doesn't live in the pcb, but that doesn't seem to be a problem, since the special state where the CR0_TS is set means that fpcurthread must be NULL, so we can recover fpcurthread from CR0_TS in this case. % 1: % popfl % #endif /* DEV_NPX */ % % movl $1,%eax % ret % END(savectx) % % /* % * resumectx(pcb) __fastcall % * Resuming processor state from pcb. % */ % ENTRY(resumectx) % /* Restore GDT. */ % lgdt PCB_GDT(%ecx) Wrong comments, as above. % /* Restore CR2, CR4, CR3 and CR0 */ % ... % movl PCB_CR0(%ecx),%eax % movl %eax,%cr0 % jmp 1f % 1: What's this magic null jump? % ... % #ifdef DEV_NPX % /* XXX FIX ME */ % #endif I now think that your patch works fine. It just sets CR0 to the state that should have been saved. The correct fix is even simpler (assuming that there are no races) -- either move the saving of CR0 after the saving of NPX, or save CR0 again after changing it in npxsave(). The copying from the pcb to the save area can probably be safely removed. npxsave() supports storing directly to the save area. The pcb is not really used for suspend/resume or other callers of savectx() (if any). It doesn't help much for the NPX part of it to be consistent with the save area when other parts are inconsistent and parts like fpucurthread don't live in either the pcb or the save area. savectx() seems to only be used by for dumping, stopping CPUs and suspending CPUs. Its save area is always special, and always an ordinary pcb struct (but amd64 seems to have a separate save area for suspendeded FPU state. I can't find where the pointer for this is initialized). Using the primary pcb is especially unimportant for dumping. When I wrote the above long comment about copying the npx state in FreeBSD-1, savectx() was only used for forking and dumping. It had to be careful for forking. In FreeBSD-2+, it wasn't used for forking or for anything else except dumping. Then the copying in the i386 version of it was excessively careful and the comment was out of date. Now savectx() is important again and must be careful for stopping and suspending CPUs. It is still broken for stopping CPUs on amd64, since it doesn't save the fpu state and neither does cpustop_handler() (unlike cpususpend_handler). Bruce From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 16 09:16:52 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98682F25; Tue, 16 Jul 2013 09:16:52 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by mx1.freebsd.org (Postfix) with ESMTP id DE5F092C; Tue, 16 Jul 2013 09:16:51 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id j13so380726wgh.24 for ; Tue, 16 Jul 2013 02:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0O2BeIWZBBtbAdMs4oVt3gUtAiQkbHX4FFpp49ztVq4=; b=NLnhH28xt7/vYLeO/4MNwCZfNZXoYJ3tCumq7OA6Li67HtPUPP/BteRKa7m5C+Lt44 BWp5HS7e526WpSQPq7wSfwEZS/0jecKn8Gw82SPz8Vkenjf+IfIigPu57YcmHHaNtVA5 ccox4ugrzt7c28Q24/j/L5XVrYwSObLLINNrF32A0rfgMQQ/kn+VHNJz5n+arVtei1Ye fjuIvTErCHnvCYF+YMCnWKy5xkJyrs/b87MqffQksR3xIzqV1oiKcOFNyrcF1aNIV+fK Rnk5QSPJ8uJcuYHIQgnzCR7rax9xyVCZA3m7rO8mENjYvnFVp5yxwlRIZO2H50wuJQHQ absA== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr420986wik.30.1373966210968; Tue, 16 Jul 2013 02:16:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Tue, 16 Jul 2013 02:16:50 -0700 (PDT) In-Reply-To: <20130716063512.d48fcc385a64619952a52a66@tackymt.homeip.net> References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> <20130708140804.R26496@sola.nimnet.asn.au> <20130716063512.d48fcc385a64619952a52a66@tackymt.homeip.net> Date: Tue, 16 Jul 2013 02:16:50 -0700 X-Google-Sender-Auth: INxP5vDictfWGR0QVyIsAo1PoIU Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Taku YAMAMOTO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 09:16:52 -0000 I'll try it out soon, thanks! -adrian On 15 July 2013 14:35, Taku YAMAMOTO wrote: > This reminds me of my local patch which I wrote and forgot about deep in > the git :) > > This hack was required to have working USB ports on X61 after resume, > but I'm not sure whether it's still required because I don't have X61 han= dy > anymore... > > > On Mon, 8 Jul 2013 11:09:20 -0700 > Adrian Chadd wrote: > >> On 7 July 2013 22:00, Ian Smith wrote: >> >> > Checking one more point .. do the USB ports come up ok if you original= ly >> > boot with nothing plugged in? If so (or if not), does that local APIC >> >> Yes. >> >> > error message appear the same then too? >> >> > >> >> No >> >> >> -adrian >> _______________________________________________ >> 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" > > > -- > -|-__ =E5=B1=B1=E6=9C=AC=E3=80=80=E6=8B=93 / YAMAMOTO, Taku > | __ < > > - A chicken is an egg's way of producing more eggs. - From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 16 10:14:40 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 89666E54; Tue, 16 Jul 2013 10:14:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id CF051BF0; Tue, 16 Jul 2013 10:14:39 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y10so3474611wgg.4 for ; Tue, 16 Jul 2013 03:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jxMgEGD3jpjEh3dF5u3HQohdXIgP+2VpYW6izXmXgdY=; b=z2JJ2X9uYeq/6jgB7lKDbkAMIrjDtHWn1ZA/ln7DGRU9U8SBB3D3zquaqaK23325+j vnBZt1ZPf3PMXTPtx3CZUhCrjCZXwVnGk5lcpuLaMh84FSzLB7rVTqGzeOl9PrvdnyVc rdejkRCZ/4OVyeQ274UUMDRbU9WA3AgsvZerYDAfdru4w3UFNvJWHMYPD0O/xSbcFENY Xr4hb1/+Pl3BaWsPQ+wHY7HeMkVHYmUEeiGE4xb3pnhMhFok6W22dN4hhlc0xqZ0sRJ9 Qx93dXGEZsMETRAZriUZZF+Kh+gb/HAP5EC3pzmrcmV/eJWHKIDA0p1T+HgkZq7jx+Ta ILcw== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr587578wik.30.1373969679048; Tue, 16 Jul 2013 03:14:39 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Tue, 16 Jul 2013 03:14:38 -0700 (PDT) In-Reply-To: References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> <20130708140804.R26496@sola.nimnet.asn.au> <20130716063512.d48fcc385a64619952a52a66@tackymt.homeip.net> Date: Tue, 16 Jul 2013 03:14:38 -0700 X-Google-Sender-Auth: pPk_Q1s0OsWw-kuZe_31CIRx5wU Message-ID: Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume From: Adrian Chadd To: Taku YAMAMOTO Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 10:14:40 -0000 Nope, no such joy. What else can I try? -adrian On 16 July 2013 02:16, Adrian Chadd wrote: > I'll try it out soon, thanks! > > > > -adrian > > On 15 July 2013 14:35, Taku YAMAMOTO wrote: >> This reminds me of my local patch which I wrote and forgot about deep in >> the git :) >> >> This hack was required to have working USB ports on X61 after resume, >> but I'm not sure whether it's still required because I don't have X61 ha= ndy >> anymore... >> >> >> On Mon, 8 Jul 2013 11:09:20 -0700 >> Adrian Chadd wrote: >> >>> On 7 July 2013 22:00, Ian Smith wrote: >>> >>> > Checking one more point .. do the USB ports come up ok if you origina= lly >>> > boot with nothing plugged in? If so (or if not), does that local API= C >>> >>> Yes. >>> >>> > error message appear the same then too? >>> >>> > >>> >>> No >>> >>> >>> -adrian >>> _______________________________________________ >>> 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" >> >> >> -- >> -|-__ =E5=B1=B1=E6=9C=AC=E3=80=80=E6=8B=93 / YAMAMOTO, Taku >> | __ < >> >> - A chicken is an egg's way of producing more eggs. - From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 16 16:01:09 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CC035973; Tue, 16 Jul 2013 16:01:09 +0000 (UTC) (envelope-from taku@tackymt.homeip.net) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:470:fd92:0:20d:61ff:fecc:2253]) by mx1.freebsd.org (Postfix) with ESMTP id 8D19494; Tue, 16 Jul 2013 16:01:09 +0000 (UTC) Received: from basalt.tackymt.homeip.net (localhost [127.0.0.1]) by basalt.tackymt.homeip.net (Postfix) with ESMTP id 0E28583C5; Wed, 17 Jul 2013 01:01:09 +0900 (JST) X-Virus-Scanned: amavisd-new at tackymt.homeip.net Received: from localhost by basalt.tackymt.homeip.net (amavisd-new, unix socket) with ESMTP id 4lWkOTRRYL2v; Wed, 17 Jul 2013 01:01:07 +0900 (JST) Received: from basalt.tackymt.homeip.net (basalt.tackymt.homeip.net [IPv6:2001:470:fd92:0:20d:61ff:fecc:2253]) by basalt.tackymt.homeip.net (Postfix) with ESMTPSA; Wed, 17 Jul 2013 01:01:07 +0900 (JST) Date: Wed, 17 Jul 2013 01:01:06 +0900 From: Taku YAMAMOTO To: Adrian Chadd Subject: Re: USB ports on Lenovo T400 do not work after a suspend/resume Message-Id: <20130717010106.2f174c2b0dc1b50b95a9dde3@tackymt.homeip.net> In-Reply-To: References: <20130621220013.X55167@sola.nimnet.asn.au> <20130626152833.M78748@sola.nimnet.asn.au> <20130626195154.GK88288@e-new.0x20.net> <20130627213331.W26984@sola.nimnet.asn.au> <20130630233640.Y23789@sola.nimnet.asn.au> <20130707204957.GD88288@e-new.0x20.net> <20130708140804.R26496@sola.nimnet.asn.au> <20130716063512.d48fcc385a64619952a52a66@tackymt.homeip.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.6; i386-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-stable@freebsd.org, Ian Smith , freebsd-usb@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:01:10 -0000 On Tue, 16 Jul 2013 03:14:38 -0700 Adrian Chadd wrote: > Nope, no such joy. > > What else can I try? Maybe sysctl dev.[uoex]hci.*.wake=1 works. Other than that I have out of my ideas :(... > -adrian > > On 16 July 2013 02:16, Adrian Chadd wrote: > > I'll try it out soon, thanks! > > > > > > > > -adrian > > > > On 15 July 2013 14:35, Taku YAMAMOTO wrote: > >> This reminds me of my local patch which I wrote and forgot about deep in > >> the git :) > >> > >> This hack was required to have working USB ports on X61 after resume, > >> but I'm not sure whether it's still required because I don't have X61 handy > >> anymore... > >> > >> > >> On Mon, 8 Jul 2013 11:09:20 -0700 > >> Adrian Chadd wrote: > >> > >>> On 7 July 2013 22:00, Ian Smith wrote: > >>> > >>> > Checking one more point .. do the USB ports come up ok if you originally > >>> > boot with nothing plugged in? If so (or if not), does that local APIC > >>> > >>> Yes. > >>> > >>> > error message appear the same then too? > >>> > >>> > > >>> > >>> No > >>> > >>> > >>> -adrian > >>> _______________________________________________ > >>> 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" > >> > >> > >> -- > >> -|-__ 山本　拓 / YAMAMOTO, Taku > >> | __ < > >> > >> - A chicken is an egg's way of producing more eggs. - -- -|-__ 山本　拓 / YAMAMOTO, Taku | __ < - A chicken is an egg's way of producing more eggs. - From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 17 20:57:03 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2EF1F12B for ; Wed, 17 Jul 2013 20:57:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9648DB29 for ; Wed, 17 Jul 2013 20:57:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6HKuwdj010443; Wed, 17 Jul 2013 23:56:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6HKuwdj010443 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6HKuuDd010442; Wed, 17 Jul 2013 23:56:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Jul 2013 23:56:56 +0300 From: Konstantin Belousov To: Bruce Evans Subject: Re: Revisiting FPU context resume on i386 Message-ID: <20130717205656.GV5991@kib.kiev.ua> References: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> <20130716052641.GE91021@kib.kiev.ua> <20130716164612.P1088@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nccO0ldXW0cuDU6a" Content-Disposition: inline In-Reply-To: <20130716164612.P1088@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:57:03 -0000 --nccO0ldXW0cuDU6a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 06:54:57PM +1000, Bruce Evans wrote: > ISTR disagreeing with jkim on using a special save area. I believe the normal save area cannot be used there at all, since the suspension is async and fpu.c could perform some operation on the PCB-pointed save area while suspend IPI is received. > % /* Restore CR2, CR4, CR3 and CR0 */ > % ... > % movl PCB_CR0(%ecx),%eax > % movl %eax,%cr0 > % jmp 1f > % 1: >=20 > What's this magic null jump? I think this is not needed. It seems to be an attempt to follow Intel spec, which requires to perform the long jump after enabling the paging, probably code got copied somehow from locore. The jmp is needed in i386/acpica/acpu_wakecode.S, but it is wrong there as well, since it should be a long jump. Also, the comment before the %cr0 manipulations to set CR0_PG was copied from amd64 version and is irrelevant there. --nccO0ldXW0cuDU6a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR5wUXAAoJEJDCuSvBvK1B4GcQAIdQ6PdboCvLQrfisg0UHwhC T1X1TNve8bc547IQRXo4uteYfSuDU/w7PwJK0RniLxqp0VFkF1S8Qn0bup21k6o5 qwC3P3UWe5cYg/cvq6ymrtBvoCThrgaWYTiM3tFJPrdOs+PUyEXNx+ZlvjIVjHtf 9015/QNneJOnJOXCeU9DPOIJ0CQ5FX197oPrUfayzGBbeMjaWI5fKuTJa2OrMY9e VrTnDXzampYyEfBlHPulXCOaFnH1M6PX3QfU1ak9p/x8gxCjFWEPyJIDIm6LUaq4 TH/ZNeddnF5xr3464VMSoUQhO1Hzk0v+1yToB3xQKI4sn+zMQcbAJCU80s5yOgwG rISaKJ2LHCmBGSnrhBIuaV3mgjzz4AF0kBCs2cZ++zIjaUBkFlV2uCPXbEeF9FGG hWzIAN+534pJy6XurPOi4ZOr6QLLhG+p1UeI17BT255Ly65yhY7Y3K55FjT6RPGM B3lksua5oQsvmxhURHI7+acsupMnm9ACPPp/LBv0xkgcAcYI5o+UeXvwKnp09NXn nSSo4Tgaps3D4FEEh4vaxhDYRXepFlv3/n50hLFuRPKXuVav7kU6H6v3CM+yUIa8 3K3k0wE/JmVsjgLjmA3iBJMfQ0ChqLKCkL2ZToMu6ExlumKkfD1U9eYiTCr9JDE1 zhwTWN+ZUMo8M2t4OM/f =JYUR -----END PGP SIGNATURE----- --nccO0ldXW0cuDU6a-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 18 05:34:12 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3AF525F9 for ; Thu, 18 Jul 2013 05:34:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id D0D4978D for ; Thu, 18 Jul 2013 05:34:10 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 45E19D41FB5; Thu, 18 Jul 2013 15:34:00 +1000 (EST) Date: Thu, 18 Jul 2013 15:33:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: Revisiting FPU context resume on i386 In-Reply-To: <20130717205656.GV5991@kib.kiev.ua> Message-ID: <20130718150806.J857@besplex.bde.org> References: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> <20130716052641.GE91021@kib.kiev.ua> <20130716164612.P1088@besplex.bde.org> <20130717205656.GV5991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=XOoJF2RE c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=IpbkEbG0bHYA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=T3l0V36KyEQA:10 a=K71uCMlgZFfCaxTWLx8A:9 a=CjuIK1q_8ugA:10 Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 05:34:12 -0000 On Wed, 17 Jul 2013, Konstantin Belousov wrote: > On Tue, Jul 16, 2013 at 06:54:57PM +1000, Bruce Evans wrote: >> ISTR disagreeing with jkim on using a special save area. > I believe the normal save area cannot be used there at all, since > the suspension is async and fpu.c could perform some operation on > the PCB-pointed save area while suspend IPI is received. If that happens, then suspension is broken anyway. Any npx operation on the pcb (or any other operation on the pcb) between savectx() and resumectx() makes the state saved by savectx() out of date. In normal kernel operations, the npx state is changed from volatile to non-volatile by pushing it to the pcb. This prevents context switches from changing it underneath you by doing the same push to the pcb. (The state is not really changed, but the place where it lives and pointers and flags that say where it lives are changed.) I think this works perfectly for suspend/resume too. It is less clear what happens for non-npx parts of the pcb. Hopefully there are no races for them (and the special save area is not needed) because there is no lazy context switching for them -- they live either in the CPU or the pcb, and are switched between the CPU and the pcu atomically on every context switch. Clearly context switches must not be allowed between suspend and resume, or the resume must be on the same thread as the suspend. Otherwise resume restores state for a wrong thread, which is a much larger bug than races and inconsistencies in accessing separate save areas for the same thread. > ... > Also, the comment before the %cr0 manipulations to set CR0_PG was > copied from amd64 version and is irrelevant there. I can't find this comment or any setting of CR0_PG in either swtch.s file. Bruce From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 18 11:38:25 2013 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 87C3C8F for ; Thu, 18 Jul 2013 11:38:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D3AAE8AF for ; Thu, 18 Jul 2013 11:38:24 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6IBcGNe017943; Thu, 18 Jul 2013 14:38:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6IBcGNe017943 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6IBcEkl017942; Thu, 18 Jul 2013 14:38:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 18 Jul 2013 14:38:14 +0300 From: Konstantin Belousov To: Bruce Evans Subject: Re: Revisiting FPU context resume on i386 Message-ID: <20130718113814.GB5991@kib.kiev.ua> References: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> <20130716052641.GE91021@kib.kiev.ua> <20130716164612.P1088@besplex.bde.org> <20130717205656.GV5991@kib.kiev.ua> <20130718150806.J857@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SBKwXYz1xY/kcGv0" Content-Disposition: inline In-Reply-To: <20130718150806.J857@besplex.bde.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 11:38:25 -0000 --SBKwXYz1xY/kcGv0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 18, 2013 at 03:33:59PM +1000, Bruce Evans wrote: > On Wed, 17 Jul 2013, Konstantin Belousov wrote: >=20 > > On Tue, Jul 16, 2013 at 06:54:57PM +1000, Bruce Evans wrote: > >> ISTR disagreeing with jkim on using a special save area. > > I believe the normal save area cannot be used there at all, since > > the suspension is async and fpu.c could perform some operation on > > the PCB-pointed save area while suspend IPI is received. >=20 > If that happens, then suspension is broken anyway. Any npx operation Yes, it is broken, but not for FPU. For the fpu.c, the actions in the IPI handler and later in resume path are invisible. > on the pcb (or any other operation on the pcb) between savectx() and > resumectx() makes the state saved by savectx() out of date. In normal > kernel operations, the npx state is changed from volatile to non-volatile > by pushing it to the pcb. This prevents context switches from changing > it underneath you by doing the same push to the pcb. (The state is not > really changed, but the place where it lives and pointers and flags that > say where it lives are changed.) I think this works perfectly for > suspend/resume too. It is less clear what happens for non-npx parts of > the pcb. Hopefully there are no races for them (and the special save > area is not needed) because there is no lazy context switching for them > -- they live either in the CPU or the pcb, and are switched between the > CPU and the pcu atomically on every context switch. Clearly context > switches must not be allowed between suspend and resume, or the resume > must be on the same thread as the suspend. Otherwise resume restores > state for a wrong thread, which is a much larger bug than races and > inconsistencies in accessing separate save areas for the same thread. I do not understand what you described there. Assume that e.g. the CPU was in fpudna() code and performs the bcopy() from fpu_initialstate when the suspend IPI was delivered. Then saving the current HW state into the same PCB save area causes corruption. I do not disagree that the current async suspension is broken, but it is for different reasons. Basically, it delegates too much work to the drivers device_suspend methods, requiring the routine to be mutually exclusive with any access to the hardware. I do not think that any driver gets this right. IMO sleep state should be only entered when all threads are parked either at safe sleep point or at the kernel->user bounday. Even this is not enough if there is in-flight sleepable operation in some device, but that part is indeed in the competence of the driver suspend method. >=20 > > ... > > Also, the comment before the %cr0 manipulations to set CR0_PG was > > copied from amd64 version and is irrelevant there. >=20 > I can't find this comment or any setting of CR0_PG in either swtch.s > file. I referred to the sys/i386/acpica/acpi_wakecode.S, which is the caller of restorectx(). --SBKwXYz1xY/kcGv0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR59OmAAoJEJDCuSvBvK1B6zMQAIJYIj0OERQETNiRzCLAP8dn zUMxeDeENBwb7TL96wzwZyzkzDEUv3qIAiwhMKj0axG7B5KdwxvWSEYFPxYXMyzx yK/TpPXyHAGQ1/9MH89gVh6CZgR+ceQJ0dAgYaAC+koRornlUWnn0efzOn9AKsvL ZHK++v7+As6nTTjSSx5qb/YecRw8k5BdYEG0bgLo61gDxEZteG1Z3BQ0x1Mk1ray aqbVI9mPtn2E0j0Cy3GtYtquKuheKeZiemHuJ9l0r+zSsODTKAIBwXFt/k1mU6Uf IsKd6+XMXm5YlqHiR0J8L+SJOmKUrXohQNaEnfsRkvk9E59hhNhMx+9hvcgKUXFE NDEY57rUexbPYQL87IXk+O2jt4a6QXiMi7cfXxRS70VKeFrEl9dKVsB3wr3kADD2 END+tdhvV84zGFx4cLeGud1G+MnRwzzHsUbQjrDhxXpUlWzteK1B+NbgaKeWyCT1 TMqS0XvJGyTGoWkFKXAauggCbY4KzbZtCGSdbcf18YHIaPiWiGxRMcfmsXsjyGXd dsFACuwmUxF0daPpe3GyHuuUhHvbwz+EOKA1jHMGTTuqTh/FwRXFN43bD+kyd40k Bf41FdhyPO5qhOydjqO+DWsQzqC4yc7vxczwOhPjJrraS4Rni9zLZbgj9LtNeUFZ 59qs2cjfQS5UDPkO4Cry =zmDl -----END PGP SIGNATURE----- --SBKwXYz1xY/kcGv0-- From owner-freebsd-acpi@FreeBSD.ORG Thu Jul 18 13:03:21 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 00FD1B27 for ; Thu, 18 Jul 2013 13:03:20 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 7555DCB3 for ; Thu, 18 Jul 2013 13:03:20 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 31C68D4079A; Thu, 18 Jul 2013 23:03:13 +1000 (EST) Date: Thu, 18 Jul 2013 23:03:12 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov Subject: Re: Revisiting FPU context resume on i386 In-Reply-To: <20130718113814.GB5991@kib.kiev.ua> Message-ID: <20130718220100.T2053@besplex.bde.org> References: <20130716070716.15b7282b9dca2cbc8a767631@tackymt.homeip.net> <20130716052641.GE91021@kib.kiev.ua> <20130716164612.P1088@besplex.bde.org> <20130717205656.GV5991@kib.kiev.ua> <20130718150806.J857@besplex.bde.org> <20130718113814.GB5991@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=YYGEuWhf c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=IpbkEbG0bHYA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=T3l0V36KyEQA:10 a=tZAENyXPNEgAMN_VtwoA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 13:03:21 -0000 On Thu, 18 Jul 2013, Konstantin Belousov wrote: > On Thu, Jul 18, 2013 at 03:33:59PM +1000, Bruce Evans wrote: >> On Wed, 17 Jul 2013, Konstantin Belousov wrote: >> >>> On Tue, Jul 16, 2013 at 06:54:57PM +1000, Bruce Evans wrote: >>>> ISTR disagreeing with jkim on using a special save area. >>> I believe the normal save area cannot be used there at all, since >>> the suspension is async and fpu.c could perform some operation on >>> the PCB-pointed save area while suspend IPI is received. >> >> If that happens, then suspension is broken anyway. Any npx operation > Yes, it is broken, but not for FPU. For the fpu.c, the actions in the > IPI handler and later in resume path are invisible. > >> on the pcb (or any other operation on the pcb) between savectx() and >> resumectx() makes the state saved by savectx() out of date. In normal >> kernel operations, the npx state is changed from volatile to non-volatile >> by pushing it to the pcb. This prevents context switches from changing >> it underneath you by doing the same push to the pcb. (The state is not >> really changed, but the place where it lives and pointers and flags that >> say where it lives are changed.) I think this works perfectly for >> suspend/resume too. It is less clear what happens for non-npx parts of >> the pcb. Hopefully there are no races for them (and the special save >> area is not needed) because there is no lazy context switching for them >> -- they live either in the CPU or the pcb, and are switched between the >> CPU and the pcu atomically on every context switch. Clearly context >> switches must not be allowed between suspend and resume, or the resume >> must be on the same thread as the suspend. Otherwise resume restores >> state for a wrong thread, which is a much larger bug than races and >> inconsistencies in accessing separate save areas for the same thread. > I do not understand what you described there. Assume that e.g. the CPU > was in fpudna() code and performs the bcopy() from fpu_initialstate > when the suspend IPI was delivered. Then saving the current HW state > into the same PCB save area causes corruption. Hmm. The npx code was designed to be safe when interrupted (because on i386's without exception 16, irq13 was used for npx traps and protection against that protects against other interrupts too). It has rotted a bit, but still seems to be safe against preemption by (maskable) IPIs except for that bcopy(), and where you changed the interrupt disabling to critical sections, and perhaps in some of your newer state-chaining code. amd64 is not very different from i386, except it misspells "npx" as "fpu". The misspelling makes it hard to refer to functions that act the same. In the following, npx means i386-only and NPX means either i386 or amd64. (You didn't change the comment about disabling interrupts before npxsave(). The comment still says that callers must disable interrupts, and on i386 the savectx() caller still disables interrupts. I think the cpu_switch() caller uses a spinlock on amd64 and i386, so interrupts are disabled there too. On amd64, ctx_fpusave() doesn't explicitly disable interrupts or use a critical section, but it doesn't need to since it doesn't change the state.) All the old code except NPXgetregs() seems to be protected by either a critical section or disabling interrupts. NPXgetregs() uses a critical section for the main part, but not for the special case which does the bcopy() of the initial state. This case assumes that it cannot be interrupted. This assumptiont was even correct for irq13 when irq13 was used, since irq13 can't happen before the npx is used. Expand this critical section and change the critical sections back to interrupts disabled and NPX should be almost interrupt-safe. There seem to be some problems like the ones in NPXgetregs() in your newer code. For example, fpu_kern_enter() doesn't use a critical section except when it calls NPXexit() (in the call). fpu_kern_leave() uses a critical section only around NPXdrop(). I had forgotten exactly how much AVX support was in i386 and thought that it wasn't there yet, since savectx() didn't't seem to do enough to support it. It seems to be all there. Anyway, on i386 savectx() still always saves the npx state to the pcb first, so the special save area doesn't help avoid the races for the npx part of the pcb, and removing the copying via the pcb would fix more than a style bug. i386 seems to need a special npxsave() like amd64, since the normal one has side effects on the pcb and pcpu even when directed to write to a special save area. Bruce - Bruce