From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
"David S. Miller" <davem@davemloft.net>,
"H. Peter Anvin" <hpa@zytor.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
stable@vger.kernel.org,
"Alexander Duyck" <alexander.h.duyck@intel.com>,
"Andrea Arcangeli" <aarcange@redhat.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Andrzej Pietrasiewicz" <andrzej.p@samsung.com>,
"Arnd Bergmann" <arnd@arndb.de>, "Borislav Petkov" <bp@alien8.de>,
"Borislav Petkov" <bp@suse.de>,
"Christoph Lameter" <cl@linux.com>,
"Daniel J Blueman" <daniel@numascale-asia.com>,
"Dave Hansen" <dave@linux.vnet.ibm.com>,
"Eric Biederman" <ebiederm@xmission.com>,
"Fenghua Yu" <fenghua.yu@intel.com>,
"Frederic Weisbecker" <fweisbec@gmail.com>,
"Gleb Natapov" <gleb@redhat.com>,
"Gokul Caushik" <caushik1@gmail.com>,
"H. J. Lu" <hjl.tools@gmail.com>,
"Hugh Dickins" <hughd@google.com>, "Ingo Molnar" <mingo@elte.hu>,
"Ingo Molnar" <mingo@kernel.org>,
"Jacob Shin" <jacob.shin@amd.com>,
"Jamie Lokier" <jamie@shareable.org>,
"Jarkko Sakkinen" <jarkko.sakkinen@intel.com>,
"Jeremy Fitzhardinge" <jeremy@goop.org>,
"Joe Millenbach" <jmillenbach@gmail.com>,
"Joerg Roedel" <joro@8bytes.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Josh Triplett" <josh@joshtriplett.org>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Lee Schermerhorn" <Lee.Schermerhorn@hp.com>,
"Len Brown" <len.brown@intel.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Matt Fleming" <matt.fleming@intel.com>,
"Mel Gorman" <mgorman@suse.de>, "Paul Turner" <pjt@google.com>,
"Pavel Machek" <pavel@ucw.cz>,
"Pekka Enberg" <penberg@kernel.org>,
"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
"Ralf Baechle" <ralf@linux-mips.org>,
"Rik van Riel" <riel@redhat.com>, "Rob Landley" <rob@landley.net>,
"Russell King" <linux@arm.linux.org.uk>,
"Rusty Russell" <rusty@rustcorp.com.au>,
"Shuah Khan" <shuah.khan@hp.com>,
"Shuah Khan" <shuahkhan@gmail.com>,
"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Yasuaki Ishimatsu" <isimatu.yasuaki@jp.fujitsu.com>,
"Zachary Amsden" <zamsden@gmail.com>,
avi@redhat.com, linux-mips@linux-mips.org,
linux-pm@vger.kernel.org, mst@redhat.com,
sparclinux@vger.kernel.org,
virtualization@lists.linux-foundation.org,
xen-devel@lists.xensource.com
Subject: Re: [GIT PULL] x86/mm changes for v3.9-rc1
Date: Fri, 22 Feb 2013 13:23:21 -0500 [thread overview]
Message-ID: <20130222182321.GA11311@phenom.dumpdata.com> (raw)
In-Reply-To: <CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
> > [ 0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
> > [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
> > [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
> > [ 0.000000] No AGP bridge found
> > [ 0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
> > [ 0.000000] e820: lacanning 1 areas for low memory corruption
> > [ 0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
> > [ 0.000000] reserving inaccessible SNB gfx pages
> > [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
> > [ 0.000000] [mem 0x00000000-0x000fffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
> > [ 0.000000] [mem 0x1f2000000-0x1f20c3fff] page 4k
> > [ 0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
> > [ 0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
> > [ 0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
> > [ 0.000000] [mem 0x1f0000000-0x1f1ffffff] page 4k
> > [ 0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
> > [ 0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
> > [ 0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
> > [ 0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
> > [ 0.000000] [mem 0x180000000-0x1efffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
> > [ 0.000000] [mem 0x00100000-0x1fffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
> > [ 0.000000] [mem 0x20200000-0x3fffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
> > [ 0.000000] [mem 0x40200000-0xbad7ffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
> > [ 0.000000] [mem 0xbadf4000-0xbadf5fff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
> > [ 0.000000] [mem 0xbae7f000-0xbaffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
> > [ 0.000000] [mem 0x100000000-0x17fffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
> > [ 0.000000] [mem 0x1f20c4000-0x23fdfffff] page 4k
>
> so init_memory_mapping are all done.
Not so.
>
> > (XEN) d0:v0: unhandled page fault (ec=0000)
> > (XEN) Pagetable walk from ffffea000005b2d0:
> > (XEN) L4[0x1d4] = 0000000000000000 ffffffffffffffff
> > (XEN) domain_crash_sync called from entry.S
> > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> > (XEN) ----[ Xen-4.1.5-pre x86_64 debug=y Tainted: C ]----
> > (XEN) CPU: 0
> > (XEN) RIP: e033:[<ffffffff8103feba>]
> > (XEN) RFLAGS: 0000000000000206 EM: 1 CONTEXT: pv guest
> > (XEN) rax: ffffea0000000000 rbx: 0000000001a0c000 rcx: 0000000080000000
> > (XEN) rdx: 000000000005b2a0 rsi: 0000000001a0c000 rdi: 0000000000000000
> > (XEN) rbp: ffffffff81a01dd8 rsp: ffffffff81a01d90 r8: 0000000000000000
> > (XEN) r9: 0000000010000001 r10: 0000000000000005 r11: 0000000000100000
> > (XEN) r12: 0000000000000000 r13: 0000020000000000 r14: 0000000000000000
> > (XEN) r15: 0000000000100000 cr0: 000000008005003b cr4: 00000000000026f0
> > (XEN) cr3: 0000000221a0c000 cr2: ffffea000005b2d0
> > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
> > (XEN) Guest stack trace from rsp=ffffffff81a01d90:
> > (XEN) 0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
> > (XEN) 000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
> > (XEN) 0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
> > (XEN) 00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
> > (XEN) ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
> > (XEN) ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
> > (XEN) ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
> > (XEN) ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
> > (XEN) ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
> > (XEN) ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
> > (XEN) 0000000000000005 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
> > (XEN) 0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
> > (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
> > (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
>
> can we get kernel trace instead?
If you look at the initial one I had posted:
> >> Call Trace:
> >> [<ffffffff8103feba>] xen_get_user_pgd+0x5a <--
> >> [<ffffffff8103feba>] xen_get_user_pgd+0x5a
> >> [<ffffffff81042d27>] xen_write_cr3+0x77
> >> [<ffffffff81ad2d21>] init_mem_mapping+0x1f9
> >> [<ffffffff81ac293f>] setup_arch+0x742
> >> [<ffffffff81666d71>] printk+0x48
> >> [<ffffffff81abcd62>] start_kernel+0x90
> >> [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b
> >> [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a
> >> [<ffffffff81abf0c7>] xen_start_kernel+0x564
The EIP matches with what this stack strace has. So we are still in
init_mem_mapping.
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: linux-mips@linux-mips.org,
"Jeremy Fitzhardinge" <jeremy@goop.org>,
"H. J. Lu" <hjl.tools@gmail.com>,
"Frederic Weisbecker" <fweisbec@gmail.com>,
"Joe Millenbach" <jmillenbach@gmail.com>,
virtualization@lists.linux-foundation.org,
"Gokul Caushik" <caushik1@gmail.com>,
"Ralf Baechle" <ralf@linux-mips.org>,
"Pavel Machek" <pavel@ucw.cz>, "H. Peter Anvin" <hpa@zytor.com>,
sparclinux@vger.kernel.org, "Christoph Lameter" <cl@linux.com>,
"Ingo Molnar" <mingo@kernel.org>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Andrea Arcangeli" <aarcange@redhat.com>,
"Lee Schermerhorn" <Lee.Schermerhorn@hp.com>,
xen-devel@lists.xensource.com,
"Russell King" <linux@arm.linux.org.uk>,
"Len Brown" <len.brown@intel.com>,
"Joerg Roedel" <joro@8bytes.org>,
linux-pm@vger.kernel.org, "Hugh Dickins" <hughd@google.com>,
"Yasuaki Ishimatsu" <isimatu.yasuaki@j>
Subject: Re: [GIT PULL] x86/mm changes for v3.9-rc1
Date: Fri, 22 Feb 2013 13:23:21 -0500 [thread overview]
Message-ID: <20130222182321.GA11311@phenom.dumpdata.com> (raw)
In-Reply-To: <CAE9FiQUe86t2Me4uF=oCz5VGqa8AJYrGQHhPA=w_9OP5OSWN=w@mail.gmail.com>
> > [ 0.000000] DMI: MSI MS-7680/H61M-P23 (MS-7680), BIOS V17.0 03/14/2011
> > [ 0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
> > [ 0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
> > [ 0.000000] No AGP bridge found
> > [ 0.000000] e820: last_pfn = 0x23fe00 max_arch_pfn = 0x400000000
> > [ 0.000000] e820: lacanning 1 areas for low memory corruption
> > [ 0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
> > [ 0.000000] reserving inaccessible SNB gfx pages
> > [ 0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
> > [ 0.000000] [mem 0x00000000-0x000fffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x1f2000000-0x1f20c3fff]
> > [ 0.000000] [mem 0x1f2000000-0x1f20c3fff] page 4k
> > [ 0.000000] BRK [0x01cd2000, 0x01cd2fff] PGTABLE
> > [ 0.000000] BRK [0x01cd3000, 0x01cd3fff] PGTABLE
> > [ 0.000000] init_memory_mapping: [mem 0x1f0000000-0x1f1ffffff]
> > [ 0.000000] [mem 0x1f0000000-0x1f1ffffff] page 4k
> > [ 0.000000] BRK [0x01cd4000, 0x01cd4fff] PGTABLE
> > [ 0.000000] BRK [0x01cd5000, 0x01cd5fff] PGTABLE
> > [ 0.000000] BRK [0x01cd6000, 0x01cd6fff] PGTABLE
> > [ 0.000000] init_memory_mapping: [mem 0x180000000-0x1efffffff]
> > [ 0.000000] [mem 0x180000000-0x1efffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x00100000-0x1fffffff]
> > [ 0.000000] [mem 0x00100000-0x1fffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x20200000-0x3fffffff]
> > [ 0.000000] [mem 0x20200000-0x3fffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x40200000-0xbad7ffff]
> > [ 0.000000] [mem 0x40200000-0xbad7ffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0xbadf4000-0xbadf5fff]
> > [ 0.000000] [mem 0xbadf4000-0xbadf5fff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0xbae7f000-0xbaffffff]
> > [ 0.000000] [mem 0xbae7f000-0xbaffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
> > [ 0.000000] [mem 0x100000000-0x17fffffff] page 4k
> > [ 0.000000] init_memory_mapping: [mem 0x1f20c4000-0x23fdfffff]
> > [ 0.000000] [mem 0x1f20c4000-0x23fdfffff] page 4k
>
> so init_memory_mapping are all done.
Not so.
>
> > (XEN) d0:v0: unhandled page fault (ec=0000)
> > (XEN) Pagetable walk from ffffea000005b2d0:
> > (XEN) L4[0x1d4] = 0000000000000000 ffffffffffffffff
> > (XEN) domain_crash_sync called from entry.S
> > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> > (XEN) ----[ Xen-4.1.5-pre x86_64 debug=y Tainted: C ]----
> > (XEN) CPU: 0
> > (XEN) RIP: e033:[<ffffffff8103feba>]
> > (XEN) RFLAGS: 0000000000000206 EM: 1 CONTEXT: pv guest
> > (XEN) rax: ffffea0000000000 rbx: 0000000001a0c000 rcx: 0000000080000000
> > (XEN) rdx: 000000000005b2a0 rsi: 0000000001a0c000 rdi: 0000000000000000
> > (XEN) rbp: ffffffff81a01dd8 rsp: ffffffff81a01d90 r8: 0000000000000000
> > (XEN) r9: 0000000010000001 r10: 0000000000000005 r11: 0000000000100000
> > (XEN) r12: 0000000000000000 r13: 0000020000000000 r14: 0000000000000000
> > (XEN) r15: 0000000000100000 cr0: 000000008005003b cr4: 00000000000026f0
> > (XEN) cr3: 0000000221a0c000 cr2: ffffea000005b2d0
> > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
> > (XEN) Guest stack trace from rsp=ffffffff81a01d90:
> > (XEN) 0000000080000000 0000000000100000 0000000000000000 ffffffff8103feba
> > (XEN) 000000010000e030 0000000000010006 ffffffff81a01dd8 000000000000e02b
> > (XEN) 0000000000000000 ffffffff81a01e08 ffffffff81042d27 000000023fe00000
> > (XEN) 00000001f20c4000 0000020000000000 00000001acac7000 ffffffff81a01e48
> > (XEN) ffffffff81ad2d21 0000000000000000 0000000000000028 0000000040004000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 ffffffff81a01ed8
> > (XEN) ffffffff81ac293f ffffffff81b46900 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 ffffffff81a01f00 ffffffff8165fbd1 ffffffff00000010
> > (XEN) ffffffff81a01ee8 ffffffff81a01ea8 0000000000000000 ffffffff81a01ec8
> > (XEN) ffffffffffffffff ffffffff81b46900 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 ffffffff81a01f28 ffffffff81abcd62 ffffffff96062000
> > (XEN) ffffffff81cc6000 ffffffff81ccd000 ffffffff81b4f2e0 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 ffffffff81a01f38
> > (XEN) ffffffff81abc5f7 ffffffff81a01ff8 ffffffff81abf0c7 0300000100000032
> > (XEN) 0000000000000005 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> > (XEN) 0000000000000000 819822831fc9cbf5 000206a700100800 0000000000000001
> > (XEN) 0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305
> > (XEN) Domain 0 crashed: rebooting machine in 5 seconds.
> > (XEN) Resetting with ACPI MEMORY or I/O RESET_REG.
>
> can we get kernel trace instead?
If you look at the initial one I had posted:
> >> Call Trace:
> >> [<ffffffff8103feba>] xen_get_user_pgd+0x5a <--
> >> [<ffffffff8103feba>] xen_get_user_pgd+0x5a
> >> [<ffffffff81042d27>] xen_write_cr3+0x77
> >> [<ffffffff81ad2d21>] init_mem_mapping+0x1f9
> >> [<ffffffff81ac293f>] setup_arch+0x742
> >> [<ffffffff81666d71>] printk+0x48
> >> [<ffffffff81abcd62>] start_kernel+0x90
> >> [<ffffffff8109416b>] __add_preferred_console.clone.1+0x9b
> >> [<ffffffff81abc5f7>] x86_64_start_reservations+0x2a
> >> [<ffffffff81abf0c7>] xen_start_kernel+0x564
The EIP matches with what this stack strace has. So we are still in
init_mem_mapping.
next prev parent reply other threads:[~2013-02-22 18:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 0:34 [GIT PULL] x86/mm changes for v3.9-rc1 H. Peter Anvin
2013-02-22 0:34 ` H. Peter Anvin
2013-02-22 0:34 ` H. Peter Anvin
2013-02-22 16:22 ` Linus Torvalds
2013-02-22 16:22 ` Linus Torvalds
2013-02-22 17:31 ` H. Peter Anvin
2013-02-22 17:31 ` H. Peter Anvin
2013-02-22 16:55 ` Konrad Rzeszutek Wilk
2013-02-22 16:55 ` Konrad Rzeszutek Wilk
2013-02-22 17:12 ` H. Peter Anvin
2013-02-22 17:12 ` H. Peter Anvin
2013-02-22 17:38 ` Konrad Rzeszutek Wilk
2013-02-22 17:38 ` Konrad Rzeszutek Wilk
2013-02-22 18:06 ` Stefano Stabellini
2013-02-22 18:06 ` Stefano Stabellini
2013-02-22 18:06 ` Stefano Stabellini
2013-02-22 18:22 ` Yinghai Lu
2013-02-22 18:22 ` Yinghai Lu
2013-02-22 18:24 ` H. Peter Anvin
2013-02-22 18:24 ` H. Peter Anvin
2013-02-22 18:24 ` H. Peter Anvin
2013-02-22 18:08 ` Yinghai Lu
2013-02-22 18:08 ` Yinghai Lu
2013-02-22 17:24 ` Konrad Rzeszutek Wilk
2013-02-22 17:24 ` Konrad Rzeszutek Wilk
2013-02-22 17:24 ` Konrad Rzeszutek Wilk
2013-02-22 17:30 ` H. Peter Anvin
2013-02-22 17:30 ` H. Peter Anvin
2013-02-22 17:30 ` H. Peter Anvin
2013-02-22 17:53 ` Yinghai Lu
2013-02-22 17:53 ` Yinghai Lu
2013-02-22 18:23 ` Konrad Rzeszutek Wilk [this message]
2013-02-22 18:23 ` Konrad Rzeszutek Wilk
2013-02-22 18:25 ` [Xen-devel] " Andrew Cooper
2013-02-22 18:25 ` Andrew Cooper
2013-02-22 17:30 ` Dave Hansen
2013-02-22 17:30 ` Dave Hansen
2013-02-22 17:33 ` H. Peter Anvin
2013-02-22 17:33 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2013-02-22 0:34 H. Peter Anvin
[not found] <CAE9FiQX5r02Prsw-f0HsgLVJ0FZeYL9aggXebwWR-E5oYsj6cw@mail.gmail.com>
[not found] ` <5127C620.2040605@linux.intel.com>
[not found] ` <alpine.DEB.2.02.1302221929040.22997@kaball.uk.xensource.com>
[not found] ` <5127CE65.5010703@linux.intel.com>
[not found] ` <CAE9FiQXHHFb0W+aJCsefRNj4p+X1+m8JOLUDz74w-nAjnhym+A@mail.gmail.com>
[not found] ` <5127DDB3.2010309@zytor.com>
[not found] ` <CAE9FiQWctM60VwXJYtOXwPBNLUoz966Fr1g6MPsPoJBiye88YQ@mail.gmail.com>
[not found] ` <5127FBA4.1040506@zytor.com>
[not found] ` <20130223003738.GA23545@phenom.dumpdata.com>
[not found] ` <CAE9FiQVTbDkvU8KQGVoYv3kn6UeCTcdiPA2hvw21OKtNbM=XKg@mail.gmail.com>
[not found] ` <20130223012716.GA28377@phenom.dumpdata.com>
2013-02-23 1:39 ` Yinghai Lu
2013-02-23 19:43 ` Konrad Rzeszutek Wilk
2013-02-23 21:37 ` Yinghai Lu
2013-02-23 21:42 ` H. Peter Anvin
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=20130222182321.GA11311@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Lee.Schermerhorn@hp.com \
--cc=a.p.zijlstra@chello.nl \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@intel.com \
--cc=andrzej.p@samsung.com \
--cc=arnd@arndb.de \
--cc=avi@redhat.com \
--cc=bp@alien8.de \
--cc=bp@suse.de \
--cc=caushik1@gmail.com \
--cc=cl@linux.com \
--cc=daniel@numascale-asia.com \
--cc=dave@linux.vnet.ibm.com \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=fenghua.yu@intel.com \
--cc=fweisbec@gmail.com \
--cc=gleb@redhat.com \
--cc=hannes@cmpxchg.org \
--cc=hjl.tools@gmail.com \
--cc=hpa@linux.intel.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=jacob.shin@amd.com \
--cc=jamie@shareable.org \
--cc=jarkko.sakkinen@intel.com \
--cc=jeremy@goop.org \
--cc=jmillenbach@gmail.com \
--cc=joro@8bytes.org \
--cc=josh@joshtriplett.org \
--cc=kyungmin.park@samsung.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=matt.fleming@intel.com \
--cc=mgorman@suse.de \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pavel@ucw.cz \
--cc=penberg@kernel.org \
--cc=pjt@google.com \
--cc=ralf@linux-mips.org \
--cc=riel@redhat.com \
--cc=rjw@sisk.pl \
--cc=rob@landley.net \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=shuah.khan@hp.com \
--cc=shuahkhan@gmail.com \
--cc=sparclinux@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=ville.syrjala@linux.intel.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=xen-devel@lists.xensource.com \
--cc=yinghai@kernel.org \
--cc=zamsden@gmail.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.