> This sounds like the problem Daniel had on his Samsung P35 recently. > He could fix it by getting rid of some asus_unhide_smbus stuff or the > otherway around, adding asus_unhide_smbus quirks in the S3 resume code. > > This thread was recently posted on lkml: > Re: [patch] smbus unhiding kills thermal management > That seems likely, thanks for the pointer: Besides the ACPI sleep hangs, this machine (TP 600X) has fan troubles upon S3 resume. The problems don't do harm (the damn fan keeps turning on when it shouldn't), but that's probably chance. Various patches that I tested for S3 resume hangs reversed this fan behavior, making the fan refuse to turn on when it should have. The same problem happened after resume from swsusp (bugzilla #5000). > https://bugzilla.novell.com/show_bug.cgi?id=173420 >From Comment #30 at the above url: "The Linux ACPI code seems to actively prevent the fan from running and that worries me." I saw that as well, and found the following recipe would work around the problem: 1. Set the trip point to, say, 70 C -- well above the actual temperature. 2. Then set the trip to anything reasonable that's under the current temperature (27 C always works). Now the fan turns on, and behaves fine from then. My explanation is that, before step 1, the fan is off but the OS thinks it's on. So the dialogue goes something like: Hardware (from EC or BIOS?): Ack, I'm overheating, turn on the fan now! OS: There, there, take it easy. I've checked bit fields in my memory, and the fan is on. So I don't have to do anything. Hardware: Ack, ... OS: There, there, ... [Hence the 100% kacpid CPU usage] Based on this explanation, I added a resume method to the fan driver. It would turn on the fan and mark it as on. So then the internal OS state matched the actual state. The fix didn't work for at least one reason: ACPI drivers didn't have suspend/resume methods (though now there are test patches to add those methods). Another fix, probably worth doing anyway, is to turn on the fan if the BIOS asks for it, whether or not the OS thinks it's on. The chance of the two pieces of information getting out of synch, and the hardware damage it can cause, is enough to make it worthwhile. The reverse case can try to optimize (if BIOS asks to shut off the fan, shut it off only if OS thinks it's on). That creates no danger: just extra fan noise if the fan is on but the OS thinks it's off. -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
