On 2 Apr 2011, [email protected] spake thusly: > On 29 Mar 2011, [email protected] outgrape: > >> On 29 Mar 2011, Kenneth Crudup verbalised: >> >>> Has anyone been able to get the 2.6.38 series of kernels to resume properly? >>> >>> No matter what I've tried (incl. removing the NVidia driver), it panic()s on >>> resume even the first time. >> >> Works perfectly for me. Dozens of resumes. > > What an idiot I am, I jinxed it. Lockup at atomic copy/restore time > (with video signal off due to Radeon KMS being copy/restored).
This is a regression in 2.6.38.2, not present in .38.1. Bisected to: commit ff518ea26654e05d325d996f6e3a7f5f569cc2d5 Author: Yinghai Lu <[email protected]> Date: Fri Feb 18 11:30:30 2011 +0000 x86: Cleanup highmap after brk is concluded commit e5f15b45ddf3afa2bbbb10c7ea34fb32b6de0a0e upstream. Now cleanup_highmap actually is in two steps: one is early in head64.c and only clears above _end; a second one is in init_memory_mapping() and tries to clean from _brk_end to _end. It should check if those boundaries are PMD_SIZE aligned but currently does not. Also init_memory_mapping() is called several times for numa or memory hotplug, so we really should not handle initial kernel mappings there. This patch moves cleanup_highmap() down after _brk_end is settled so we can do everything in one step. Also we honor max_pfn_mapped in the implementation of cleanup_highmap. Signed-off-by: Yinghai Lu <[email protected]> Signed-off-by: Stefano Stabellini <[email protected]> LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop> Signed-off-by: H. Peter Anvin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Reverting this commit atop 2.6.38.2 allows ToI to resume again. Cc:ing Yinghai and Rafael, since this reportedly affects in-kernel resumption as well (though I haven't tried it, others have). I suspect this commit needs to be reverted from -stable. -- NULL && (void) _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
