Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752299AbWCRHYE (ORCPT ); Sat, 18 Mar 2006 02:24:04 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752283AbWCRHYE (ORCPT ); Sat, 18 Mar 2006 02:24:04 -0500 Received: from mraos.ra.phy.cam.ac.uk ([131.111.48.8]:16589 "EHLO mraos.ra.phy.cam.ac.uk") by vger.kernel.org with ESMTP id S1752249AbWCRHYB (ORCPT ); Sat, 18 Mar 2006 02:24:01 -0500 To: "Yu, Luming" cc: linux-kernel@vger.kernel.org, "Linus Torvalds" , "Andrew Morton" , "Tom Seeley" , "Dave Jones" , "Jiri Slaby" , michael@mihu.de, mchehab@infradead.org, "Brian Marete" , "Ryan Phillips" , gregkh@suse.de, "Brown, Len" , linux-acpi@vger.kernel.org, "Mark Lord" , "Randy Dunlap" , jgarzik@pobox.com, "Duncan" <1i5t5.duncan@cox.net>, "Pavlik Vojtech" , "Meelis Roos" Subject: Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT] In-Reply-To: Your message of "Sat, 18 Mar 2006 10:02:45 +0800." <3ACA40606221794F80A5670F0AF15F84041AC266@pdsmsx403> Date: Sat, 18 Mar 2006 07:23:56 +0000 From: Sanjoy Mahajan Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2254 Lines: 53 >> Which is why I think the minimal change is the diff above to >> utils.c [to make acpi_evaluate_integer fake _TMP]. With that >> change the system never hung. > Good, this is exactly what I wanted. How many times you tested with > this hack without hang? Sadly, I just tried it again and it hung. But from looking at my old emails and test results, I know why. I made the previous tests with only THM0 loaded. The bisection began by loading only THM0 (by having acpi_thermal_add() ignore THM[267]). The hang still happened, so I never tested whether THM[267] also have problems: chase one problem at a time. To test the theory, I recompiled to recreate the kernel with the utils.c change [to make acpi_evaluate_integer fake _TMP] and with only THM0 loaded (i.e. what I had tested and reported a few days ago). It didn't hang (10 cycles), which repeats my previous result. > The short-term proper way could be: > 1. add a global variable: acpi_in_suspend. > 2. in acpi_pm_prepare: > a.call acpi_os_wait_events_complete() > b.set acpi_in_suspend = YES. > in acpi_pm_finish : > set acpi_in_suspend = NO. > 3. in acpi_thermal_run: > if (acpi_in_suspend == YES) > do nothing. I tested the included diff to implement the above short-term fix. It also hung on the second sleep. BUT, it's the same reason that the utils.c change didn't help: because acpi_thermal_add() was loading THM[0267]. After the usual modification to acpi_thermal_add() to have it ignore THM[267], the system didn't hang (12 cycles). Which is progress. So I conclude that this diff does fix the THM0 problem, but that at least one other thermal zone has a problem, and the problem is not _TMP. Or at least, the problem is not the same one that THM0 has (running thermal threads at suspend time), otherwise the diff would fix it like it fixed THM0. I guess I should try loading only one of THM2,6,7 to see which zones besides THM0 produce a problem, and then narrow the problem to one method within the zone. -Sanjoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/