All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <dkiper@net-space.pl>
To: Olaf Hering <olaf@aepfle.de>
Cc: Daniel Kiper <dkiper@net-space.pl>,
	kexec@lists.infradead.org, xen-devel@lists.xensource.com,
	linux-kernel@vger.kernel.org
Subject: Re: incorrect layout of globals from head_64.S during kexec boot
Date: Fri, 6 Jul 2012 17:54:57 +0200	[thread overview]
Message-ID: <20120706155457.GA3733@router-fw-old.local.net-space.pl> (raw)
In-Reply-To: <20120706120750.GA8970@aepfle.de>

On Fri, Jul 06, 2012 at 02:07:50PM +0200, Olaf Hering wrote:
> On Fri, Jul 06, Daniel Kiper wrote:
>
> > Copy is done a few times durnig kexec/kdump but the most important
> > in this case, I think, is in relocate_kernel() function (look for
> > rep movsl or rep movsq and code around it). But I am a bit surprised
> > that kernel is decompressing itself. I always thought that it is done
> > during kexec/kdump load phase but maybe I am wrong. Could you send

I am wrong.

> > me more info about your Linux Kernel version, kexec-tools version
> > and exact commands which you are using to load/exececute kernel?
>
> Its kexec-tools and kernel mainline, but it happens also with older
> versions of both. kexec works fine with the forward ported version of
> xenlinux.
>
> kexec -l bzImage --ramdisk=/boot/initrd-3.5.0-rc5-bug694863+ '--command-line=root=/dev/disk/by-label/sles11sp1_full
> sysrq=yes
> panic=9
> oops=panic
> console=ttyS0,115200
> log_buf_len=16M
> ignore_loglevel
> initcall_debug
> debug earlyprintk=serial,ttyS0,115200' -t bzImage --console-serial --serial=ttyS0 --serial-baud=115200 --debug
> kexec -e

Nothing special. But try also ELF loader.

> As Jan pointed out, the copying is done in
> arch/x86/boot/compressed/misc.c. But adding some debug to inspect
> *output in parse_elf() shows that the second entry in program headers is
> already shifted by 44 bytes in my testing, the others are shifted by the
> same amount.
>
> Program Headers:
>   Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
>   LOAD           0x200000 0xffffffff81000000 0x0000000001000000 0xa3b000 0xa3b000 R E 0x200000
>   LOAD           0xe00000 0xffffffff81c00000 0x0000000001c00000 0x05b0e8 0x05b0e8 RW  0x200000
>   LOAD           0x1000000 0x0000000000000000 0x0000000001c5c000 0x012c40 0x012c40 RW  0x200000
>   LOAD           0x106f000 0xffffffff81c6f000 0x0000000001c6f000 0x087000 0x702000 RWE 0x200000
>   NOTE           0x82d5bc 0xffffffff8162d5bc 0x000000000162d5bc 0x00017c 0x00017c     0x4
>
> That makes me wonder wether kexec-tools is the culprit.

Is it relocatable kernel? If not please try use not relocatable one.
Then kernel will be always in the same place.

Daniel

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Kiper <dkiper@net-space.pl>
To: Olaf Hering <olaf@aepfle.de>
Cc: xen-devel@lists.xensource.com, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, Daniel Kiper <dkiper@net-space.pl>
Subject: Re: incorrect layout of globals from head_64.S during kexec boot
Date: Fri, 6 Jul 2012 17:54:57 +0200	[thread overview]
Message-ID: <20120706155457.GA3733@router-fw-old.local.net-space.pl> (raw)
In-Reply-To: <20120706120750.GA8970@aepfle.de>

On Fri, Jul 06, 2012 at 02:07:50PM +0200, Olaf Hering wrote:
> On Fri, Jul 06, Daniel Kiper wrote:
>
> > Copy is done a few times durnig kexec/kdump but the most important
> > in this case, I think, is in relocate_kernel() function (look for
> > rep movsl or rep movsq and code around it). But I am a bit surprised
> > that kernel is decompressing itself. I always thought that it is done
> > during kexec/kdump load phase but maybe I am wrong. Could you send

I am wrong.

> > me more info about your Linux Kernel version, kexec-tools version
> > and exact commands which you are using to load/exececute kernel?
>
> Its kexec-tools and kernel mainline, but it happens also with older
> versions of both. kexec works fine with the forward ported version of
> xenlinux.
>
> kexec -l bzImage --ramdisk=/boot/initrd-3.5.0-rc5-bug694863+ '--command-line=root=/dev/disk/by-label/sles11sp1_full
> sysrq=yes
> panic=9
> oops=panic
> console=ttyS0,115200
> log_buf_len=16M
> ignore_loglevel
> initcall_debug
> debug earlyprintk=serial,ttyS0,115200' -t bzImage --console-serial --serial=ttyS0 --serial-baud=115200 --debug
> kexec -e

Nothing special. But try also ELF loader.

> As Jan pointed out, the copying is done in
> arch/x86/boot/compressed/misc.c. But adding some debug to inspect
> *output in parse_elf() shows that the second entry in program headers is
> already shifted by 44 bytes in my testing, the others are shifted by the
> same amount.
>
> Program Headers:
>   Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
>   LOAD           0x200000 0xffffffff81000000 0x0000000001000000 0xa3b000 0xa3b000 R E 0x200000
>   LOAD           0xe00000 0xffffffff81c00000 0x0000000001c00000 0x05b0e8 0x05b0e8 RW  0x200000
>   LOAD           0x1000000 0x0000000000000000 0x0000000001c5c000 0x012c40 0x012c40 RW  0x200000
>   LOAD           0x106f000 0xffffffff81c6f000 0x0000000001c6f000 0x087000 0x702000 RWE 0x200000
>   NOTE           0x82d5bc 0xffffffff8162d5bc 0x000000000162d5bc 0x00017c 0x00017c     0x4
>
> That makes me wonder wether kexec-tools is the culprit.

Is it relocatable kernel? If not please try use not relocatable one.
Then kernel will be always in the same place.

Daniel

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  parent reply	other threads:[~2012-07-06 15:55 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-05 21:06 incorrect layout of globals from head_64.S during kexec boot Olaf Hering
2012-07-05 21:06 ` Olaf Hering
2012-07-06  8:29 ` [Xen-devel] " Jan Beulich
2012-07-06  8:29   ` Jan Beulich
2012-07-06  8:29   ` Jan Beulich
2012-07-06  8:41 ` Daniel Kiper
2012-07-06  8:41   ` Daniel Kiper
2012-07-06  8:41   ` Daniel Kiper
2012-07-06 12:07   ` Olaf Hering
2012-07-06 12:07     ` Olaf Hering
2012-07-06 12:56     ` [Xen-devel] " Jan Beulich
2012-07-06 12:56       ` Jan Beulich
2012-07-06 12:56       ` Jan Beulich
2012-07-06 13:31       ` Olaf Hering
2012-07-06 13:31         ` Olaf Hering
2012-07-06 13:31         ` Olaf Hering
2012-07-06 13:53         ` Jan Beulich
2012-07-06 13:53           ` Jan Beulich
2012-07-06 13:53           ` Jan Beulich
2012-07-06 14:14         ` Olaf Hering
2012-07-06 14:14           ` Olaf Hering
2012-07-06 14:50           ` Jan Beulich
2012-07-06 14:50             ` Jan Beulich
2012-07-06 14:50             ` Jan Beulich
2012-07-06 17:29             ` Olaf Hering
2012-07-06 17:29               ` Olaf Hering
2012-07-10  9:33               ` Olaf Hering
2012-07-10  9:33                 ` Olaf Hering
2012-07-10 14:14                 ` Konrad Rzeszutek Wilk
2012-07-10 14:14                   ` Konrad Rzeszutek Wilk
2012-07-10 14:46                   ` Ian Campbell
2012-07-10 14:46                     ` Ian Campbell
2012-07-10 14:51                     ` Konrad Rzeszutek Wilk
2012-07-10 14:51                       ` Konrad Rzeszutek Wilk
2012-07-10 14:51                       ` Konrad Rzeszutek Wilk
2012-07-10 15:29                       ` Ian Campbell
2012-07-10 15:29                         ` Ian Campbell
2012-07-10 15:29                         ` Ian Campbell
2012-07-10 15:37                         ` Olaf Hering
2012-07-10 15:37                           ` Olaf Hering
2012-07-10 15:23                   ` Olaf Hering
2012-07-10 15:23                     ` Olaf Hering
2012-07-10 17:26                     ` Konrad Rzeszutek Wilk
2012-07-10 17:26                       ` Konrad Rzeszutek Wilk
2012-07-10 17:26                       ` Konrad Rzeszutek Wilk
2012-07-10 18:09                       ` Olaf Hering
2012-07-10 18:09                         ` Olaf Hering
2012-07-10 18:32                         ` Konrad Rzeszutek Wilk
2012-07-10 18:32                           ` Konrad Rzeszutek Wilk
2012-07-10 19:08                         ` Keir Fraser
2012-07-10 19:08                           ` Keir Fraser
2012-07-10 19:08                           ` Keir Fraser
2012-07-13 20:20                           ` Olaf Hering
2012-07-13 20:20                             ` Olaf Hering
2012-07-14  4:54                             ` Keir Fraser
2012-07-14  4:54                               ` Keir Fraser
2012-07-14  4:54                               ` Keir Fraser
2012-07-15 16:06                           ` Olaf Hering
2012-07-15 16:06                             ` Olaf Hering
2012-07-15 17:17                             ` Keir Fraser
2012-07-15 17:17                               ` Keir Fraser
2012-07-15 17:17                               ` Keir Fraser
2012-07-16 15:46                             ` Konrad Rzeszutek Wilk
2012-07-16 15:46                               ` Konrad Rzeszutek Wilk
2012-07-17 10:24                               ` Olaf Hering
2012-07-17 10:24                                 ` Olaf Hering
2012-07-17 12:34                                 ` Olaf Hering
2012-07-17 12:34                                   ` Olaf Hering
2012-07-06 15:54     ` Daniel Kiper [this message]
2012-07-06 15:54       ` Daniel Kiper

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=20120706155457.GA3733@router-fw-old.local.net-space.pl \
    --to=dkiper@net-space.pl \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olaf@aepfle.de \
    --cc=xen-devel@lists.xensource.com \
    /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.