From owner-freebsd-bugs@FreeBSD.ORG Sun Sep 1 15:40:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 111E9458 for ; Sun, 1 Sep 2013 15:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F0B9D239E for ; Sun, 1 Sep 2013 15:40:01 +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 r81Fe1eu064771 for ; Sun, 1 Sep 2013 15:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r81Fe1Yc064770; Sun, 1 Sep 2013 15:40:01 GMT (envelope-from gnats) Date: Sun, 1 Sep 2013 15:40:01 GMT Message-Id: <201309011540.r81Fe1Yc064770@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Mike Harding Subject: Re: kern/181632: 9.2-RC3 - on resume from suspend, disk operations are slower X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Mike Harding List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2013 15:40:02 -0000 The following reply was made to PR kern/181632; it has been noted by GNATS. From: Mike Harding To: Andriy Gapon Cc: bug-followup@freebsd.org Subject: Re: kern/181632: 9.2-RC3 - on resume from suspend, disk operations are slower Date: Sun, 1 Sep 2013 08:34:02 -0700 --047d7bb0435c686c9204e5542fed Content-Type: text/plain; charset=ISO-8859-1 Yes, I did notice the list of things to check. Nothing significant is different in the cpu states (just temperature, etc.), no hcpi differences, and no processes returned by your code fragment. I have isolated my issue to this particular line of code, which has been changed (from my point of view) in 9.2-RC and different in 9.1. It is 100% repeatable. No previous released version of FreeBSD has this change in it. You introduced it, if it caused 'increased power consumption and heat production" with the previous version, it would have been noticed by now I think. As you point out, it runs rarely. I only see this issue after a suspend/resume on a desktop machine, which is not something most people do, I am sure. The only place I see the disable idle calls in this file are acpi_cpu_shutdown, acpi_cpu_suspend, and acpi_cpu_startup. It's possible that introducing a 'hlt' into the code path in these calls is causing a deadlock, race condition, or other issue that is not immediately obvious. The only symptom I have is that disk operations are very slow, which is probably an interrupt issue or hardware suspend/resume issue. I am running a pretty generic system (Intel I5 750, Asus motherboard). It is 100% repeatable, do you have a machine with multiple CPUs that you can try this with? Do you have a machine with working suspend/resume? Given that the line in question appears to only run during startup, suspend/resume and shutdown, I think that reverting this -single line- to the version that has run on previous released versions of FreeBSD rather than a version that causes a demonstrated issue is prudent. The only difference should be that a 'hlt' call will not occur during startup, shutdown or suspend, which are very short transitions. I am using an Intel i5 750 with this motherboard: http://www.asus.com/Motherboards/P7P55D/, which is running fairly common hardware. Is there anything else I can do? I can give you ssh access to the system in question. On Sat, Aug 31, 2013 at 11:39 PM, Andriy Gapon wrote: > on 31/08/2013 20:05 Mike Harding said the following: > > I reverted the single line at > > > > > http://svnweb.freebsd.org/base/stable/9/sys/dev/acpica/acpi_cpu.c?annotate=244616&pathrev=244616#l978 > > Thank you for narrowing this down! > > > Given that the code says > > > > /* If disabled, take the safe path. */ > > 977 if (is_idle_disabled(sc)) { > > 978 acpi_cpu_c1(); > > 979 return; > > 980 } > > > > > > and then does a 'hlt' or idle if idle is disabled, this might be a > problem. > > But it should not be a problem. > > First, is_idle_disabled should not be normally set. It is supposed to be > set > only during short transitional periods. So it would be useful to > understand why > it is set (after resume) and makes the difference. > > Second, "idle is disabled" means that the ACPI C-state machine is > disabled, not > that the system must not idle at all. In fact, being in this function > (acpi_cpu_idle) means that the system explicitly wants to idle. Using hlt > to > idle is the right / normal / safe thing. Not using hlt means that the > system > keeps burning cycles even when it has nothing to do. So with your change > you > should observe increased power consumption and heat production. > So, this is another mystery as to why the perfectly normal use of hlt > affects > your system so badly. > > P.S. I hope that you noticed a list of things to look at in my previous > followup > to this PR. > -- > Andriy Gapon > --047d7bb0435c686c9204e5542fed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, I did notice the l= ist of things to check.=A0 Nothing significant is different
in the= cpu states (just temperature, etc.), no hcpi differences, and no
= processes returned by your code fragment.

I have isolated my issue to this particular line of code, which h= as been changed
(from my point of view) in 9.2-RC and differe= nt in 9.1.=A0 It is 100% repeatable.
No previous released ver= sion of FreeBSD has this change in it.=A0 You
introduced it, if it caused 'increased power consumption and heat produ= ction"
with the previous version, it would have been not= iced by now I think.
As you point out, it runs rarely.=A0 I only see thi= s issue after a suspend/resume
on a desktop machine, which is not something most people do, I am sure.
=

The only place I see the disable idle calls in th= is file are acpi_cpu_shutdown,
acpi_cpu_suspend, and acpi_cpu_startup.= =A0 It's possible that introducing
a 'hlt' into the code path in these calls is causing a d= eadlock, race condition,
or other issue that is not immediate= ly obvious.=A0 The only symptom I have is
that disk operations are very = slow, which is probably an interrupt issue or
hardware suspend/resume issue.

I am runn= ing a pretty generic system (Intel I5 750, Asus
motherboard).=A0 I= t is 100% repeatable, do you have a machine with multiple
CPU= s that you can try this with?=A0 Do you have a machine with working
suspend/resume?

Given that the line in question appears t= o only run during startup, suspend/resume
and shutdown, I think that rev= erting this -single line- to the version that has run
on previous releas= ed versions of FreeBSD rather than a version that causes a
demonstrated issue is prudent.=A0 The only difference should be that a '= ;hlt'
call will not occur during startup, shutdown or sus= pend, which are very
short transitions.

I a= m using an Intel i5 750 with this motherboard: http://www.asus.com/Motherboards/P7P55D/,
which is running fairly common hardware.

Is th= ere anything else I can do?=A0 I can give you ssh access to the system inquestion.


On Sat, Aug 31, 2013 at 11:39 PM, Andriy Gapon <avg@freebsd.org> wrote:
on 31/08/2013 20:05 Mike Harding said the following:
> I reverted the single line at
>
> http:= //svnweb.freebsd.org/base/stable/9/sys/dev/acpica/acpi_cpu.c?annotate=3D244= 616&pathrev=3D244616#l978

Thank you for narrowing this down!

> Given that the code says
>
> /* If disabled, take the safe path. */
> 977 =A0 if (is_idle_disabled(sc)) {
> 978 =A0 acpi_cpu_c1();
> 979 =A0 return;
> 980 =A0 }
>
>
> and then does a 'hlt' or idle if idle is disabled, this might = be a problem.

But it should not be a problem.

First, is_idle_disabled should not be normally set. =A0It is supposed to be= set
only during short transitional periods. =A0So it would be useful to underst= and why
it is set (after resume) and makes the difference.

Second, "idle is disabled" means that the ACPI C-state machine is= disabled, not
that the system must not idle at all. =A0In fact, being in this function (acpi_cpu_idle) means that the system explicitly wants to idle. =A0Using hl= t to
idle is the right / normal / safe thing. =A0Not using hlt means that the sy= stem
keeps burning cycles even when it has nothing to do. =A0So with your change= you
should observe increased power consumption and heat production.
So, this is another mystery as to why the perfectly normal use of hlt affec= ts
your system so badly.

P.S. I hope that you noticed a list of things to look at in my previous fol= lowup
to this PR.
--
Andriy Gapon

--047d7bb0435c686c9204e5542fed--