mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk>
To: "Brown, Len" <len.brown@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	akpm@osdl.org, torvalds@osdl.org, linux-kernel@vger.kernel.org,
	axboe@suse.de, James.Bottomley@steeleye.com, greg@kroah.com,
	linux-acpi@vger.kernel.org,
	linux-usb-devel@lists.sourceforge.net, "Yu,
	Luming" <luming.yu@intel.com>,
	lk@bencastricum.nl, helgehaf@aitel.hist.no, fluido@fluido.as,
	gbruchhaeuser@gmx.de, Nicolas.Mailhot@LaPoste.net, perex@suse.cz,
	tiwai@suse.de, patrizio.bassi@gmail.com, bni.swe@gmail.com,
	arvidjaar@mail.ru, p_christ@hol.gr, ghrt@dial.kappa.ro,
	jinhong.hu@gmail.com, andrew.vasquez@qlogic.com,
	linux-scsi@vger.kernel.org, bcrl@kvack.org
Subject: Re: Linux 2.6.16-rc3
Date: Tue, 14 Feb 2006 16:17:01 -0500	[thread overview]
Message-ID: <E1F97Xh-000138-59@approximate.corpus.cam.ac.uk> (raw)
In-Reply-To: Your message of "Mon, 13 Feb 2006 03:02:46 EST." <F7DC2337C7631D4386A2DF6E8FB22B30060BD1D9@hdsmsx401.amr.corp.intel.com>

> I don't think anybody claimed this isn't a regression for the 600X.

I narrowed it further.  The short story is that this commit (diff below
sig) makes the second S3 sleep go into the endless loop, if the loaded
modules are exactly thermal, processor, intel_agp, and agpgart:

53f11d4ff8797bcceaf014e62bd39f16ce84baec is first bad commit
diff-tree 53f11d4ff8797bcceaf014e62bd39f16ce84baec (from 02b28a33aae93a3b53068e0858d62f8bcaef60a3)
Author: Len Brown <len.brown@intel.com>
Date:   Mon Dec 5 16:46:36 2005 -0500

    [ACPI] Enable Embedded Controller (EC) interrupt mode by default
    
    "ec_intr=0" reverts to polling
    "ec_burst=" no longer exists.
    
    Signed-off-by: Len Brown <len.brown@intel.com>
    Acked-by: Luming Yu <luming.yu@intel.com>

:040000 040000 9eec66712c68ebe372b2fb2c8d78bdc99df942ab e7e62cd09983730aee468edd4ba1cce50786b7e5 M	Documentation
:040000 040000 6e7db46918f6124f64a11f6757560078a8a27519 aa8abb1023024902300cb2e7a5bf74acd8c579e8 M	drivers

If I boot with ec_intr=0, the second sleep works fine.

Here is the full story.  First I tried a system with the minimal set of
modules to boot and run X (S3 sleep-wake wrecks the VGA consoles, but X
restores fine with 'chvt 1; sleep 0.5 ; chvt 7' on wakeup).  So I
stopped every service and unloaded all modules possible, which left only
intel_agp and agpgart.  Then, for each of the usual loaded modules
(except for sound modules, which often has sleep-wake problems anyway),
I tried:

1. Load the module
2. S3 sleep-wake-sleep-wake
3. Unload the module

to see whether the second sleep went into the infinite loop (visible
across the console).  The one culprit I found was 'thermal' (which
brings in 'processor').  Other modules didn't trigger the problem.

Then I recompiled using a minimal config, with only networking (for X to
work) and the acpi modules, and maybe a few others that I couldn't
avoid, and retested to make sure 'thermal' still triggered the problem,
which it did.  I used this config, or one just like it for 2.6.15, as a
base for all other kernels in the bisection search, using the nearest
ancestor's .config and then
   yes '' | make oldconfig
to make the new .config

Eventually bisection converged to the commit above, and then I retested
that kernel with 'ec_intr=0'.

Is this a problem with the TP 600X hardware, in which case I'll just use
ec_intr=0 forever, or is there more software debugging (DSDT or related
to the diff)?  I can turn on gobs of ACPI debugging and send the useful
parts of the log file.

In the bisection, many kernels worked fine, meaning that the second S3
cycle returned and I could compile the next bisection kernel.  In doing
that I noticed another problem, that the fan would not turn on with some
of these good kernels even though the system was hot enough (plenty of
chance for it to turn on since the next compile heated up the CPU).  For
example, acpi -t showed

     Thermal 1: ok, 46.0 degrees C
     Thermal 2: active[0], 42.0 degrees C
     Thermal 3: ok, 31.0 degrees C
     Thermal 4: ok, 34.0 degrees C

but the fan was off.  

So whenever I had a good kernel (meaning taht S3 sleep-wake-sleep-wake
returned), I checked whether the fan would turn on, to collect data for
a separate bisection search.  However, the data seems inconsistent.  If
I feed the data to a fresh git bisect, it complains about one commit
being marked both good and bad.  So I'll ask on the git list about that
issue.

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   - Bertrand de Jouvenal


diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 5dffcfe..2ad64ef 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -452,6 +452,11 @@ running once the system is up.
 
 	eata=		[HW,SCSI]
 
+	ec_intr=	[HW,ACPI] ACPI Embedded Controller interrupt mode
+			Format: <int>
+			0: polling mode
+			non-0: interrupt mode (default)
+
 	eda=		[HW,PS2]
 
 	edb=		[HW,PS2]
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index bb3963b..d4366ad 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -73,7 +73,7 @@ static struct acpi_driver acpi_ec_driver
 	.class = ACPI_EC_CLASS,
 	.ids = ACPI_EC_HID,
 	.ops = {
-		.add = acpi_ec_poll_add,
+		.add = acpi_ec_intr_add,
 		.remove = acpi_ec_remove,
 		.start = acpi_ec_start,
 		.stop = acpi_ec_stop,
@@ -147,7 +147,7 @@ static union acpi_ec *ec_ecdt;
 
 /* External interfaces use first EC only, so remember */
 static struct acpi_device *first_ec;
-static int acpi_ec_poll_mode = EC_POLL;
+static int acpi_ec_poll_mode = EC_INTR;
 
 /* --------------------------------------------------------------------------
                              Transaction Management
@@ -1594,4 +1594,4 @@ static int __init acpi_ec_set_intr_mode(
 	return 0;
 }
 
-__setup("ec_burst=", acpi_ec_set_intr_mode);
+__setup("ec_intr=", acpi_ec_set_intr_mode);

  parent reply	other threads:[~2006-02-14 21:17 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-13  8:02 Brown, Len
2006-02-13  8:12 ` Andrew Morton
2006-02-13  8:42   ` Sanjoy Mahajan
2006-02-13  8:57   ` Arjan van de Ven
2006-02-14  3:08     ` Michal Jaegermann
2006-02-14  3:28       ` Andrew Morton
2006-02-14  4:48         ` Dave Jones
2006-02-14  5:29         ` Arjan van de Ven
2006-02-14  6:22         ` Michal Jaegermann
2006-02-16 23:04         ` Pavel Machek
2006-02-14  3:30       ` Lee Revell
2006-02-14  6:55         ` Michal Jaegermann
2006-02-14  5:31       ` Arjan van de Ven
2006-02-14 21:17 ` Sanjoy Mahajan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-02-14  6:23 Brown, Len
2006-02-13  7:07 Brown, Len
2006-02-13  7:13 ` David S. Miller
2006-02-13  7:43 ` Sanjoy Mahajan
2006-02-13  6:59 Brown, Len
2006-02-13  1:19 Linus Torvalds
2006-02-13  3:05 ` Andrew Morton
2006-02-13  3:22   ` Trond Myklebust
2006-02-13 15:09     ` Benjamin LaHaise
2006-02-13  3:28   ` Sanjoy Mahajan
2006-02-13  3:36   ` Jeff Garzik
2006-02-13  4:40   ` James Bottomley
2006-02-13  7:04   ` Arjan van de Ven
2006-02-13  8:11   ` Jens Axboe
2006-02-13  9:22   ` Patrizio Bassi
2006-02-13 12:02   ` Takashi Iwai
2006-02-13 12:37     ` Patrizio Bassi
2006-02-13 13:13       ` Takashi Iwai
2006-02-13 13:31         ` Patrizio Bassi
2006-02-13 14:15           ` Takashi Iwai
2006-02-13 14:34             ` Patrizio Bassi
2006-02-13 14:39               ` Takashi Iwai
2006-02-13 13:09     ` Rafael J. Wysocki
2006-02-13 13:51       ` Takashi Iwai
2006-02-13 19:33         ` Rafael J. Wysocki
2006-02-13 16:36     ` Thierry Vignaud
2006-02-13 16:36     ` Thierry Vignaud
2006-02-15  6:51       ` Andrew Morton
2006-02-15 13:40         ` Thierry Vignaud
2006-02-15 20:00           ` Andrew Morton
2006-02-13 16:10   ` Adrian Bunk
2006-02-13 19:31     ` Daniel Drake
2006-02-13 20:30   ` Paul Fulghum
2006-02-13 20:38   ` Greg KH
2006-02-14 16:34     ` James Bottomley
2006-02-16  1:56       ` James Bottomley
2006-02-16 17:12         ` Russell King
2006-02-16 17:34           ` Stefan Richter
2006-02-16 17:57           ` James Bottomley
2006-02-16 18:09             ` Russell King
2006-02-16 18:14               ` James Bottomley
2006-02-16 18:18                 ` Russell King
2006-02-16 19:09                   ` James Bottomley
2006-02-16 20:01                     ` Jens Axboe
2006-02-18  0:42                       ` James Bottomley
2006-02-18  1:00                         ` Greg KH
2006-02-18  2:12                         ` Roland Dreier
2006-02-18 21:06   ` Helge Hafting
2006-02-22 16:49   ` Ben Castricum
2006-02-13  8:46 ` Jan Dittmer
2006-02-13  9:07   ` Yoichi Yuasa
2006-02-13 15:47   ` Linus Torvalds
2006-02-13 22:11     ` Jan Dittmer
     [not found] ` <3aa654a40602130231p1c476e99paa986fa198951839@mail.gmail.com>
2006-02-13 10:39   ` Andrew Morton
2006-02-13 10:54     ` Con Kolivas
2006-02-13 17:27       ` Andi Kleen
     [not found]     ` <3aa654a40602130251t174a5e4bg28a52a147cc9b2cf@mail.gmail.com>
2006-02-13 10:56       ` Andrew Morton
2006-02-14  2:44         ` Andrew Morton
2006-02-14  2:54           ` Dave Jones
2006-02-14  3:21             ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1F97Xh-000138-59@approximate.corpus.cam.ac.uk \
    --to=sanjoy@mrao.cam.ac.uk \
    --cc=James.Bottomley@steeleye.com \
    --cc=Nicolas.Mailhot@LaPoste.net \
    --cc=akpm@osdl.org \
    --cc=andrew.vasquez@qlogic.com \
    --cc=arvidjaar@mail.ru \
    --cc=axboe@suse.de \
    --cc=bcrl@kvack.org \
    --cc=bni.swe@gmail.com \
    --cc=davem@davemloft.net \
    --cc=fluido@fluido.as \
    --cc=gbruchhaeuser@gmx.de \
    --cc=ghrt@dial.kappa.ro \
    --cc=greg@kroah.com \
    --cc=helgehaf@aitel.hist.no \
    --cc=jinhong.hu@gmail.com \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=lk@bencastricum.nl \
    --cc=luming.yu@intel.com \
    --cc=p_christ@hol.gr \
    --cc=patrizio.bassi@gmail.com \
    --cc=perex@suse.cz \
    --cc=tiwai@suse.de \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®