Le 02/04/11 19:31, Nix a écrit : > 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. > I can confirm this. Without reverting this commit, resume always hangs at "doing atomic restore".
François Valenduc _______________________________________________ stable mailing list [email protected] http://linux.kernel.org/mailman/listinfo/stable
