On Sat, Apr 02, 2011 at 06:31:31PM +0100, Nix wrote: > 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.
Known issue, it will be reverted next week. thanks, greg k-h _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
