All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bruno Prémont" <bonbons-ud5FBsm0p/xEiooADzr8i9i2O/JbrIOy@public.gmane.org>
To: Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
Cc: P J P <ppandit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: 3.12 to 3.13 boot regression bisected - still applies to 3.16
Date: Tue, 5 Aug 2014 11:13:30 +0200	[thread overview]
Message-ID: <20140805111330.3cf9319f@pluto> (raw)
In-Reply-To: <20140805084542.GM15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

On Tue, 5 Aug 2014 09:45:42 +0100 Matt Fleming wrote:
> On Tue, 05 Aug, at 10:02:42AM, Bruno Prémont wrote:
> > 
> > I tried in setup_arch(), but system still keeps rebooting.
> > 
> > Working backwards I got to x86_64_start_kernel() in
> > arch/x86/kernel/head64.c but system is still rebooting.
>  
> Thanks for doing this. I'm sure it was a major PITA ;-)

Fortunately building the kernels on a separate system and being
able to build a dozen of them to try from efi shell it's survivable.

> > Not sure what happens before x86_64_start_kernel() is called, it seems
> > to be called from ASM code in arch/x86/kernel/head_64.S.
>  
> Yep. Roughly the code flow goes like this (chronologically),
> 
>   efi_pe_entry()	[arch/x86/boot/compressed/head_64.S]
>     efi_main()		[arch/x86/boot/compressed/eboot.c]

I get at least to just before
  status = efi_call_early(exit_boot_services, handle, key);
in eboot.c on line 1310. A efi_printk inserted there is displayed.

>   startup_64		[arch/x86/kernel/head_64.S]
>   secondary_startup64	[arch/x86/kernel/head_64.S]
>   x86_64_start_kernel()	[arch/x86/kernel/head64.c]
> 
> > > Meanwhile I'm going to go and stare at the EFI boot stub code and
> > > instrument OVMF to check for more memory corruption bugs like the one
> > > Michael found in commit c7fb93ec51d4 ("x86/efi: Include a .bss section
> > > within the PE/COFF headers").
> > 
> > If there are places between exit_boot() in
> > arch/x86/boot/compressed/eboot.c and x86_64_start_kernel() where I
> > should include such loops, please tell!
> 
> I guess we need to verify efi_main() actually exits correctly. So a
> while (1); loop at the end of that function would be useful.
> 
> Assuming that does actually hang, you get the fun of rummaging around in
> the early assembly code, where you can use something like this,
> 
> bruno:
> 	hlt
> 	jmp bruno
> 
> to try and force a hang.

Will spin a few attempts and see what I get.

> Could you also attach your .config? In particular I'm wondering whether
> you've got CONFIG_RELOCATBLE enabled.

Config attached (gzipped). CONFIG_RELOCATBLE is not enabled.

Bruno

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 18362 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: Matt Fleming <matt@console-pimps.org>
Cc: P J P <ppandit@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org
Subject: Re: 3.12 to 3.13 boot regression bisected - still applies to 3.16
Date: Tue, 5 Aug 2014 11:13:30 +0200	[thread overview]
Message-ID: <20140805111330.3cf9319f@pluto> (raw)
In-Reply-To: <20140805084542.GM15082@console-pimps.org>

[-- Attachment #1: Type: text/plain, Size: 2179 bytes --]

On Tue, 5 Aug 2014 09:45:42 +0100 Matt Fleming wrote:
> On Tue, 05 Aug, at 10:02:42AM, Bruno Prémont wrote:
> > 
> > I tried in setup_arch(), but system still keeps rebooting.
> > 
> > Working backwards I got to x86_64_start_kernel() in
> > arch/x86/kernel/head64.c but system is still rebooting.
>  
> Thanks for doing this. I'm sure it was a major PITA ;-)

Fortunately building the kernels on a separate system and being
able to build a dozen of them to try from efi shell it's survivable.

> > Not sure what happens before x86_64_start_kernel() is called, it seems
> > to be called from ASM code in arch/x86/kernel/head_64.S.
>  
> Yep. Roughly the code flow goes like this (chronologically),
> 
>   efi_pe_entry()	[arch/x86/boot/compressed/head_64.S]
>     efi_main()		[arch/x86/boot/compressed/eboot.c]

I get at least to just before
  status = efi_call_early(exit_boot_services, handle, key);
in eboot.c on line 1310. A efi_printk inserted there is displayed.

>   startup_64		[arch/x86/kernel/head_64.S]
>   secondary_startup64	[arch/x86/kernel/head_64.S]
>   x86_64_start_kernel()	[arch/x86/kernel/head64.c]
> 
> > > Meanwhile I'm going to go and stare at the EFI boot stub code and
> > > instrument OVMF to check for more memory corruption bugs like the one
> > > Michael found in commit c7fb93ec51d4 ("x86/efi: Include a .bss section
> > > within the PE/COFF headers").
> > 
> > If there are places between exit_boot() in
> > arch/x86/boot/compressed/eboot.c and x86_64_start_kernel() where I
> > should include such loops, please tell!
> 
> I guess we need to verify efi_main() actually exits correctly. So a
> while (1); loop at the end of that function would be useful.
> 
> Assuming that does actually hang, you get the fun of rummaging around in
> the early assembly code, where you can use something like this,
> 
> bruno:
> 	hlt
> 	jmp bruno
> 
> to try and force a hang.

Will spin a few attempts and see what I get.

> Could you also attach your .config? In particular I'm wondering whether
> you've got CONFIG_RELOCATBLE enabled.

Config attached (gzipped). CONFIG_RELOCATBLE is not enabled.

Bruno

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 18362 bytes --]

  parent reply	other threads:[~2014-08-05  9:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-04  9:34 3.12 to 3.13 boot regression bisected - still applies to 3.16 Bruno Prémont
2014-08-04  9:34 ` Bruno Prémont
2014-08-04 12:27 ` Matt Fleming
2014-08-04 12:27   ` Matt Fleming
     [not found]   ` <20140804122728.GH15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-08-04 13:06     ` Bruno Prémont
2014-08-04 13:06       ` Bruno Prémont
2014-08-04 13:54       ` Matt Fleming
2014-08-05  8:02         ` Bruno Prémont
2014-08-05  8:45           ` Matt Fleming
     [not found]             ` <20140805084542.GM15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-08-05  9:13               ` Bruno Prémont [this message]
2014-08-05  9:13                 ` Bruno Prémont
2014-08-05  9:18                 ` Matt Fleming
     [not found]                   ` <20140805091848.GN15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-08-05 11:51                     ` Bruno Prémont
2014-08-05 11:51                       ` Bruno Prémont
2014-08-05 12:11                       ` Bruno Prémont
2014-08-05 12:11                         ` Bruno Prémont
2014-08-05 12:55                         ` Matt Fleming
2014-08-05 12:55                           ` Matt Fleming
     [not found]                           ` <20140805125548.GP15082-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-08-05 14:21                             ` Bruno Prémont
2014-08-05 14:21                               ` Bruno Prémont
2014-08-05 15:07                               ` Matt Fleming

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140805111330.3cf9319f@pluto \
    --to=bonbons-ud5fbsm0p/xeiooadzr8i9i2o/jbrioy@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org \
    --cc=ppandit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.