From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Jan Beulich <jbeulich@suse.com>,
Matt Fleming <matt.fleming@intel.com>,
David Howells <dhowells@redhat.com>,
Grant Likely <grant.likely@secretlab.ca>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Arnd Bergmann <arnd@arndb.de>, Dave Jones <davej@redhat.com>,
Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Michael Kerrisk <mtk.manpages@gmail.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [GIT PULL] x86/uapi for 3.8
Date: Sat, 15 Dec 2012 21:06:12 +0100 [thread overview]
Message-ID: <20121215200612.GA221@x4> (raw)
In-Reply-To: <CA+55aFxi5SnacGoHzHuth4PvTRQQWA5kWM+D2Mn+FgV4VGYADQ@mail.gmail.com>
On 2012.12.15 at 11:58 -0800, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> >
> > Matt is on vacation, and I'm partly offline for the weekend, but that
> > definitely seems suspicious. Do we have a memory map of the affected
> > machine(s)?
>
> Here's mine.
>
> e820: BIOS-provided physical RAM map:
> BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
> BIOS-e820: [mem 0x000000000009e800-0x000000000009ffff] reserved
> BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
> BIOS-e820: [mem 0x0000000000100000-0x00000000bdc6ffff] usable
> BIOS-e820: [mem 0x00000000bdc70000-0x00000000bdc87fff] ACPI data
> BIOS-e820: [mem 0x00000000bdc88000-0x00000000bdcdbfff] ACPI NVS
> BIOS-e820: [mem 0x00000000bdcdc000-0x00000000bfffffff] reserved
> BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
> BIOS-e820: [mem 0x0000000100000000-0x00000001fbffffff] usable
> BIOS-e820: [mem 0x00000001fc000000-0x00000001ffffffff] reserved
> BIOS-e820: [mem 0x0000000200000000-0x000000023fffffff] usable
>
> but as mentioned, there's bound to be some particular kernel layout
> that triggers this, because I definitely ran a few kernels with that
> commit in it without problems (and clearly other people are too).
> Looking at my boot log, I had successful boots with both 6a57d104c8cb
> and c2714334b944, which contains that commit.
>
> It might also be that it causes some massive corruption at boot time,
> but it then requires that that particular memory is actually used. So
> maybe it's not so much about the memory map except indirectly.
>
> But that commit *does* look a lot more likely than the things I looked at.
>
> Markus, how did you happen to pinpoint that particular commit? Is it
> entirely repeatable for you?
Yes, although at one point during bisecting the BUG disappeared and the
screen went simply black during boot and X never started. I marked this
as bad and continued the bisection.
Here is my mem-map:
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000100-0x000000000009fbff] usable
BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000e6000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x00000000dfe8ffff] usable
BIOS-e820: [mem 0x00000000dfe90000-0x00000000dfea7fff] ACPI data
BIOS-e820: [mem 0x00000000dfea8000-0x00000000dfecffff] ACPI NVS
BIOS-e820: [mem 0x00000000dfed0000-0x00000000dfefffff] reserved
BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
BIOS-e820: [mem 0x0000000100000000-0x000000021fffffff] usable
--
Markus
next prev parent reply other threads:[~2012-12-15 20:06 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-12 22:11 [GIT PULL] x86/uapi for 3.8 H. Peter Anvin
2012-12-12 23:48 ` David Howells
2012-12-14 18:25 ` Linus Torvalds
2012-12-14 23:45 ` David Howells
2012-12-15 1:16 ` Linus Torvalds
2012-12-15 1:41 ` Linus Torvalds
2012-12-15 1:47 ` Linus Torvalds
2012-12-15 16:33 ` Markus Trippelsdorf
2012-12-15 16:35 ` Markus Trippelsdorf
2012-12-16 12:43 ` Matt Fleming
2012-12-16 13:25 ` Markus Trippelsdorf
2012-12-16 14:54 ` Matt Fleming
2012-12-16 20:12 ` Linus Torvalds
2012-12-16 22:07 ` Linus Torvalds
2012-12-16 22:25 ` H. Peter Anvin
2012-12-16 22:40 ` Matt Fleming
2012-12-16 22:52 ` Linus Torvalds
2012-12-16 23:49 ` Markus Trippelsdorf
2012-12-15 18:35 ` Linus Torvalds
2012-12-15 19:41 ` H. Peter Anvin
2012-12-15 19:58 ` Linus Torvalds
2012-12-15 20:06 ` Markus Trippelsdorf [this message]
2012-12-15 21:04 ` Markus Trippelsdorf
2012-12-15 21:06 ` Linus Torvalds
2012-12-15 21:36 ` H. Peter Anvin
2012-12-15 22:05 ` Yinghai Lu
2012-12-15 23:37 ` Linus Torvalds
2012-12-15 23:46 ` H. Peter Anvin
2012-12-16 12:46 ` Matt Fleming
2012-12-15 21:37 ` Dave Jones
2012-12-15 23:47 ` H. Peter Anvin
2012-12-17 9:04 ` Jan Beulich
2012-12-17 15:44 ` Linus Torvalds
2012-12-17 16:00 ` Jan Beulich
2012-12-17 16:39 ` H. Peter Anvin
2012-12-17 17:03 ` Jan Beulich
2012-12-17 17:15 ` H. Peter Anvin
2012-12-18 8:02 ` Jan Beulich
2012-12-15 4:25 ` 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=20121215200612.GA221@x4 \
--to=markus@trippelsdorf.de \
--cc=arnd@arndb.de \
--cc=davej@redhat.com \
--cc=dhowells@redhat.com \
--cc=g.liakhovetski@gmx.de \
--cc=grant.likely@secretlab.ca \
--cc=hpa@zytor.com \
--cc=jbeulich@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mingo@elte.hu \
--cc=mtk.manpages@gmail.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.