>>> On 17.12.12 at 18:15, "H. Peter Anvin" wrote:
> On 12/17/2012 09:03 AM, Jan Beulich wrote:
> On 17.12.12 at 17:39, "H. Peter Anvin" wrote:
>>> Right, I think you nailed this one. This patch copies PTEs from the
>>> kernel PTEs and thus they will have the global bit set. It obviously
>>>
On 12/17/2012 09:03 AM, Jan Beulich wrote:
On 17.12.12 at 17:39, "H. Peter Anvin" wrote:
>> Right, I think you nailed this one. This patch copies PTEs from the
>> kernel PTEs and thus they will have the global bit set. It obviously
>> makes no sense to *copy* PTEs from the kernel and yet le
>>> On 17.12.12 at 17:39, "H. Peter Anvin" wrote:
> Right, I think you nailed this one. This patch copies PTEs from the
> kernel PTEs and thus they will have the global bit set. It obviously
> makes no sense to *copy* PTEs from the kernel and yet leaving the global
> bit set, which means there a
On 12/17/2012 08:00 AM, Jan Beulich wrote:
On 17.12.12 at 16:44, Linus Torvalds wrote:
>> On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich wrote:
>>>
>>> How about this being caused by using the same lower level
>>> page table entries that swapper_pg_dir uses, namely including
>>> the _PAGE_GLOB
>>> On 17.12.12 at 16:44, Linus Torvalds wrote:
> On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich wrote:
>>
>> How about this being caused by using the same lower level
>> page table entries that swapper_pg_dir uses, namely including
>> the _PAGE_GLOBAL bits? efi_call_virt_{pre,epi}log() only write
On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich wrote:
>
> How about this being caused by using the same lower level
> page table entries that swapper_pg_dir uses, namely including
> the _PAGE_GLOBAL bits? efi_call_virt_{pre,epi}log() only write
> CR3 (see 185034e72d591f9465e5e18f937ed642e7ea0070), b
>>> On 15.12.12 at 19:35, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf
> wrote:
>> On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
>>>
>>> Ho humm. Anybody else see anything strange?
>>
>> Yes. I'm seeing a BUG early during boot on my machine (RIP=NULL):
>>
>>
On 2012.12.16 at 14:07 -0800, Linus Torvalds wrote:
> On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds
> wrote:
> >
> > So I'll test it and see, and hope for the best,
>
> No such luck. Applying your patch and the reverting the revert of the
> EFI date thing results in the same oops in find_vma()
On Sun, Dec 16, 2012 at 2:40 PM, Matt Fleming wrote:
>
> Linus have you got a stacktrace for the oops (and maybe even a dmesg)? I
> suspect it won't tell us much, but any/all info we can gather will help.
Sadly, it starts scrolling away pretty quickly, and it really wasn't
very useful. None of th
On Sun, 2012-12-16 at 14:07 -0800, Linus Torvalds wrote:
> On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds
> wrote:
> >
> > So I'll test it and see, and hope for the best,
>
> No such luck. Applying your patch and the reverting the revert of the
> EFI date thing results in the same oops in find_
On 12/16/2012 02:07 PM, Linus Torvalds wrote:
> On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds
> wrote:
>>
>> So I'll test it and see, and hope for the best,
>
> No such luck. Applying your patch and the reverting the revert of the
> EFI date thing results in the same oops in find_vma() from ud
On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds
wrote:
>
> So I'll test it and see, and hope for the best,
No such luck. Applying your patch and the reverting the revert of the
EFI date thing results in the same oops in find_vma() from udev that I
had before.
So the patch is still scrogged, and
On Sun, Dec 16, 2012 at 6:54 AM, Matt Fleming wrote:
>
> At least we now know the problem wasn't caused by a memory map issue,
> just my buggy patch.
>
> Linus, Peter, how should we proceed from here? Since the commit and its
> dependants have been reverted should we punt for now and try again nex
On Sun, 2012-12-16 at 14:25 +0100, Markus Trippelsdorf wrote:
> Matt, your patch fixes the problem for me. Thanks.
That's great! Thanks for testing so quickly.
At least we now know the problem wasn't caused by a memory map issue,
just my buggy patch.
Linus, Peter, how should we proceed from here
On 2012.12.16 at 12:43 +, Matt Fleming wrote:
> On Sat, 2012-12-15 at 17:35 +0100, Markus Trippelsdorf wrote:
> > On 2012.12.15 at 17:33 +0100, Markus Trippelsdorf wrote:
> > > On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
> > > > On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds
> > > > w
On Sat, 2012-12-15 at 15:37 -0800, Linus Torvalds wrote:
> And why do we have to call the get-time calls so early? Couldn't we
> move them later and avoid all the crazy "let's create silly magical
> page tables just for the idiotic EFI problems".
Unfortunately not, because this patch series fixes
On Sat, 2012-12-15 at 17:35 +0100, Markus Trippelsdorf wrote:
> On 2012.12.15 at 17:33 +0100, Markus Trippelsdorf wrote:
> > On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
> > > On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds
> > > wrote:
> > > > I was wrong. It's not the x86 UAPI split, it's
On 12/15/2012 01:37 PM, Dave Jones wrote:
On Sat, Dec 15, 2012 at 11:58:00AM -0800, Linus Torvalds wrote:
> 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 memor
Anybody see anything else?
And why do we have to call the get-time calls so early? Couldn't we
move them later and avoid all the crazy "let's create silly magical
page tables just for the idiotic EFI problems".
We need them anyway... actually the whole point of that patch is to try
to *remov
On Sat, Dec 15, 2012 at 2:05 PM, Yinghai Lu wrote:
> On Sat, Dec 15, 2012 at 1:06 PM, Linus Torvalds
> wrote:
>>
>> I've reverted the commit.
>
> more than that, 3 commits just after that commit should be reverted at
> the same time.
> they all depend on that commit.
Thanks for pointing that ou
On Sat, Dec 15, 2012 at 1:06 PM, Linus Torvalds
wrote:
> On Sat, Dec 15, 2012 at 1:04 PM, Markus Trippelsdorf
> wrote:
>>
>> So I wonder if the following simple patch might be enough?
>> It fixes the issue for me at least.
>
> Not enough.
>
> It presumably fixes the issue for you by hiding the pr
On Sat, Dec 15, 2012 at 11:58:00AM -0800, Linus Torvalds wrote:
> 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.
I wonder if this migh
On 12/15/2012 01:06 PM, Linus Torvalds wrote:
On Sat, Dec 15, 2012 at 1:04 PM, Markus Trippelsdorf
wrote:
So I wonder if the following simple patch might be enough?
It fixes the issue for me at least.
Not enough.
It presumably fixes the issue for you by hiding the problem. But if
you were t
On Sat, Dec 15, 2012 at 1:04 PM, Markus Trippelsdorf
wrote:
>
> So I wonder if the following simple patch might be enough?
> It fixes the issue for me at least.
Not enough.
It presumably fixes the issue for you by hiding the problem. But if
you were to boot a kernel with EFI support, it would re
On 2012.12.15 at 11:58 -0800, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin 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)?
>
>
> but as menti
On 2012.12.15 at 11:58 -0800, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin 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.
>
On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin 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 0x000
On 12/15/2012 10:35 AM, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf
> wrote:
>> On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
>>>
>>> Ho humm. Anybody else see anything strange?
>>
>> Yes. I'm seeing a BUG early during boot on my machine (RIP=NULL):
>>
>> BU
On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf
wrote:
> On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
>>
>> Ho humm. Anybody else see anything strange?
>
> Yes. I'm seeing a BUG early during boot on my machine (RIP=NULL):
>
> BUG: unable to handle kernel NULL pointer dereference at
On 2012.12.15 at 17:33 +0100, Markus Trippelsdorf wrote:
> On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
> > On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds
> > wrote:
> > > I was wrong. It's not the x86 UAPI split, it's the DT pull. More people
> > > added.
> >
> > Looking at the merge (j
On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
> On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds
> wrote:
> > I was wrong. It's not the x86 UAPI split, it's the DT pull. More people
> > added.
>
> Looking at the merge (just in case it could have done something odd),
> I'm starting to worry
On 12/14/2012 05:16 PM, Linus Torvalds wrote:
> On Fri, Dec 14, 2012 at 3:45 PM, David Howells wrote:
>> Linus Torvalds wrote:
>>
>>> Yeah, I think I have most of the x86 stuff merged now (just merged the
>>> EFI and ACPI trees), and at this point it might be worth regenerating
>>> it and getting
On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds
wrote:
> I was wrong. It's not the x86 UAPI split, it's the DT pull. More people added.
Looking at the merge (just in case it could have done something odd),
I'm starting to worry that this is some nasty heisenbug, and my
bisection is not trustworth
I was wrong. It's not the x86 UAPI split, it's the DT pull. More people added.
Grant and Guennadi - it looks like some nasty memory corruption,
because now it didn't cause infinite scrolling, now it caused an oops
in unmap_single_vma() during exit_vmas(). In udevd. Followed by a
hang. I don't know
On Fri, Dec 14, 2012 at 3:45 PM, David Howells wrote:
> Linus Torvalds wrote:
>
>> Yeah, I think I have most of the x86 stuff merged now (just merged the
>> EFI and ACPI trees), and at this point it might be worth regenerating
>> it and getting this over and done with.
>
> Okay, regenerated and p
Linus Torvalds wrote:
> Yeah, I think I have most of the x86 stuff merged now (just merged the
> EFI and ACPI trees), and at this point it might be worth regenerating
> it and getting this over and done with.
Okay, regenerated and pushed.
David
---
The following changes since commit d42b3a2906a
On Wed, Dec 12, 2012 at 3:48 PM, David Howells wrote:
> H. Peter Anvin wrote:
>
>> The following changes since commit 7e5530af11be68f3109672aed59243f82e1272f0:
>>
>> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-12-02
>> 16:39:00 -0800)
>>
>> are available in the git repo
H. Peter Anvin wrote:
> The following changes since commit 7e5530af11be68f3109672aed59243f82e1272f0:
>
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-12-02
> 16:39:00 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/gi
Hi Linus,
This is the arch/x86 portion of David Howell's user API splitup.
Since this is a "build or fail" type patchset, I consider it to be
very low risk.
My test merge shows a single merge conflict in
arch/x86/include/asm/mce.h; the resolution should simply be to remove
the bits from the conf
39 matches
Mail list logo
