Bug 14658

Summary: Regression in efi.c
Product: Platform Specific/Hardware Reporter: Rafael J. Wysocki (rjw)
Component: x86-64Assignee: platform_x86_64 (platform_x86_64)
Status: CLOSED CODE_FIX    
Severity: normal CC: feng.tang, florian
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.31 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 13615    

Description Rafael J. Wysocki 2009-11-21 14:50:07 UTC
Subject    : Regression in efi.c 2.6.32-rc7
Submitter  : indexer <indexer@internode.on.net>
Date       : 2009-11-17 14:54
References : http://marc.info/?l=linux-kernel&m=125846988820120&w=4

This entry is being used for tracking a regression from 2.6.31.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Rafael J. Wysocki 2009-11-21 20:17:21 UTC
Caused by:

commit 7bd867dfb4e0357e06a3211ab2bd0e714110def3
Author: Feng Tang <feng.tang@intel.com>
Date:   Thu Sep 10 10:48:56 2009 +0800

    x86: Move get/set_wallclock to x86_platform_ops
   
    get/set_wallclock() have already a set of platform dependent
    implementations (default, EFI, paravirt). MRST will add another
    variant.
   
    Moving them to platform ops simplifies the existing code and minimizes
    the effort to integrate new variants.
   
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

First-Bad-Commit : 7bd867dfb4e0357e06a3211ab2bd0e714110def3
Comment 2 Thomas Gleixner 2009-11-22 17:50:03 UTC
On Sat, 21 Nov 2009, bugzilla-daemon@bugzilla.kernel.org wrote:

Switched to email. Please reply by mail (reply-to-all) and not in the
bugzilla.

> --- Comment #1 from Rafael J. Wysocki <rjw@sisk.pl>  2009-11-21 20:17:21 ---
> Caused by:
> 
> commit 7bd867dfb4e0357e06a3211ab2bd0e714110def3

That's completely bogus. That commit is not in 2.6.31. It was merged in the
2.6.32 merge window.

From the original bug report:

http://marc.info/?l=linux-kernel&m=125846988820120&w=4

> I would like to report a possible regression in efi.c with kernels
> 2.6.31 , 2.6.32-rc5 and 2.6.32.rc7.
>
> Attempting to boot x86_64 with elilo succeeds using 2.6.30 . Using the
> same config cannot boot with any of the 3 afore mentioned kernels.

So the problem exists with 2.6.31 already which excludes the above
commit.

The above commit indeed caused problems on 64bit efi systems in
2.6.32-rc. The fix was merged between 32-rc5 and 32-rc6.

The bisect was done with:

git bisect start
# good: [59a3759d0fe8d969888c741bb33f4946e4d3750d] Linux 2.6.30-rc7
git bisect good 59a3759d0fe8d969888c741bb33f4946e4d3750d
# bad: [156171c71a0dc4bce12b4408bb1591f8fe32dc1a] Linux 2.6.32-rc7

while the bisect should have be done with

good 2.6.30
bad  2.6.31

William, could you please go through the bisect pain again?

Thanks,

	tglx
Comment 3 Anonymous Emailer 2009-11-23 02:42:25 UTC
Reply-To: indexer@internode.on.net

Thomas Gleixner wrote:
> On Sat, 21 Nov 2009, bugzilla-daemon@bugzilla.kernel.org wrote:
>
> Switched to email. Please reply by mail (reply-to-all) and not in the
> bugzilla.
>
>   
>> --- Comment #1 from Rafael J. Wysocki <rjw@sisk.pl>  2009-11-21 20:17:21 ---
>> Caused by:
>>
>> commit 7bd867dfb4e0357e06a3211ab2bd0e714110def3
>>     
>
> That's completely bogus. That commit is not in 2.6.31. It was merged in the
> 2.6.32 merge window.
>
> From the original bug report:
>
> http://marc.info/?l=linux-kernel&m=125846988820120&w=4
>
>   
>> I would like to report a possible regression in efi.c with kernels
>> 2.6.31 , 2.6.32-rc5 and 2.6.32.rc7.
>>
>> Attempting to boot x86_64 with elilo succeeds using 2.6.30 . Using the
>> same config cannot boot with any of the 3 afore mentioned kernels.
>>     
>
> So the problem exists with 2.6.31 already which excludes the above
> commit.
>
> The above commit indeed caused problems on 64bit efi systems in
> 2.6.32-rc. The fix was merged between 32-rc5 and 32-rc6.
>
> The bisect was done with:
>
> git bisect start
> # good: [59a3759d0fe8d969888c741bb33f4946e4d3750d] Linux 2.6.30-rc7
> git bisect good 59a3759d0fe8d969888c741bb33f4946e4d3750d
> # bad: [156171c71a0dc4bce12b4408bb1591f8fe32dc1a] Linux 2.6.32-rc7
>
> while the bisect should have be done with
>
> good 2.6.30
> bad  2.6.31
>
> William, could you please go through the bisect pain again?
>
> Thanks,
>
>       tglx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>   
Thomas

I had already done a similar bisect to this in private conversation to 
Huang Ying, and is what prompted me to expand my bisect out. I redid it 
regardless and will send you the information.

commit 74fca6a42863ffacaf7ba6f1936a9f228950f657
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Wed Sep 9 15:13:59 2009 -0700

    Linux 2.6.31

 Makefile |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


git bisect start
# good: [07a2039b8eb0af4ff464efd3dfd95de5c02648c6] Linux 2.6.30
git bisect good 07a2039b8eb0af4ff464efd3dfd95de5c02648c6
# bad: [74fca6a42863ffacaf7ba6f1936a9f228950f657] Linux 2.6.31
git bisect bad 74fca6a42863ffacaf7ba6f1936a9f228950f657
# good: [925d74ae717c9a12d3618eb4b36b9fb632e2cef3] V4L/DVB (11736): 
videobuf: modify return value of VIDIOC_REQBUFS ioctl
git bisect good 925d74ae717c9a12d3618eb4b36b9fb632e2cef3
# good: [a380137900fca5c79e6daa9500bdb6ea5649188e] ixgbe: Fix device 
capabilities of 82599 single speed fiber NICs.
git bisect good a380137900fca5c79e6daa9500bdb6ea5649188e
# good: [b54c3835469c9548d470e7788cb22a2fd7e21133] Merge branch 
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
git bisect good b54c3835469c9548d470e7788cb22a2fd7e21133
# good: [7b2aa037e878c939676675969983284a02958ae3] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6
git bisect good 7b2aa037e878c939676675969983284a02958ae3
# good: [8486a0f95c844b27ecc855cfec89b7e34f831cad] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect good 8486a0f95c844b27ecc855cfec89b7e34f831cad
# good: [f415c413f458837bd0c27086b79aca889f9435e4] Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
git bisect good f415c413f458837bd0c27086b79aca889f9435e4
# good: [37d0892c5a94e208cf863e3b7bac014edee4346d] autofs4 - fix missed 
case when changing to use struct path
git bisect good 37d0892c5a94e208cf863e3b7bac014edee4346d
# good: [0edfa2b1b5a5e1475e76dd3c792447687d966de4] Merge branch 
'for-linus' of git://oss.sgi.com/xfs/xfs
git bisect good 0edfa2b1b5a5e1475e76dd3c792447687d966de4
# good: [5136a6c0fd5b26bbf39ad761cf7a4fc563ad83a3] Merge 
git://git.infradead.org/~dwmw2/mtd-2.6.31
git bisect good 5136a6c0fd5b26bbf39ad761cf7a4fc563ad83a3
# good: [f69fb9c39868463f6b0b8306824341bd5610250b] Merge branch 
'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
git bisect good f69fb9c39868463f6b0b8306824341bd5610250b
# good: [755ae761c5519929a97567d61a379b87352c337c] Merge branch 
'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
git bisect good 755ae761c5519929a97567d61a379b87352c337c
# good: [7c8460db30dfd085ef3837c8fb02ecf2e718b983] drm/i915: fix mask 
bits setting
git bisect good 7c8460db30dfd085ef3837c8fb02ecf2e718b983
# good: [7135a71b19be1faf48b7148d77844d03bc0717d6] aoe: allocate unused 
request_queue for sysfs
git bisect good 7135a71b19be1faf48b7148d77844d03bc0717d6
 Sincerely

William

PS - The fact remains i still cant efi boot in 2.6.32-rc7, so this bug 
still exists, and I will keep doing what i can to help track this down.
Comment 4 Thomas Gleixner 2009-11-23 09:45:54 UTC
On Mon, 23 Nov 2009, indexer wrote:
> > while the bisect should have be done with
> > 
> > good 2.6.30
> > bad  2.6.31
> > 
> > William, could you please go through the bisect pain again?
>> 
> I had already done a similar bisect to this in private conversation to Huang
> Ying, and is what prompted me to expand my bisect out. I redid it regardless
> and will send you the information.
> 
> commit 74fca6a42863ffacaf7ba6f1936a9f228950f657
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Wed Sep 9 15:13:59 2009 -0700
> 
>    Linux 2.6.31
> 
> Makefile |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)

So you are saying that 
 
> # good: [7135a71b19be1faf48b7148d77844d03bc0717d6] aoe: allocate unused
> request_queue for sysfs
> git bisect good 7135a71b19be1faf48b7148d77844d03bc0717d6

which is the last code changing commit before the 2.6.31 release is
booting fine, but with the release commit which merily changes the
Makefile it is not ?

> PS - The fact remains i still cant efi boot in 2.6.32-rc7, so this bug still
> exists, and I will keep doing what i can to help track this down.

Sure, but I hope we agree that it does not make much sense to search
2.6.31..now when we already know that 2.6.31 is not booting and the
change which causes the problem is between 2.6.30 and 2.6.31.

Thanks,

	tglx
Comment 5 Feng Tang 2009-11-25 02:48:08 UTC
William,

You reported that when you did the bisect between 2.6.31-rc1 and 2.6.32-rc1, my commit broke:
commit 7bd867dfb4e0357e06a3211ab2bd0e714110def3
Author: Feng Tang <feng.tang@intel.com>
Date:   Thu Sep 10 10:48:56 2009 +0800

    x86: Move get/set_wallclock to x86_platform_ops

    get/set_wallclock() have already a set of platform dependent
    implementations (default, EFI, paravirt). MRST will add another
    variant.

    Moving them to platform ops simplifies the existing code and minimizes
    the effort to integrate new variants.

    Signed-off-by: Feng Tang <feng.tang@intel.com>
    LKML-Reference: <new-submission>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>


Yes, that commit did bring a regression for efi-enabled x86_64 kernel, and was fixed by this new commit:

commit 772be899bc022ef2b911c3611b487d417e3269c3
Author: Feng Tang <feng.tang@intel.com>
Date:   Tue Oct 20 12:54:02 2009 +0800

    x86: Make EFI RTC function depend on 32bit again

    The EFI RTC functions are only available on 32 bit. commit 7bd867df
    (x86: Move get/set_wallclock to x86_platform_ops) removed the 32bit
    dependency which leads to boot crashes on 64bit EFI systems.

    Add the dependency back.
    Solves: http://bugzilla.kernel.org/show_bug.cgi?id=14466

    Tested-by: Matthew Garrett <mjg59@srcf.ucam.org>
    Signed-off-by: Feng Tang <feng.tang@intel.com>
    LKML-Reference: <20091020125402.028d66d5@feng-desktop>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

diff --git a/arch/x86/kernel/efi.c b/arch/x86/kernel/efi.c
index ad5bd98..cdcfb12 100644
--- a/arch/x86/kernel/efi.c
+++ b/arch/x86/kernel/efi.c
@@ -454,8 +454,10 @@ void __init efi_init(void)
        if (add_efi_memmap)
                do_add_efi_memmap();

+#ifdef CONFIG_X86_32
        x86_platform.get_wallclock = efi_get_time;
        x86_platform.set_wallclock = efi_set_rtc_mmss;
+#endif

        /* Setup for EFI runtime service */
        reboot_type = BOOT_EFI;

So could you please apply this new fix 772be899b right after 7bd867dfb, and test the kernel? From this, we can identify if my RTC commmits really break your kernel.

Thanks,
Feng
Comment 6 Florian Mickler 2010-12-18 00:47:01 UTC
fixed in 2.6.32-rc6 by

commit 772be899bc022ef2b911c3611b487d417e3269c3
Author: Feng Tang <feng.tang@intel.com>
Date:   Tue Oct 20 12:54:02 2009 +0800

    x86: Make EFI RTC function depend on 32bit again