All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt@console-pimps.org>
To: Dave Young <dyoung@redhat.com>
Cc: mjg59@srcf.ucam.org, msalter@redhat.com,
	linux-efi@vger.kernel.org, toshi.kani@hp.com, greg@kroah.com,
	x86@kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, leif.lindholm@linaro.org,
	James.Bottomley@HansenPartnership.com, horms@verge.net.au,
	bp@alien8.de, ebiederm@xmission.com, hpa@zytor.com,
	akpm@linux-foundation.org, mingo@kernel.org, vgoyal@redhat.com
Subject: Re: [PATCH v6 14/14] x86: kdebugfs do not use __va for getting setup_data virt addr
Date: Tue, 17 Dec 2013 11:24:52 +0000	[thread overview]
Message-ID: <20131217112452.GA3145@console-pimps.org> (raw)
In-Reply-To: <20131217065346.GG6751@dhcp-16-126.nay.redhat.com>

On Tue, 17 Dec, at 02:53:46PM, Dave Young wrote:
> On 12/17/13 at 02:24pm, Dave Young wrote:
> > On 12/16/13 at 04:35pm, Matt Fleming wrote:
> > > On Mon, 16 Dec, at 05:30:35PM, Dave Young wrote:
> > > > kdump kernel will use memmap=exactmap kernel cmdline, but __va does not
> > > > work in case memmap=exactmap, so let's always use ioremap_cache.
> > > > 
> > > > Signed-off-by: Dave Young <dyoung@redhat.com>
> > > > ---
> > > >  arch/x86/kernel/kdebugfs.c | 35 +++++++++++------------------------
> > > >  1 file changed, 11 insertions(+), 24 deletions(-)
> > > 
> > > Dave, I've no idea why this change is necessary from the commit log. Is
> > > it required for kexec to function on EFI? Why does __va() not work in
> > > the memmap=exactmap case?
> > > 
> > 
> > During previous kdump tests I saw panics while reading the setup_data in debugfs.
> > I thought it is caused by some unmapped addresses. At that time I also reproduced
> > it by booting the non-kexec kernel with memmap=exact.
> > 
> > Since you are asking about this I'm testing it again but I seems can not
> > reproduce this problem any more, it's weird.
> > 
> > I should dug more about it and save the panic messages.
> > 
> > So let's drop this patch for now, I will keep an eye on this and address it later
> > if I can find the problem again.
> 
> Reproduced it again in normal boot with memmap=exactmap, but I agree it's a corner
> case, I remember I saw this in kdump kernel, but I still did not see it in today's
> testing so I think move this issue out of this patch series is fine to me.
 
Please include the following oops when you submit this patch again.

> [    0.359467] BUG: unable to handle kernel paging request at ffff8800d5592020
> [    0.359472] IP: [<ffffffff817dbdbc>] arch_kdebugfs_init+0x11a/0x201
> [    0.359474] PGD 316b067 PUD 37031063 PMD 0 
> [    0.359476] Oops: 0000 [#1] PREEMPT SMP 
> [    0.359477] Modules linked in:
> [    0.359480] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc3+ #65
> [    0.359481] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013
> [    0.359482] task: ffff880037022000 ti: ffff880037188000 task.ti: ffff880037188000
> [    0.359484] RIP: 0010:[<ffffffff817dbdbc>]  [<ffffffff817dbdbc>] arch_kdebugfs_init+0x11a/0x201
> [    0.359485] RSP: 0000:ffff880037189e30  EFLAGS: 00010286
> [    0.359486] RAX: ffff8800372e30e0 RBX: ffff8800372e30e0 RCX: 0000000000000191
> [    0.359486] RDX: 0000000000000000 RSI: ffffffff8168a39e RDI: ffff880037189e50
> [    0.359487] RBP: ffff880037189e90 R08: ffff8800372e30e0 R09: 0000000000000000
> [    0.359488] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003640aea0
> [    0.359489] R13: 00000000d5592018 R14: ffff88003640b200 R15: ffff8800d5592018
> [    0.359490] FS:  0000000000000000(0000) GS:ffff880037480000(0000) knlGS:0000000000000000
> [    0.359491] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.359491] CR2: ffff8800d5592020 CR3: 0000000002716000 CR4: 00000000000407e0
> [    0.359492] Stack:
> [    0.359494]  ffffffff817da6d5 ffff88003640b0e0 ffff88003640afc0 0000000000000004
> [    0.359496]  ffff880037180033 ffffffff8149d82d 00000000c9b42d58 ffffffff817dbca2
> [    0.359498]  0000000000000000 00000000000000f3 0000000000000000 0000000000000000
> [    0.359499] Call Trace:
> [    0.359502]  [<ffffffff817da6d5>] ? boot_params_ksysfs_init+0x1ff/0x244
> [    0.359507]  [<ffffffff8149d82d>] ? mutex_unlock+0x9/0xb
> [    0.359508]  [<ffffffff817dbca2>] ? topology_init+0x36/0x36
> [    0.359512]  [<ffffffff810002bf>] do_one_initcall+0xae/0x15b
> [    0.359515]  [<ffffffff81078500>] ? parameq+0xb/0x1f
> [    0.359516]  [<ffffffff81078770>] ? parse_args+0x25c/0x33a
> [    0.359519]  [<ffffffff817d5ec6>] kernel_init_freeable+0x115/0x19b
> [    0.359521]  [<ffffffff817d573d>] ? do_early_param+0x88/0x88
> [    0.359523]  [<ffffffff81489359>] ? rest_init+0xbd/0xbd
> [    0.359524]  [<ffffffff81489362>] kernel_init+0x9/0xfa
> [    0.359527]  [<ffffffff8149fd0c>] ret_from_fork+0x7c/0xb0
> [    0.359528]  [<ffffffff81489359>] ? rest_init+0xbd/0xbd
> [    0.359548] Code: ff 48 85 c0 48 89 c3 0f 84 b9 00 00 00 49 bf 00 00 00 00 00 88 ff ff 4c 89 28 8b 55 bc 48 8d 7d c0 4d 01 ef 48 c 
> [    0.359549] RIP  [<ffffffff817dbdbc>] arch_kdebugfs_init+0x11a/0x201
> [    0.359550]  RSP <ffff880037189e30>
> [    0.359550] CR2: ffff8800d5592020
> [    0.359559] ---[ end trace d52b3fbe64a26115 ]---
> [    0.621287] kworker/u8:0 (43) used greatest stack depth: 5232 bytes left
> [    0.628021] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [    0.628021] 

-- 
Matt Fleming, Intel Open Source Technology Center

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

WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
To: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org,
	hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org,
	James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org,
	vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
	horms-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org,
	kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org,
	greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org,
	toshi.kani-VXdhtT5mjnY@public.gmane.org,
	akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
	mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	msalter-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	leif.lindholm-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Subject: Re: [PATCH v6 14/14] x86: kdebugfs do not use __va for getting setup_data virt addr
Date: Tue, 17 Dec 2013 11:24:52 +0000	[thread overview]
Message-ID: <20131217112452.GA3145@console-pimps.org> (raw)
In-Reply-To: <20131217065346.GG6751-je1gSBvt1TcFLmT5oZ11vB/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>

On Tue, 17 Dec, at 02:53:46PM, Dave Young wrote:
> On 12/17/13 at 02:24pm, Dave Young wrote:
> > On 12/16/13 at 04:35pm, Matt Fleming wrote:
> > > On Mon, 16 Dec, at 05:30:35PM, Dave Young wrote:
> > > > kdump kernel will use memmap=exactmap kernel cmdline, but __va does not
> > > > work in case memmap=exactmap, so let's always use ioremap_cache.
> > > > 
> > > > Signed-off-by: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > > > ---
> > > >  arch/x86/kernel/kdebugfs.c | 35 +++++++++++------------------------
> > > >  1 file changed, 11 insertions(+), 24 deletions(-)
> > > 
> > > Dave, I've no idea why this change is necessary from the commit log. Is
> > > it required for kexec to function on EFI? Why does __va() not work in
> > > the memmap=exactmap case?
> > > 
> > 
> > During previous kdump tests I saw panics while reading the setup_data in debugfs.
> > I thought it is caused by some unmapped addresses. At that time I also reproduced
> > it by booting the non-kexec kernel with memmap=exact.
> > 
> > Since you are asking about this I'm testing it again but I seems can not
> > reproduce this problem any more, it's weird.
> > 
> > I should dug more about it and save the panic messages.
> > 
> > So let's drop this patch for now, I will keep an eye on this and address it later
> > if I can find the problem again.
> 
> Reproduced it again in normal boot with memmap=exactmap, but I agree it's a corner
> case, I remember I saw this in kdump kernel, but I still did not see it in today's
> testing so I think move this issue out of this patch series is fine to me.
 
Please include the following oops when you submit this patch again.

> [    0.359467] BUG: unable to handle kernel paging request at ffff8800d5592020
> [    0.359472] IP: [<ffffffff817dbdbc>] arch_kdebugfs_init+0x11a/0x201
> [    0.359474] PGD 316b067 PUD 37031063 PMD 0 
> [    0.359476] Oops: 0000 [#1] PREEMPT SMP 
> [    0.359477] Modules linked in:
> [    0.359480] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc3+ #65
> [    0.359481] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013
> [    0.359482] task: ffff880037022000 ti: ffff880037188000 task.ti: ffff880037188000
> [    0.359484] RIP: 0010:[<ffffffff817dbdbc>]  [<ffffffff817dbdbc>] arch_kdebugfs_init+0x11a/0x201
> [    0.359485] RSP: 0000:ffff880037189e30  EFLAGS: 00010286
> [    0.359486] RAX: ffff8800372e30e0 RBX: ffff8800372e30e0 RCX: 0000000000000191
> [    0.359486] RDX: 0000000000000000 RSI: ffffffff8168a39e RDI: ffff880037189e50
> [    0.359487] RBP: ffff880037189e90 R08: ffff8800372e30e0 R09: 0000000000000000
> [    0.359488] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003640aea0
> [    0.359489] R13: 00000000d5592018 R14: ffff88003640b200 R15: ffff8800d5592018
> [    0.359490] FS:  0000000000000000(0000) GS:ffff880037480000(0000) knlGS:0000000000000000
> [    0.359491] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.359491] CR2: ffff8800d5592020 CR3: 0000000002716000 CR4: 00000000000407e0
> [    0.359492] Stack:
> [    0.359494]  ffffffff817da6d5 ffff88003640b0e0 ffff88003640afc0 0000000000000004
> [    0.359496]  ffff880037180033 ffffffff8149d82d 00000000c9b42d58 ffffffff817dbca2
> [    0.359498]  0000000000000000 00000000000000f3 0000000000000000 0000000000000000
> [    0.359499] Call Trace:
> [    0.359502]  [<ffffffff817da6d5>] ? boot_params_ksysfs_init+0x1ff/0x244
> [    0.359507]  [<ffffffff8149d82d>] ? mutex_unlock+0x9/0xb
> [    0.359508]  [<ffffffff817dbca2>] ? topology_init+0x36/0x36
> [    0.359512]  [<ffffffff810002bf>] do_one_initcall+0xae/0x15b
> [    0.359515]  [<ffffffff81078500>] ? parameq+0xb/0x1f
> [    0.359516]  [<ffffffff81078770>] ? parse_args+0x25c/0x33a
> [    0.359519]  [<ffffffff817d5ec6>] kernel_init_freeable+0x115/0x19b
> [    0.359521]  [<ffffffff817d573d>] ? do_early_param+0x88/0x88
> [    0.359523]  [<ffffffff81489359>] ? rest_init+0xbd/0xbd
> [    0.359524]  [<ffffffff81489362>] kernel_init+0x9/0xfa
> [    0.359527]  [<ffffffff8149fd0c>] ret_from_fork+0x7c/0xb0
> [    0.359528]  [<ffffffff81489359>] ? rest_init+0xbd/0xbd
> [    0.359548] Code: ff 48 85 c0 48 89 c3 0f 84 b9 00 00 00 49 bf 00 00 00 00 00 88 ff ff 4c 89 28 8b 55 bc 48 8d 7d c0 4d 01 ef 48 c 
> [    0.359549] RIP  [<ffffffff817dbdbc>] arch_kdebugfs_init+0x11a/0x201
> [    0.359550]  RSP <ffff880037189e30>
> [    0.359550] CR2: ffff8800d5592020
> [    0.359559] ---[ end trace d52b3fbe64a26115 ]---
> [    0.621287] kworker/u8:0 (43) used greatest stack depth: 5232 bytes left
> [    0.628021] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [    0.628021] 

-- 
Matt Fleming, Intel Open Source Technology Center

WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt@console-pimps.org>
To: Dave Young <dyoung@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
	x86@kernel.org, mjg59@srcf.ucam.org, hpa@zytor.com,
	James.Bottomley@HansenPartnership.com, vgoyal@redhat.com,
	ebiederm@xmission.com, horms@verge.net.au,
	kexec@lists.infradead.org, bp@alien8.de, greg@kroah.com,
	toshi.kani@hp.com, akpm@linux-foundation.org, mingo@kernel.org,
	msalter@redhat.com, leif.lindholm@linaro.org
Subject: Re: [PATCH v6 14/14] x86: kdebugfs do not use __va for getting setup_data virt addr
Date: Tue, 17 Dec 2013 11:24:52 +0000	[thread overview]
Message-ID: <20131217112452.GA3145@console-pimps.org> (raw)
In-Reply-To: <20131217065346.GG6751@dhcp-16-126.nay.redhat.com>

On Tue, 17 Dec, at 02:53:46PM, Dave Young wrote:
> On 12/17/13 at 02:24pm, Dave Young wrote:
> > On 12/16/13 at 04:35pm, Matt Fleming wrote:
> > > On Mon, 16 Dec, at 05:30:35PM, Dave Young wrote:
> > > > kdump kernel will use memmap=exactmap kernel cmdline, but __va does not
> > > > work in case memmap=exactmap, so let's always use ioremap_cache.
> > > > 
> > > > Signed-off-by: Dave Young <dyoung@redhat.com>
> > > > ---
> > > >  arch/x86/kernel/kdebugfs.c | 35 +++++++++++------------------------
> > > >  1 file changed, 11 insertions(+), 24 deletions(-)
> > > 
> > > Dave, I've no idea why this change is necessary from the commit log. Is
> > > it required for kexec to function on EFI? Why does __va() not work in
> > > the memmap=exactmap case?
> > > 
> > 
> > During previous kdump tests I saw panics while reading the setup_data in debugfs.
> > I thought it is caused by some unmapped addresses. At that time I also reproduced
> > it by booting the non-kexec kernel with memmap=exact.
> > 
> > Since you are asking about this I'm testing it again but I seems can not
> > reproduce this problem any more, it's weird.
> > 
> > I should dug more about it and save the panic messages.
> > 
> > So let's drop this patch for now, I will keep an eye on this and address it later
> > if I can find the problem again.
> 
> Reproduced it again in normal boot with memmap=exactmap, but I agree it's a corner
> case, I remember I saw this in kdump kernel, but I still did not see it in today's
> testing so I think move this issue out of this patch series is fine to me.
 
Please include the following oops when you submit this patch again.

> [    0.359467] BUG: unable to handle kernel paging request at ffff8800d5592020
> [    0.359472] IP: [<ffffffff817dbdbc>] arch_kdebugfs_init+0x11a/0x201
> [    0.359474] PGD 316b067 PUD 37031063 PMD 0 
> [    0.359476] Oops: 0000 [#1] PREEMPT SMP 
> [    0.359477] Modules linked in:
> [    0.359480] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.13.0-rc3+ #65
> [    0.359481] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013
> [    0.359482] task: ffff880037022000 ti: ffff880037188000 task.ti: ffff880037188000
> [    0.359484] RIP: 0010:[<ffffffff817dbdbc>]  [<ffffffff817dbdbc>] arch_kdebugfs_init+0x11a/0x201
> [    0.359485] RSP: 0000:ffff880037189e30  EFLAGS: 00010286
> [    0.359486] RAX: ffff8800372e30e0 RBX: ffff8800372e30e0 RCX: 0000000000000191
> [    0.359486] RDX: 0000000000000000 RSI: ffffffff8168a39e RDI: ffff880037189e50
> [    0.359487] RBP: ffff880037189e90 R08: ffff8800372e30e0 R09: 0000000000000000
> [    0.359488] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88003640aea0
> [    0.359489] R13: 00000000d5592018 R14: ffff88003640b200 R15: ffff8800d5592018
> [    0.359490] FS:  0000000000000000(0000) GS:ffff880037480000(0000) knlGS:0000000000000000
> [    0.359491] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [    0.359491] CR2: ffff8800d5592020 CR3: 0000000002716000 CR4: 00000000000407e0
> [    0.359492] Stack:
> [    0.359494]  ffffffff817da6d5 ffff88003640b0e0 ffff88003640afc0 0000000000000004
> [    0.359496]  ffff880037180033 ffffffff8149d82d 00000000c9b42d58 ffffffff817dbca2
> [    0.359498]  0000000000000000 00000000000000f3 0000000000000000 0000000000000000
> [    0.359499] Call Trace:
> [    0.359502]  [<ffffffff817da6d5>] ? boot_params_ksysfs_init+0x1ff/0x244
> [    0.359507]  [<ffffffff8149d82d>] ? mutex_unlock+0x9/0xb
> [    0.359508]  [<ffffffff817dbca2>] ? topology_init+0x36/0x36
> [    0.359512]  [<ffffffff810002bf>] do_one_initcall+0xae/0x15b
> [    0.359515]  [<ffffffff81078500>] ? parameq+0xb/0x1f
> [    0.359516]  [<ffffffff81078770>] ? parse_args+0x25c/0x33a
> [    0.359519]  [<ffffffff817d5ec6>] kernel_init_freeable+0x115/0x19b
> [    0.359521]  [<ffffffff817d573d>] ? do_early_param+0x88/0x88
> [    0.359523]  [<ffffffff81489359>] ? rest_init+0xbd/0xbd
> [    0.359524]  [<ffffffff81489362>] kernel_init+0x9/0xfa
> [    0.359527]  [<ffffffff8149fd0c>] ret_from_fork+0x7c/0xb0
> [    0.359528]  [<ffffffff81489359>] ? rest_init+0xbd/0xbd
> [    0.359548] Code: ff 48 85 c0 48 89 c3 0f 84 b9 00 00 00 49 bf 00 00 00 00 00 88 ff ff 4c 89 28 8b 55 bc 48 8d 7d c0 4d 01 ef 48 c 
> [    0.359549] RIP  [<ffffffff817dbdbc>] arch_kdebugfs_init+0x11a/0x201
> [    0.359550]  RSP <ffff880037189e30>
> [    0.359550] CR2: ffff8800d5592020
> [    0.359559] ---[ end trace d52b3fbe64a26115 ]---
> [    0.621287] kworker/u8:0 (43) used greatest stack depth: 5232 bytes left
> [    0.628021] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [    0.628021] 

-- 
Matt Fleming, Intel Open Source Technology Center

  reply	other threads:[~2013-12-17 11:25 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-16  9:30 [PATCH v6 00/14] kexec kernel efi runtime support Dave Young
2013-12-16  9:30 ` Dave Young
2013-12-16  9:30 ` Dave Young
2013-12-16  9:30 ` [PATCH v6 01/14] x86/mm: sparse warning fix for early_memremap Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 02/14] efi: Use early_memremap and early_memunmap to fix sparse warnings Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 03/14] efi: remove unused variables in __map_region Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 04/14] efi: add a wrapper function efi_map_region_fixed Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 05/14] efi: reserve boot service fix Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 06/14] efi: cleanup efi_enter_virtual_mode function Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 07/14] efi: export more efi table variable to sysfs Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 08/14] efi: export efi runtime memory mapping " Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16 15:09   ` Matt Fleming
2013-12-16 15:09     ` Matt Fleming
2013-12-16 15:09     ` Matt Fleming
2013-12-17  6:13     ` Dave Young
2013-12-17  6:13       ` Dave Young
2013-12-17  6:13       ` Dave Young
2013-12-17  8:00   ` [PATCH v7 " Dave Young
2013-12-17  8:00     ` Dave Young
2013-12-17  8:00     ` Dave Young
2013-12-16  9:30 ` [PATCH v6 09/14] efi: passing kexec necessary efi data via setup_data Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-17  8:01   ` [PATCH v7 " Dave Young
2013-12-17  8:01     ` Dave Young
2013-12-17  8:01     ` Dave Young
2013-12-17  8:08     ` Dave Young
2013-12-17  8:08       ` Dave Young
2013-12-17  8:08       ` Dave Young
2013-12-16  9:30 ` [PATCH v6 10/14] efi: only print saved efi runtime maps instead of all memmap ranges for kexec Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-19 16:41   ` Matt Fleming
2013-12-19 16:41     ` Matt Fleming
2013-12-19 16:41     ` Matt Fleming
2013-12-20  1:35     ` Dave Young
2013-12-20  1:35       ` Dave Young
2013-12-20  1:35       ` Dave Young
2013-12-20  1:57       ` Dave Young
2013-12-20  1:57         ` Dave Young
2013-12-20  1:57         ` Dave Young
2013-12-16  9:30 ` [PATCH v6 11/14] x86: add xloadflags bit for efi runtime support on kexec Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 12/14] x86: export x86 boot_params to sysfs Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 13/14] x86: reserve setup_data ranges late after parsing memmap cmdline Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30 ` [PATCH v6 14/14] x86: kdebugfs do not use __va for getting setup_data virt addr Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16  9:30   ` Dave Young
2013-12-16 16:35   ` Matt Fleming
2013-12-16 16:35     ` Matt Fleming
2013-12-16 16:35     ` Matt Fleming
2013-12-17  6:24     ` Dave Young
2013-12-17  6:24       ` Dave Young
2013-12-17  6:24       ` Dave Young
2013-12-17  6:53       ` Dave Young
2013-12-17  6:53         ` Dave Young
2013-12-17  6:53         ` Dave Young
2013-12-17 11:24         ` Matt Fleming [this message]
2013-12-17 11:24           ` Matt Fleming
2013-12-17 11:24           ` Matt Fleming
2013-12-18  9:29           ` Dave Young
2013-12-18  9:29             ` Dave Young
2013-12-18  9:29             ` Dave Young

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=20131217112452.GA3145@console-pimps.org \
    --to=matt@console-pimps.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dyoung@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=greg@kroah.com \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=msalter@redhat.com \
    --cc=toshi.kani@hp.com \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.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.