[Bisected] 3.7-rc1 can't resume

Commit Message

Jonas Heinrich Feb. 23, 2013, 1:18 p.m. UTC

Hi,
thank you for your replay and the effort you invest in helping me out
with this problem.
Today, I further debuged the problem and reverted this part of your commit
(without understanding the actual code):


I applied this change to the current 3.8 kernel and it worked!
If you need more test results, just send me patches and I'll try them :)

Best regards,
Jonas

On 02-18 08:21, H. Peter Anvin wrote:
> I might be able to get my hands on a T43 later this week and see if I can reproduce this.  This patch seems more plausible, at least... but still puzzling.
> 
> Jonas Heinrich <[e-mail]> wrote:
> 
> >On 02-17 21:40, Rafael J. Wysocki wrote:
> >> Does the commit immediately preceding this one behave correctly?
> >Strangely the preceding commit works well, so I bisected the kernel
> >again, this time more carefully and I've got a different result!
> >(see bisect_log attachement).
> >It seems to be commit 73201dbec64aebf6b0dca855b523f437972dc7bb 
> >(https://patchwork.kernel.org/patch/1511921/).
> >Someone on LKML already reported an issue with this commit
> >(https://lkml.org/lkml/2012/10/18/228) , but Peter
> >Anvins patch got already applied in newer versions.
> >Reverting this patch with the recent git clone seems to be difficult
> >because it already has too much dependencies.
> >
> >Additionally I've included dmesg dumps of the last good and the bad
> >kernel version.
> >
> >On 02-17 12:52, H. Peter Anvin wrote:
> >> T43 is quite old... which might have exposed unique bugs.  How
> >reliable is the failure?  Even one misidentified commit results in git
> >bisect giving garbage.
> >It affects really all versions after that commit and the failure
> >happens
> >every time I try to resume my notebook.
> >
> >Best regards,
> >Jonas
> 
> -- 
> Sent from my mobile phone. Please excuse brevity and lack of formatting.

Comments

H. Peter Anvin Feb. 23, 2013, 9:54 p.m. UTC | #1

On 02/23/2013 05:18 AM, Jonas Heinrich wrote:
> Hi,
> thank you for your replay and the effort you invest in helping me out
> with this problem.
> Today, I further debuged the problem and reverted this part of your commit
> (without understanding the actual code):
>

Hi, that commit is indeed buggy, but it has already been fixed; commit
1396adc3c2bdc556d4cdd1cf107aa0b6d59fbb1e contains the fix.

So to bisect anything between 73201dbec64aebf6b0dca855b523f437972dc7bb 
and 1396adc3c2bdc556d4cdd1cf107aa0b6d59fbb1e in a meaningful way you 
will have to apply 1396adc3c2bdc556d4cdd1cf107aa0b6d59fbb1e on top.

If 73201dbec64aebf6b0dca855b523f437972dc7b with 
1396adc3c2bdc556d4cdd1cf107aa0b6d59fbb1e on top fails whereas the 
previous one does, then that is very interesting and something we can 
work with.

	-hpa

Patch

diff --git a/arch/x86/realmode/rm/wakeup_asm.S b/arch/x86/realmode/rm/wakeup_asm.S
index 8905166..e56479e 100644
--- a/arch/x86/realmode/rm/wakeup_asm.S
+++ b/arch/x86/realmode/rm/wakeup_asm.S
@@ -110,15 +119,15 @@   ENTRY(wakeup_start)
 	movl	pmode_cr3, %eax
 	movl	%eax, %cr3
 
-	movl	pmode_cr4, %ecx
-	jecxz	1f
-	movl	%ecx, %cr4
+	btl	$WAKEUP_BEHAVIOR_RESTORE_CR4, %edi
+	jz	1f
+	movl	pmode_cr4, %eax
+	movl	%eax, %cr4
 1:
+	btl	$WAKEUP_BEHAVIOR_RESTORE_EFER, %edi
+	jz	1f
 	movl	pmode_efer, %eax
 	movl	pmode_efer + 4, %edx
-	movl	%eax, %ecx
-	orl	%edx, %ecx
-	jz	1f
 	movl	$MSR_EFER, %ecx
 	wrmsr
 1: