Re: [Bug 14658] Regression in efi.c
Thomas Gleixner
Switched to email. Please reply by mail (reply-to-all) and not in the
bugzilla.
> --- Comment #1 from Rafael J. Wysocki <r...@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 majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
indexer
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 <torv...@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.
indexer
> Hi William,
>
> One stupid question, when you did the bisect, did you really try to boot every kernel that you built out?
>
> - Feng
Yes, i did boot every single on. We had this problem where it was the
makefile when i did a similar bisect with Huang Ying, and it is what
prompted me to expand the bisect parameters to v2.6.32. I believe the
email about that is in the mailing list still, and im more than happy
to do any other tests you can think of to test and isolate this bug as
it currently causes a significant issue.
Cheers
William
Thomas Gleixner
> > 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?
>>
> 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 <torv...@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.
indexer
> 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 <torv...@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 ?
>
bisect parameters a bit, but really im quite new to all this. It may
also be a possibility it is gen-patches breaking it as i reported
2.6.30-gentoo was the broken kernel. Either way, the fact remains that
on 2.6.31 and higher vanilla it is broken.
>
>> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
i of course may have made an error in what i reported. I am after all
only human, and i might have made a mistake, and this is the first time
i have ever submitted a bug, let alone found one like this. The end
product is that 2.6.32 doesn't boot, but maybe the last working version
was not 2.6.30-rc8, maybe it was a 2.6.31 kernel. I might redo the
bisect and try this out again, as i'm quite intent on finding the source
of this. I will also see if i can get my hands on another x86_64 linux
install with efi to test it on a different machine to see if it is
hardware specific to my computer. For the record i am running a late
2009 macbook pro gen 5 rev 3, efi version 1.7 with refit and elilo.
William
indexer
I have redone the bisect and i believe the versions i originally stated
were wrong. I apologise for this mistake
commit 7bd867dfb4e0357e06a3211ab2bd0e714110def3
Author: Feng Tang <feng...@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...@intel.com>
LKML-Reference: <new-submission>
Signed-off-by: Thomas Gleixner <tg...@linutronix.de>
arch/x86/include/asm/paravirt.h | 10 ------
arch/x86/include/asm/paravirt_types.h | 4 --
arch/x86/include/asm/time.h | 50
---------------------------------
arch/x86/include/asm/x86_init.h | 4 ++
arch/x86/kernel/efi.c | 4 ++
arch/x86/kernel/kvmclock.c | 4 +-
arch/x86/kernel/paravirt.c | 2 -
arch/x86/kernel/rtc.c | 12 ++-----
arch/x86/kernel/vmi_32.c | 4 +-
arch/x86/kernel/x86_init.c | 2 +
arch/x86/lguest/boot.c | 4 +--
arch/x86/xen/enlighten.c | 4 +-
12 files changed, 21 insertions(+), 83 deletions(-)
Also find my bisect log attached.
William
Huang Ying
On Wed, 2009-11-25 at 08:35 +0800, indexer wrote:
> To whom it may concern
>
> I have redone the bisect and i believe the versions i originally stated
> were wrong. I apologise for this mistake
>
> commit 7bd867dfb4e0357e06a3211ab2bd0e714110def3
> Author: Feng Tang <feng...@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.
Now Legacy RTC code instead of EFI get/set_wallclock is used on x86_64.
Your test shows that before this patch, kernel can boot on your system,
but can not boot after that?
Best Regards,
Huang Ying
indexer
Yes that is correct, i cant boot after this patch was applied, but
former to this patch, my system would boot.
William
indexer
I have just tested and applied that correction, and it resulted in a
working system. I dont really know where to go from here so any advice
would be appreciated.
William
Tang, Feng
You've confirmed that apply commit 772be899b "x86: Make EFI RTC function depend
on 32bit again" right after 7bd867dfb "x86: Move get/set_wallclock to
x86_platform_ops" will get a bootable kernel.
Then, one debug method may be use "git-rebase -i" to move commit 772be899b right after
7bd867dfb, and do the bisect from there on.
Thanks,
Feng
>-----Original Message-----
>From: indexer [mailto:ind...@internode.on.net]
>Sent: 2009��11��25�� 17:43
>To: Tang, Feng
>Cc: LKML
>Subject: Re: [Bug 14658] Regression in efi.c
>
>Feng tang
>
>I have just tested and applied that correction, and it resulted in a
>working system. I dont really know where to go from here so any advice
>would be appreciated.
>
>William
�{.n�+�������+%��lzwm��b�맲��r��zX�� �w��{ay� ʇڙ�,j ��f���h���z� �w��� ���j:+v���w�j�m���� ����zZ+��ݢj"��!�iO��z��v�^ � m���� nƊ��Y&�
indexer
I decided to go back a few versions and check out if there any previous
bugs, and upon bisecting i found this one
commit 37ba7ab5e33cebc25c68fffe33e9f21e7c2014e8
Author: H. Peter Anvin <h...@zytor.com>
Date: Mon May 11 15:56:08 2009 -0700
x86, boot: make kernel_alignment adjustable; new bzImage fields
Make the kernel_alignment field adjustable; this allows us to set it
to a large value (intended to be 16 MB to avoid ZONE_DMA contention,
memory holes and other weirdness) while a smart bootloader can still
force a loading at a lesser alignment if absolutely necessary.
Also export pref_address (preferred loading address, corresponding to
the link-time address) and init_size, the total amount of linear
memory the kernel will require during initialization.
[ Impact: allows better kernel placement, gives bootloader more info ]
Signed-off-by: H. Peter Anvin <h...@zytor.com>
arch/x86/boot/compressed/head_32.S | 7 +++++--
arch/x86/boot/compressed/head_64.S | 14 ++++++++++----
arch/x86/boot/header.S | 15 +++++++++++++--
arch/x86/include/asm/boot.h | 15 +++++++++++++++
arch/x86/kernel/asm-offsets_32.c | 1 +
arch/x86/kernel/asm-offsets_64.c | 1 +
6 files changed, 45 insertions(+), 8 deletions(-)
This seems to stop efi booting as well on x86_64. I have also been able
to recently test this on a gen 4 macbook pro as well as my own gen 5 to
make sure it is not an issue specific to this model.
William
Tang, Feng wrote:
> William,
>
> You've confirmed that apply commit 772be899b "x86: Make EFI RTC function depend
> on 32bit again" right after 7bd867dfb "x86: Move get/set_wallclock to
> x86_platform_ops" will get a bootable kernel.
>
> Then, one debug method may be use "git-rebase -i" to move commit 772be899b right after
> 7bd867dfb, and do the bisect from there on.
>
> Thanks,
> Feng
>
>> -----Original Message-----
>> From: indexer [mailto:ind...@internode.on.net]
>> Sent: 2009年11月25日 17:43
>> To: Tang, Feng
>> Cc: LKML
>> Subject: Re: [Bug 14658] Regression in efi.c
>>
>> Feng tang
>>
>> I have just tested and applied that correction, and it resulted in a
>> working system. I dont really know where to go from here so any advice
>> would be appreciated.
>>
>> William
>>
> N嫥叉靣笡y氊b瞂千v豝�)藓{.n�+壏{睉赙zXФ 洝塄}财爖�&j:+v墾� 珣赙zZ+€�+zf＂穐殘啳嗃i�z� 畐ア�?櫒璀�&�)撷 f旟^j谦y呩@A玜囤 � 0鹅h� 鍜i