ACPI: Protection from suspending in the middle of EC transaction
in [Kernel]
|
Prev: netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f
Next: Toyota.......Award......Lucky.....Winner
From: Alexey Starikovskiy on 1 Feb 2010 05:30 Henrique de Moraes Holschuh пишет: > On Sun, 31 Jan 2010, Maxim Levitsky wrote: >> Unfortunately, this patch even causes regressions on my notebook (it >> survive 63 hibernate cycles), but now I battery driver reports 'battery >> absent', backlight driver reports 0 brightness, but reload helped. > > ... > >> I think that not only _PTS ans _WAK are problematic. What about other >> ACPI drivers that start accessing the EC before it is resumed? >> I think that these cause the problems I observe. > > ACPI drivers might access the EC (even indirectly, through the DSDT). And > platform drivers do often access the EC both at suspend and resume time. Actually, only SBS and thinkpad-acpi access EC directly. All others go through DSDT for access. Still, stopping EC in .suspend is too early, IMHO... > > This needs some sort of strong ordering, the EC must suspend last, and > resume first (as seen by any ACPI and ACPI-aware drivers such as libata, > some platform drivers, etc). If EC interrupts are a problem, maybe it can > be kicked to poll mode for the suspend/resume transition? It's this way already for about a year now... The problem is that EC driver might be stopped in middle of the transaction, thus leaving EC in unknown state for BIOS or switch-over kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |