Re: [GIT PULL] x86/uapi for 3.8
>>> 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
>>> makes no sense to *copy* PTEs from the kernel and yet leaving the global
>>> bit set, which means there are two ways of fixing it: either sharing
>>> page tables and use the cr4.pge off/on trick that Jan mentioned -- this
>>> would also be my preference -- and the other is to copy the PTEs but
>>> strip the global bit, which has the advantage that the actual kernel
>>> mappings will survive.
>>
>> PTE copying is only one half of it. I think additionally L4 entries
>> get copied for the 1:1 mapping, and you can't strip the global
>> bits there without allocating separate page tables.
>>
>
> The point right now is that it *does* allocate separate page tables, but
My point was that this isn't really the case: You only considered
the ioremap() adjustment of the respective patch, but the first
of the two loops the same patch adds to setup_real_mode() does
in fact share page tables for the identity mapping of RAM.
Matthew - that loop is, btw, off by one, i.e. should be
for (i = 0; i <= pgd_index((max_pfn - 1) << PAGE_SHIFT); i++) {
But of course this, at least for the moment, is only a theoretical
issue.
> doesn't take advantage of it. What I say is I think we should take the
> flush for the advantage of sharing page tables. If we are allocating
> new page tables then we should of course make them non-global.
>
> Do we know how often this gets called? I presume the most common case
> is when we have an EFI RTC? Unless there is a use case where this
> happens a lot sharing seems much easier...
When running on EFI any access to the real time clock will go
that route (i.e. there is no such thing as EFI without EFI RTC).
But then again there of course shouldn't be frequent accesses
to the RTC in the first place (which otherwise would quickly
become a bottleneck with the CMOS RTC as well).
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 17.12.12 at 18:15, H. Peter Anvin h...@linux.intel.com wrote:
On 12/17/2012 09:03 AM, Jan Beulich wrote:
On 17.12.12 at 17:39, H. Peter Anvin h...@linux.intel.com 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 are two ways of fixing it: either sharing
page tables and use the cr4.pge off/on trick that Jan mentioned -- this
would also be my preference -- and the other is to copy the PTEs but
strip the global bit, which has the advantage that the actual kernel
mappings will survive.
PTE copying is only one half of it. I think additionally L4 entries
get copied for the 1:1 mapping, and you can't strip the global
bits there without allocating separate page tables.
The point right now is that it *does* allocate separate page tables, but
My point was that this isn't really the case: You only considered
the ioremap() adjustment of the respective patch, but the first
of the two loops the same patch adds to setup_real_mode() does
in fact share page tables for the identity mapping of RAM.
Matthew - that loop is, btw, off by one, i.e. should be
for (i = 0; i = pgd_index((max_pfn - 1) PAGE_SHIFT); i++) {
But of course this, at least for the moment, is only a theoretical
issue.
doesn't take advantage of it. What I say is I think we should take the
flush for the advantage of sharing page tables. If we are allocating
new page tables then we should of course make them non-global.
Do we know how often this gets called? I presume the most common case
is when we have an EFI RTC? Unless there is a use case where this
happens a lot sharing seems much easier...
When running on EFI any access to the real time clock will go
that route (i.e. there is no such thing as EFI without EFI RTC).
But then again there of course shouldn't be frequent accesses
to the RTC in the first place (which otherwise would quickly
become a bottleneck with the CMOS RTC as well).
Jan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 leaving the global >> bit set, which means there are two ways of fixing it: either sharing >> page tables and use the cr4.pge off/on trick that Jan mentioned -- this >> would also be my preference -- and the other is to copy the PTEs but >> strip the global bit, which has the advantage that the actual kernel >> mappings will survive. > > PTE copying is only one half of it. I think additionally L4 entries > get copied for the 1:1 mapping, and you can't strip the global > bits there without allocating separate page tables. > The point right now is that it *does* allocate separate page tables, but doesn't take advantage of it. What I say is I think we should take the flush for the advantage of sharing page tables. If we are allocating new page tables then we should of course make them non-global. Do we know how often this gets called? I presume the most common case is when we have an EFI RTC? Unless there is a use case where this happens a lot sharing seems much easier... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
>>> 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 are two ways of fixing it: either sharing > page tables and use the cr4.pge off/on trick that Jan mentioned -- this > would also be my preference -- and the other is to copy the PTEs but > strip the global bit, which has the advantage that the actual kernel > mappings will survive. PTE copying is only one half of it. I think additionally L4 entries get copied for the 1:1 mapping, and you can't strip the global bits there without allocating separate page tables. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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_GLOBAL bits? efi_call_virt_{pre,epi}log() only write
>>> CR3 (see 185034e72d591f9465e5e18f937ed642e7ea0070), but
>>> would need to also flip CR4.PGE afaict.
>>
>> Now *this* is the kind of issue that I could easily see causing major
>> corruption, but be subtle enough to not happen reliably. Coming back
>> from the EFI calls (or going into them) with stale TLB contents due to
>> global pages could explain things.
>>
>> Good thinking. That efi call code should use flush_tlb_kernel() (or
>> __flush_tlb_global() if it wants to avoid any paravirtualization
>> stuff) if it has global pages in different places from the normal
>> kernel map. Does it really have that?
>
> I don't see it having such. But I also don't think flush_tlb_kernel()
> is the right mechanism here. I'd rather suggest clearing CR4.PGE in
> the "prelog", an restore it in the epilog. Para-virtual environments
> shouldn't be directly interfacing with EFI runtime code anyway.
>
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 are two ways of fixing it: either sharing
page tables and use the cr4.pge off/on trick that Jan mentioned -- this
would also be my preference -- and the other is to copy the PTEs but
strip the global bit, which has the advantage that the actual kernel
mappings will survive.
One idea in this is to change ioremap() on x86-64 to instead of
allocating address space dynamically to always use the PAGE_OFFSET
mapping address, even for I/O devices. Then the trampoline page table
can simply include two sets of pointers into the kernel page tables --
with, again, the caveat that a global page flush is absolutely mandatory.
Linus, Ingo, do you have any preferences here?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
>>> 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
>> CR3 (see 185034e72d591f9465e5e18f937ed642e7ea0070), but
>> would need to also flip CR4.PGE afaict.
>
> Now *this* is the kind of issue that I could easily see causing major
> corruption, but be subtle enough to not happen reliably. Coming back
> from the EFI calls (or going into them) with stale TLB contents due to
> global pages could explain things.
>
> Good thinking. That efi call code should use flush_tlb_kernel() (or
> __flush_tlb_global() if it wants to avoid any paravirtualization
> stuff) if it has global pages in different places from the normal
> kernel map. Does it really have that?
I don't see it having such. But I also don't think flush_tlb_kernel()
is the right mechanism here. I'd rather suggest clearing CR4.PGE in
the "prelog", an restore it in the epilog. Para-virtual environments
shouldn't be directly interfacing with EFI runtime code anyway.
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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), but
> would need to also flip CR4.PGE afaict.
Now *this* is the kind of issue that I could easily see causing major
corruption, but be subtle enough to not happen reliably. Coming back
from the EFI calls (or going into them) with stale TLB contents due to
global pages could explain things.
Good thinking. That efi call code should use flush_tlb_kernel() (or
__flush_tlb_global() if it wants to avoid any paravirtualization
stuff) if it has global pages in different places from the normal
kernel map. Does it really have that?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
>>> 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):
>>
>> BUG: unable to handle kernel NULL pointer dereference at (null)
>>
>> This is caused by commit 53b87cf088e2 ("x86, mm: Include the
>> entire kernel memory map in trampoline_pgd")
>
> Hmm. That reverts cleanly, and the result boots fine for me. And the
> commit looks like exactly the kind of thing that could result in
> problems with exactly the right memory layout, so it could explain why
> the bisect failed and some kernels randomly worked for me and others
> didn't.
>
> So this at least looks like a very possible candidate.
>
> Does anybody have an explanation for the problem?
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), but
would need to also flip CR4.PGE afaict.
Jan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 12/17/2012 08:00 AM, Jan Beulich wrote:
On 17.12.12 at 16:44, Linus Torvalds torva...@linux-foundation.org wrote:
On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich jbeul...@suse.com 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), but
would need to also flip CR4.PGE afaict.
Now *this* is the kind of issue that I could easily see causing major
corruption, but be subtle enough to not happen reliably. Coming back
from the EFI calls (or going into them) with stale TLB contents due to
global pages could explain things.
Good thinking. That efi call code should use flush_tlb_kernel() (or
__flush_tlb_global() if it wants to avoid any paravirtualization
stuff) if it has global pages in different places from the normal
kernel map. Does it really have that?
I don't see it having such. But I also don't think flush_tlb_kernel()
is the right mechanism here. I'd rather suggest clearing CR4.PGE in
the prelog, an restore it in the epilog. Para-virtual environments
shouldn't be directly interfacing with EFI runtime code anyway.
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 are two ways of fixing it: either sharing
page tables and use the cr4.pge off/on trick that Jan mentioned -- this
would also be my preference -- and the other is to copy the PTEs but
strip the global bit, which has the advantage that the actual kernel
mappings will survive.
One idea in this is to change ioremap() on x86-64 to instead of
allocating address space dynamically to always use the PAGE_OFFSET
mapping address, even for I/O devices. Then the trampoline page table
can simply include two sets of pointers into the kernel page tables --
with, again, the caveat that a global page flush is absolutely mandatory.
Linus, Ingo, do you have any preferences here?
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 17.12.12 at 17:39, H. Peter Anvin h...@linux.intel.com 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 are two ways of fixing it: either sharing page tables and use the cr4.pge off/on trick that Jan mentioned -- this would also be my preference -- and the other is to copy the PTEs but strip the global bit, which has the advantage that the actual kernel mappings will survive. PTE copying is only one half of it. I think additionally L4 entries get copied for the 1:1 mapping, and you can't strip the global bits there without allocating separate page tables. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 12/17/2012 09:03 AM, Jan Beulich wrote: On 17.12.12 at 17:39, H. Peter Anvin h...@linux.intel.com 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 are two ways of fixing it: either sharing page tables and use the cr4.pge off/on trick that Jan mentioned -- this would also be my preference -- and the other is to copy the PTEs but strip the global bit, which has the advantage that the actual kernel mappings will survive. PTE copying is only one half of it. I think additionally L4 entries get copied for the 1:1 mapping, and you can't strip the global bits there without allocating separate page tables. The point right now is that it *does* allocate separate page tables, but doesn't take advantage of it. What I say is I think we should take the flush for the advantage of sharing page tables. If we are allocating new page tables then we should of course make them non-global. Do we know how often this gets called? I presume the most common case is when we have an EFI RTC? Unless there is a use case where this happens a lot sharing seems much easier... -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 15.12.12 at 19:35, Linus Torvalds torva...@linux-foundation.org wrote:
On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf
mar...@trippelsdorf.de 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 (null)
This is caused by commit 53b87cf088e2 (x86, mm: Include the
entire kernel memory map in trampoline_pgd)
Hmm. That reverts cleanly, and the result boots fine for me. And the
commit looks like exactly the kind of thing that could result in
problems with exactly the right memory layout, so it could explain why
the bisect failed and some kernels randomly worked for me and others
didn't.
So this at least looks like a very possible candidate.
Does anybody have an explanation for the problem?
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), but
would need to also flip CR4.PGE afaict.
Jan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich jbeul...@suse.com 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), but
would need to also flip CR4.PGE afaict.
Now *this* is the kind of issue that I could easily see causing major
corruption, but be subtle enough to not happen reliably. Coming back
from the EFI calls (or going into them) with stale TLB contents due to
global pages could explain things.
Good thinking. That efi call code should use flush_tlb_kernel() (or
__flush_tlb_global() if it wants to avoid any paravirtualization
stuff) if it has global pages in different places from the normal
kernel map. Does it really have that?
Linus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 17.12.12 at 16:44, Linus Torvalds torva...@linux-foundation.org wrote:
On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich jbeul...@suse.com 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), but
would need to also flip CR4.PGE afaict.
Now *this* is the kind of issue that I could easily see causing major
corruption, but be subtle enough to not happen reliably. Coming back
from the EFI calls (or going into them) with stale TLB contents due to
global pages could explain things.
Good thinking. That efi call code should use flush_tlb_kernel() (or
__flush_tlb_global() if it wants to avoid any paravirtualization
stuff) if it has global pages in different places from the normal
kernel map. Does it really have that?
I don't see it having such. But I also don't think flush_tlb_kernel()
is the right mechanism here. I'd rather suggest clearing CR4.PGE in
the prelog, an restore it in the epilog. Para-virtual environments
shouldn't be directly interfacing with EFI runtime code anyway.
Jan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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() from udev that I > had before. > > So the patch is still scrogged, and it is *not* ready to even be put > in some "next merge window" pile. Hm, I just double checked my logs and it looks like I've booted the wrong kernel. The new patch fails for me, too. Sorry for the confusion. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 the traces contained any of the new code. The backtrace was something like "find_vma()" called by "do_munmap()". I do have a phone picture of an earlier oops, which was similar. In that case, the oops happened in "unmap_single_vma()", with the call trace being unmap_vmas exit_mmap mmput do_exit do_group_exit get_signal_to_deliver do_signal do_notify_resume retint_signal which looks rather similar: it's some kind of nasty vma list corruption. The main difference being that the exit of the process happened as a result of a signal rather than just a plain exit() system call. Which is probably in turn the result of some corruption of user-space data structures. In some other cases, I've got quickly scrolling stuff that I couldn't even guess at, or just a hung system at early boot. > At this point, I'm wondering if insert_identity_mapping() is trashing > valid mappings. It does feel like *major* data corruption. As in "not just a bitflip or two", but "megabytes of data is wrong". Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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_vma() from udev that I > had before. > > So the patch is still scrogged, and it is *not* ready to even be put > in some "next merge window" pile. 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. At this point, I'm wondering if insert_identity_mapping() is trashing valid mappings. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 udev that I > had before. > > So the patch is still scrogged, and it is *not* ready to even be put > in some "next merge window" pile. > No, we need to get to the bottom with the problem. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 it is *not* ready to even be put in some "next merge window" pile. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 next > merge window? Hmm. Since we're several days away from the merge window closing, I think I can apply your fixed patch and then undo the revert. But I'll need to feel confident that it works for me too, because I absolutely detest having kernels that I can't use for development myself (which is why I _very_ aggressively revert stuff that I notice myself: if it's a problem reported by some random user, I try to give developers time to fix it if they are responding to the problem report, but if it's a problem that means that I can't use the current -git tree myself, I tend to revert much more aggressively). So I'll test it and see, and hope for the best, Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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? Since the commit and its dependants have been reverted should we punt for now and try again next merge window? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 > > > > 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 trustworthy at all. Because the DT pull sure as heck > > > > doesn't look like a likely candidate for anything either. > > > > > > > > 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 (null) > > > > > > This is caused by: > > > > > > commit 53b87cf088e2ea68d7c59619d0214cc15bb76133 > > > Author: Matt Fleming > > > Date: Fri Sep 7 18:23:51 2012 +0100 > > > > > > x86, mm: Include the entire kernel memory map in trampoline_pgd > > > > > > There are various pieces of code in arch/x86 that require a page table > > > with an identity mapping. Make trampoline_pgd a proper kernel page > > > table, it currently only includes the kernel text and module space > > > mapping. > > > > > > One new feature of trampoline_pgd is that it now has mappings for the > > > physical I/O device addresses, which are inserted at ioremap() > > > time. Some broken implementations of EFI firmware require these > > > mappings to always be around. > > > > > > Acked-by: Jan Beulich > > > Signed-off-by: Matt Fleming > > > > > > > Adding Matt to CC. > > Markus, could you please send me your full dmesg, or if possible the > dmesgs from both a working and non-working kernel. > > After looking at your memory map layout, nothing immediately jumps out. > > Could you try this revised patch and see if things work better? It's the > only thing I noticed that looked wrong with the original patch (apart > from the >512G ram bug that Yinghai pointed out). Matt, your patch fixes the problem for me. Thanks. -- Markus Linux version 3.7.0-08451-g2b83188-dirty (markus@x4) (gcc version 4.8.0 20121214 (experimental) (GCC) ) #143 SMP Sat Dec 15 22:34:34 CET 2012 Command line: root=PARTUUID=1E3384D0-CAE6-41BB-8CD6-4F640164EFD7 init=/sbin/minit fbcon=rotate:3 drm_kms_helper.poll=0 quiet KERNEL supported cpus: AMD AuthenticAMD e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0100-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e6000-0x000f] reserved BIOS-e820: [mem 0x0010-0xdfe8] usable BIOS-e820: [mem 0xdfe9-0xdfea7fff] ACPI data BIOS-e820: [mem 0xdfea8000-0xdfec] ACPI NVS BIOS-e820: [mem 0xdfed-0xdfef] reserved BIOS-e820: [mem 0xfff0-0x] reserved BIOS-e820: [mem 0x0001-0x00021fff] usable NX (Execute Disable) protection: active DMI present. DMI: System manufacturer System Product Name/M4A78T-E, BIOS 350304/13/2011 e820: update [mem 0x-0x] usable ==> reserved e820: remove [mem 0x000a-0x000f] usable e820: last_pfn = 0x22 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-E uncachable F-F write-protect MTRR variable ranges enabled: 0 base mask 8000 write-back 1 base 8000 mask C000 write-back 2 base C000 mask E000 write-back 3 base F000 mask F800 write-combining 4 disabled 5 disabled 6 disabled 7 disabled TOM2: 00022000 aka 8704M x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 e820: last_pfn = 0xdfe90 max_arch_pfn = 0x4 initial memory mapped: [mem 0x-0x1fff] Base memory trampoline at [88099000] 99000 size 24576 Using GB pages for direct mapping init_memory_mapping: [mem 0x-0xdfe8] [mem 0x-0xbfff] page 1G [mem 0xc000-0xdfdf] page 2M [mem 0xdfe0-0xdfe8] page 4k kernel direct mapping tables up to 0xdfe8 @ [mem 0x1fffd000-0x1fff] init_memory_mapping: [mem 0x1-0x21fff] [mem 0x1-0x1] page 1G [mem 0x2-0x21fff] page 2M kernel direct mapping tables up to 0x21fff @ [mem 0xdfe8e000-0xdfe8] ACPI: RSDP 000fb880 00024 (v02 ACPIAM) ACPI: XSDT dfe90100 0005C (v01 041311 XSDT1656 20110413 MSFT 0097) ACPI: FACP dfe90290 000F4 (v03 041311 FACP1656 20110413 MSFT 0097) ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length:
Re: [GIT PULL] x86/uapi for 3.8
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 the case where some ASUS EFI machines ignore parts of the memory map that we invalidate with SetVirtualAddressMap() - so the firmware is accessing mappings for devices after we explicitly tell it they're no longer valid. It's possible to trigger this broken behaviour at whatever point we interact with the firmware. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 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 trustworthy at all. Because the DT pull sure as heck
> > > doesn't look like a likely candidate for anything either.
> > >
> > > 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 (null)
> >
> > This is caused by:
> >
> > commit 53b87cf088e2ea68d7c59619d0214cc15bb76133
> > Author: Matt Fleming
> > Date: Fri Sep 7 18:23:51 2012 +0100
> >
> > x86, mm: Include the entire kernel memory map in trampoline_pgd
> >
> > There are various pieces of code in arch/x86 that require a page table
> > with an identity mapping. Make trampoline_pgd a proper kernel page
> > table, it currently only includes the kernel text and module space
> > mapping.
> >
> > One new feature of trampoline_pgd is that it now has mappings for the
> > physical I/O device addresses, which are inserted at ioremap()
> > time. Some broken implementations of EFI firmware require these
> > mappings to always be around.
> >
> > Acked-by: Jan Beulich
> > Signed-off-by: Matt Fleming
> >
>
> Adding Matt to CC.
Markus, could you please send me your full dmesg, or if possible the
dmesgs from both a working and non-working kernel.
After looking at your memory map layout, nothing immediately jumps out.
Could you try this revised patch and see if things work better? It's the
only thing I noticed that looked wrong with the original patch (apart
from the >512G ram bug that Yinghai pointed out).
---
>From dbc2a0bc1f3ea6c4df591e691916801e5aac85e3 Mon Sep 17 00:00:00 2001
From: Matt Fleming
Date: Fri, 7 Sep 2012 18:23:51 +0100
Subject: [PATCH] x86, mm: Include the entire kernel memory map in
trampoline_pgd
There are various pieces of code in arch/x86 that require a page table
with an identity mapping. Make trampoline_pgd a proper kernel page
table, it currently only includes the kernel text and module space
mapping.
One new feature of trampoline_pgd is that it now has mappings for the
physical I/O device addresses, which are inserted at ioremap()
time. Some broken implementations of EFI firmware require these
mappings to always be around.
Acked-by: Jan Beulich
Signed-off-by: Matt Fleming
---
v2: Ensure we update 'paddr' as we work our way through the pgtables.
arch/x86/mm/init_64.c| 9 +++-
arch/x86/mm/ioremap.c| 111 +++
arch/x86/realmode/init.c | 17 +++-
3 files changed, 134 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 2b6b4a3..fd4404f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -108,13 +108,13 @@ void sync_global_pgds(unsigned long start, unsigned long
end)
for (address = start; address <= end; address += PGDIR_SIZE) {
const pgd_t *pgd_ref = pgd_offset_k(address);
struct page *page;
+ pgd_t *pgd;
if (pgd_none(*pgd_ref))
continue;
spin_lock(_lock);
list_for_each_entry(page, _list, lru) {
- pgd_t *pgd;
spinlock_t *pgt_lock;
pgd = (pgd_t *)page_address(page) + pgd_index(address);
@@ -130,6 +130,13 @@ void sync_global_pgds(unsigned long start, unsigned long
end)
spin_unlock(pgt_lock);
}
+
+ pgd = __va(real_mode_header->trampoline_pgd);
+ pgd += pgd_index(address);
+
+ if (pgd_none(*pgd))
+ set_pgd(pgd, *pgd_ref);
+
spin_unlock(_lock);
}
}
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 78fe3f1..353b64b 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -50,6 +50,113 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long
size,
return err;
}
+#ifdef CONFIG_X86_64
+static void ident_pte_range(unsigned long paddr, unsigned long vaddr,
+ pmd_t *ppmd, pmd_t *vpmd, unsigned long end)
+{
+ pte_t *ppte = pte_offset_kernel(ppmd, paddr);
+ pte_t *vpte = pte_offset_kernel(vpmd, vaddr);
+
+ do {
+ set_pte(ppte, *vpte);
+ } while (ppte++, vpte++, vaddr += PAGE_SIZE, vaddr != end);
+}
+
+static int ident_pmd_range(unsigned long paddr, unsigned long vaddr,
+
Re: [GIT PULL] x86/uapi for 3.8
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
torva...@linux-foundation.org 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 trustworthy at all. Because the DT pull sure as heck
doesn't look like a likely candidate for anything either.
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 (null)
This is caused by:
commit 53b87cf088e2ea68d7c59619d0214cc15bb76133
Author: Matt Fleming matt.flem...@intel.com
Date: Fri Sep 7 18:23:51 2012 +0100
x86, mm: Include the entire kernel memory map in trampoline_pgd
There are various pieces of code in arch/x86 that require a page table
with an identity mapping. Make trampoline_pgd a proper kernel page
table, it currently only includes the kernel text and module space
mapping.
One new feature of trampoline_pgd is that it now has mappings for the
physical I/O device addresses, which are inserted at ioremap()
time. Some broken implementations of EFI firmware require these
mappings to always be around.
Acked-by: Jan Beulich jbeul...@suse.com
Signed-off-by: Matt Fleming matt.flem...@intel.com
Adding Matt to CC.
Markus, could you please send me your full dmesg, or if possible the
dmesgs from both a working and non-working kernel.
After looking at your memory map layout, nothing immediately jumps out.
Could you try this revised patch and see if things work better? It's the
only thing I noticed that looked wrong with the original patch (apart
from the 512G ram bug that Yinghai pointed out).
---
From dbc2a0bc1f3ea6c4df591e691916801e5aac85e3 Mon Sep 17 00:00:00 2001
From: Matt Fleming matt.flem...@intel.com
Date: Fri, 7 Sep 2012 18:23:51 +0100
Subject: [PATCH] x86, mm: Include the entire kernel memory map in
trampoline_pgd
There are various pieces of code in arch/x86 that require a page table
with an identity mapping. Make trampoline_pgd a proper kernel page
table, it currently only includes the kernel text and module space
mapping.
One new feature of trampoline_pgd is that it now has mappings for the
physical I/O device addresses, which are inserted at ioremap()
time. Some broken implementations of EFI firmware require these
mappings to always be around.
Acked-by: Jan Beulich jbeul...@suse.com
Signed-off-by: Matt Fleming matt.flem...@intel.com
---
v2: Ensure we update 'paddr' as we work our way through the pgtables.
arch/x86/mm/init_64.c| 9 +++-
arch/x86/mm/ioremap.c| 111 +++
arch/x86/realmode/init.c | 17 +++-
3 files changed, 134 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 2b6b4a3..fd4404f 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -108,13 +108,13 @@ void sync_global_pgds(unsigned long start, unsigned long
end)
for (address = start; address = end; address += PGDIR_SIZE) {
const pgd_t *pgd_ref = pgd_offset_k(address);
struct page *page;
+ pgd_t *pgd;
if (pgd_none(*pgd_ref))
continue;
spin_lock(pgd_lock);
list_for_each_entry(page, pgd_list, lru) {
- pgd_t *pgd;
spinlock_t *pgt_lock;
pgd = (pgd_t *)page_address(page) + pgd_index(address);
@@ -130,6 +130,13 @@ void sync_global_pgds(unsigned long start, unsigned long
end)
spin_unlock(pgt_lock);
}
+
+ pgd = __va(real_mode_header-trampoline_pgd);
+ pgd += pgd_index(address);
+
+ if (pgd_none(*pgd))
+ set_pgd(pgd, *pgd_ref);
+
spin_unlock(pgd_lock);
}
}
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 78fe3f1..353b64b 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -50,6 +50,113 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long
size,
return err;
}
+#ifdef CONFIG_X86_64
+static void ident_pte_range(unsigned long paddr, unsigned long vaddr,
+ pmd_t *ppmd, pmd_t *vpmd, unsigned long end)
+{
+ pte_t *ppte = pte_offset_kernel(ppmd, paddr);
+ pte_t *vpte = pte_offset_kernel(vpmd, vaddr);
+
+ do {
+ set_pte(ppte, *vpte);
+ } while (ppte++, vpte++, vaddr += PAGE_SIZE, vaddr != end);
+}
+
+static int
Re: [GIT PULL] x86/uapi for 3.8
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 the case where some ASUS EFI machines ignore parts of the memory map that we invalidate with SetVirtualAddressMap() - so the firmware is accessing mappings for devices after we explicitly tell it they're no longer valid. It's possible to trigger this broken behaviour at whatever point we interact with the firmware. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 torva...@linux-foundation.org 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 trustworthy at all. Because the DT pull sure as heck doesn't look like a likely candidate for anything either. 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 (null) This is caused by: commit 53b87cf088e2ea68d7c59619d0214cc15bb76133 Author: Matt Fleming matt.flem...@intel.com Date: Fri Sep 7 18:23:51 2012 +0100 x86, mm: Include the entire kernel memory map in trampoline_pgd There are various pieces of code in arch/x86 that require a page table with an identity mapping. Make trampoline_pgd a proper kernel page table, it currently only includes the kernel text and module space mapping. One new feature of trampoline_pgd is that it now has mappings for the physical I/O device addresses, which are inserted at ioremap() time. Some broken implementations of EFI firmware require these mappings to always be around. Acked-by: Jan Beulich jbeul...@suse.com Signed-off-by: Matt Fleming matt.flem...@intel.com Adding Matt to CC. Markus, could you please send me your full dmesg, or if possible the dmesgs from both a working and non-working kernel. After looking at your memory map layout, nothing immediately jumps out. Could you try this revised patch and see if things work better? It's the only thing I noticed that looked wrong with the original patch (apart from the 512G ram bug that Yinghai pointed out). Matt, your patch fixes the problem for me. Thanks. -- Markus Linux version 3.7.0-08451-g2b83188-dirty (markus@x4) (gcc version 4.8.0 20121214 (experimental) (GCC) ) #143 SMP Sat Dec 15 22:34:34 CET 2012 Command line: root=PARTUUID=1E3384D0-CAE6-41BB-8CD6-4F640164EFD7 init=/sbin/minit fbcon=rotate:3 drm_kms_helper.poll=0 quiet KERNEL supported cpus: AMD AuthenticAMD e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0100-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e6000-0x000f] reserved BIOS-e820: [mem 0x0010-0xdfe8] usable BIOS-e820: [mem 0xdfe9-0xdfea7fff] ACPI data BIOS-e820: [mem 0xdfea8000-0xdfec] ACPI NVS BIOS-e820: [mem 0xdfed-0xdfef] reserved BIOS-e820: [mem 0xfff0-0x] reserved BIOS-e820: [mem 0x0001-0x00021fff] usable NX (Execute Disable) protection: active DMI present. DMI: System manufacturer System Product Name/M4A78T-E, BIOS 350304/13/2011 e820: update [mem 0x-0x] usable == reserved e820: remove [mem 0x000a-0x000f] usable e820: last_pfn = 0x22 max_arch_pfn = 0x4 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-E uncachable F-F write-protect MTRR variable ranges enabled: 0 base mask 8000 write-back 1 base 8000 mask C000 write-back 2 base C000 mask E000 write-back 3 base F000 mask F800 write-combining 4 disabled 5 disabled 6 disabled 7 disabled TOM2: 00022000 aka 8704M x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 e820: last_pfn = 0xdfe90 max_arch_pfn = 0x4 initial memory mapped: [mem 0x-0x1fff] Base memory trampoline at [88099000] 99000 size 24576 Using GB pages for direct mapping init_memory_mapping: [mem 0x-0xdfe8] [mem 0x-0xbfff] page 1G [mem 0xc000-0xdfdf] page 2M [mem 0xdfe0-0xdfe8] page 4k kernel direct mapping tables up to 0xdfe8 @ [mem 0x1fffd000-0x1fff] init_memory_mapping: [mem 0x1-0x21fff] [mem 0x1-0x1] page 1G [mem 0x2-0x21fff] page 2M kernel direct mapping tables up to 0x21fff @ [mem 0xdfe8e000-0xdfe8] ACPI: RSDP 000fb880 00024 (v02 ACPIAM) ACPI: XSDT dfe90100 0005C (v01 041311 XSDT1656 20110413 MSFT 0097) ACPI: FACP dfe90290 000F4 (v03 041311 FACP1656 20110413 MSFT 0097) ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length: 0x/0x1 (20121018/tbfadt-598) ACPI: DSDT
Re: [GIT PULL] x86/uapi for 3.8
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? Since the commit and its dependants have been reverted should we punt for now and try again next merge window? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sun, Dec 16, 2012 at 6:54 AM, Matt Fleming matt.flem...@intel.com 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 next merge window? Hmm. Since we're several days away from the merge window closing, I think I can apply your fixed patch and then undo the revert. But I'll need to feel confident that it works for me too, because I absolutely detest having kernels that I can't use for development myself (which is why I _very_ aggressively revert stuff that I notice myself: if it's a problem reported by some random user, I try to give developers time to fix it if they are responding to the problem report, but if it's a problem that means that I can't use the current -git tree myself, I tend to revert much more aggressively). So I'll test it and see, and hope for the best, Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds torva...@linux-foundation.org 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 it is *not* ready to even be put in some next merge window pile. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 12/16/2012 02:07 PM, Linus Torvalds wrote: On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds torva...@linux-foundation.org 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 it is *not* ready to even be put in some next merge window pile. No, we need to get to the bottom with the problem. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sun, 2012-12-16 at 14:07 -0800, Linus Torvalds wrote: On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds torva...@linux-foundation.org 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 it is *not* ready to even be put in some next merge window pile. 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. At this point, I'm wondering if insert_identity_mapping() is trashing valid mappings. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sun, Dec 16, 2012 at 2:40 PM, Matt Fleming matt.flem...@intel.com 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 the traces contained any of the new code. The backtrace was something like find_vma() called by do_munmap(). I do have a phone picture of an earlier oops, which was similar. In that case, the oops happened in unmap_single_vma(), with the call trace being unmap_vmas exit_mmap mmput do_exit do_group_exit get_signal_to_deliver do_signal do_notify_resume retint_signal which looks rather similar: it's some kind of nasty vma list corruption. The main difference being that the exit of the process happened as a result of a signal rather than just a plain exit() system call. Which is probably in turn the result of some corruption of user-space data structures. In some other cases, I've got quickly scrolling stuff that I couldn't even guess at, or just a hung system at early boot. At this point, I'm wondering if insert_identity_mapping() is trashing valid mappings. It does feel like *major* data corruption. As in not just a bitflip or two, but megabytes of data is wrong. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 2012.12.16 at 14:07 -0800, Linus Torvalds wrote: On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds torva...@linux-foundation.org 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 it is *not* ready to even be put in some next merge window pile. Hm, I just double checked my logs and it looks like I've booted the wrong kernel. The new patch fails for me, too. Sorry for the confusion. -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 memory map except indirectly. I wonder if this might explain the XFS corruption I've been seeing the last couple days. Won't be able to get at the affected laptop until Monday to find out.. It seems somewhat unlikely, but not implausible, since the trampoline page table is only in use for very brief moments and usually not very often at all, but if it is just completely screwed and we do fandango on memory... yes we could have problems. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 *remove* silly magical page tables just for EFI and use another set of silly magical page tables we need anyway (for S3 resume, SMP bootup and so on.) Reducing the sheer number of silly magical page tables has been a priority for some time -- I want to get it down to one if we can. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 out, and just to make sure I verified that on my Macbook Air which does use EFI. It was broken by the single revert, and fixed by the additional three reverts. Sadly: > and first checking of that commit, it would have problem with system > more than 512g ... That particular bug isn't the cause for my non-EFI problems, since I don't have that kind of memory.. So there is something else going on in addition to the bug you found. But good eye. 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". And while I'm asking, why the f*ck did Intel do that crazy EFI thing in the first place again? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 problem. But if > you were to boot a kernel with EFI support, it would re-surface. > Including in any distro kernel that obviously will include EFI support > in order to handle the generic case. > > 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. and first checking of that commit, it would have problem with system more than 512g ... static int insert_identity_mapping(resource_size_t paddr, unsigned long vaddr, unsigned long size) ... pgd_t *vpgd, *ppgd; ppgd = __va(real_mode_header->trampoline_pgd) + pgd_index(paddr); it missed one . we should use ppgd = (pgd_t *)__va(real_mode_header->trampoline_pgd) + pgd_index(paddr); Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 might explain the XFS corruption I've been seeing the last couple days. Won't be able to get at the affected laptop until Monday to find out.. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 to boot a kernel with EFI support, it would re-surface. Including in any distro kernel that obviously will include EFI support in order to handle the generic case. I've reverted the commit. Right... we'll work on fixing it properly. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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-surface. Including in any distro kernel that obviously will include EFI support in order to handle the generic case. I've reverted the commit. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 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.
The commit message says that only some broken implementations of EFI
firmware require the mapping for the physical I/O device addresses.
So I wonder if the following simple patch might be enough?
It fixes the issue for me at least.
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index e190f7b..402e4ca 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -50,7 +50,7 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long
size,
return err;
}
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_EFI
static void ident_pte_range(unsigned long paddr, unsigned long vaddr,
pmd_t *ppmd, pmd_t *vpmd, unsigned long end)
{
--
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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. > > e820: BIOS-provided physical RAM map: > BIOS-e820: [mem 0x-0x0009e7ff] usable > BIOS-e820: [mem 0x0009e800-0x0009] reserved > BIOS-e820: [mem 0x000e4000-0x000f] reserved > BIOS-e820: [mem 0x0010-0xbdc6] usable > BIOS-e820: [mem 0xbdc7-0xbdc87fff] ACPI data > BIOS-e820: [mem 0xbdc88000-0xbdcdbfff] ACPI NVS > BIOS-e820: [mem 0xbdcdc000-0xbfff] reserved > BIOS-e820: [mem 0xfee0-0xfee00fff] reserved > BIOS-e820: [mem 0xff80-0x] reserved > BIOS-e820: [mem 0x0001-0x0001fbff] usable > BIOS-e820: [mem 0x0001fc00-0x0001] reserved > BIOS-e820: [mem 0x0002-0x00023fff] 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 0x0100-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e6000-0x000f] reserved BIOS-e820: [mem 0x0010-0xdfe8] usable BIOS-e820: [mem 0xdfe9-0xdfea7fff] ACPI data BIOS-e820: [mem 0xdfea8000-0xdfec] ACPI NVS BIOS-e820: [mem 0xdfed-0xdfef] reserved BIOS-e820: [mem 0xfff0-0x] reserved BIOS-e820: [mem 0x0001-0x00021fff] usable -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 0x-0x0009e7ff] usable BIOS-e820: [mem 0x0009e800-0x0009] reserved BIOS-e820: [mem 0x000e4000-0x000f] reserved BIOS-e820: [mem 0x0010-0xbdc6] usable BIOS-e820: [mem 0xbdc7-0xbdc87fff] ACPI data BIOS-e820: [mem 0xbdc88000-0xbdcdbfff] ACPI NVS BIOS-e820: [mem 0xbdcdc000-0xbfff] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xff80-0x] reserved BIOS-e820: [mem 0x0001-0x0001fbff] usable BIOS-e820: [mem 0x0001fc00-0x0001] reserved BIOS-e820: [mem 0x0002-0x00023fff] 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? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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):
>>
>> BUG: unable to handle kernel NULL pointer dereference at (null)
>>
>> This is caused by commit 53b87cf088e2 ("x86, mm: Include the
>> entire kernel memory map in trampoline_pgd")
>
> Hmm. That reverts cleanly, and the result boots fine for me. And the
> commit looks like exactly the kind of thing that could result in
> problems with exactly the right memory layout, so it could explain why
> the bisect failed and some kernels randomly worked for me and others
> didn't.
>
> So this at least looks like a very possible candidate.
>
> Does anybody have an explanation for the problem?
>
> Btw. the machine in question does not have EFI, and is a bog-standard
> PC (DMI string: "P7H57D-V EVO, BIOS 0999 01/19/2010")
>
> Matt? Jan?
>
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)?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 (null)
>
> This is caused by commit 53b87cf088e2 ("x86, mm: Include the
> entire kernel memory map in trampoline_pgd")
Hmm. That reverts cleanly, and the result boots fine for me. And the
commit looks like exactly the kind of thing that could result in
problems with exactly the right memory layout, so it could explain why
the bisect failed and some kernels randomly worked for me and others
didn't.
So this at least looks like a very possible candidate.
Does anybody have an explanation for the problem?
Btw. the machine in question does not have EFI, and is a bog-standard
PC (DMI string: "P7H57D-V EVO, BIOS 0999 01/19/2010")
Matt? Jan?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 (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 trustworthy at all. Because the DT pull sure as heck > > doesn't look like a likely candidate for anything either. > > > > 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 (null) > > This is caused by: > > commit 53b87cf088e2ea68d7c59619d0214cc15bb76133 > Author: Matt Fleming > Date: Fri Sep 7 18:23:51 2012 +0100 > > x86, mm: Include the entire kernel memory map in trampoline_pgd > > There are various pieces of code in arch/x86 that require a page table > with an identity mapping. Make trampoline_pgd a proper kernel page > table, it currently only includes the kernel text and module space > mapping. > > One new feature of trampoline_pgd is that it now has mappings for the > physical I/O device addresses, which are inserted at ioremap() > time. Some broken implementations of EFI firmware require these > mappings to always be around. > > Acked-by: Jan Beulich > Signed-off-by: Matt Fleming > Adding Matt to CC. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 that this is some nasty heisenbug, and my > bisection is not trustworthy at all. Because the DT pull sure as heck > doesn't look like a likely candidate for anything either. > > 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 (null) This is caused by: commit 53b87cf088e2ea68d7c59619d0214cc15bb76133 Author: Matt Fleming Date: Fri Sep 7 18:23:51 2012 +0100 x86, mm: Include the entire kernel memory map in trampoline_pgd There are various pieces of code in arch/x86 that require a page table with an identity mapping. Make trampoline_pgd a proper kernel page table, it currently only includes the kernel text and module space mapping. One new feature of trampoline_pgd is that it now has mappings for the physical I/O device addresses, which are inserted at ioremap() time. Some broken implementations of EFI firmware require these mappings to always be around. Acked-by: Jan Beulich Signed-off-by: Matt Fleming -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote: On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds torva...@linux-foundation.org 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 trustworthy at all. Because the DT pull sure as heck doesn't look like a likely candidate for anything either. 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 (null) This is caused by: commit 53b87cf088e2ea68d7c59619d0214cc15bb76133 Author: Matt Fleming matt.flem...@intel.com Date: Fri Sep 7 18:23:51 2012 +0100 x86, mm: Include the entire kernel memory map in trampoline_pgd There are various pieces of code in arch/x86 that require a page table with an identity mapping. Make trampoline_pgd a proper kernel page table, it currently only includes the kernel text and module space mapping. One new feature of trampoline_pgd is that it now has mappings for the physical I/O device addresses, which are inserted at ioremap() time. Some broken implementations of EFI firmware require these mappings to always be around. Acked-by: Jan Beulich jbeul...@suse.com Signed-off-by: Matt Fleming matt.flem...@intel.com -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 torva...@linux-foundation.org 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 trustworthy at all. Because the DT pull sure as heck doesn't look like a likely candidate for anything either. 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 (null) This is caused by: commit 53b87cf088e2ea68d7c59619d0214cc15bb76133 Author: Matt Fleming matt.flem...@intel.com Date: Fri Sep 7 18:23:51 2012 +0100 x86, mm: Include the entire kernel memory map in trampoline_pgd There are various pieces of code in arch/x86 that require a page table with an identity mapping. Make trampoline_pgd a proper kernel page table, it currently only includes the kernel text and module space mapping. One new feature of trampoline_pgd is that it now has mappings for the physical I/O device addresses, which are inserted at ioremap() time. Some broken implementations of EFI firmware require these mappings to always be around. Acked-by: Jan Beulich jbeul...@suse.com Signed-off-by: Matt Fleming matt.flem...@intel.com Adding Matt to CC. -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf mar...@trippelsdorf.de 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 (null) This is caused by commit 53b87cf088e2 (x86, mm: Include the entire kernel memory map in trampoline_pgd) Hmm. That reverts cleanly, and the result boots fine for me. And the commit looks like exactly the kind of thing that could result in problems with exactly the right memory layout, so it could explain why the bisect failed and some kernels randomly worked for me and others didn't. So this at least looks like a very possible candidate. Does anybody have an explanation for the problem? Btw. the machine in question does not have EFI, and is a bog-standard PC (DMI string: P7H57D-V EVO, BIOS 0999 01/19/2010) Matt? Jan? Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 12/15/2012 10:35 AM, Linus Torvalds wrote: On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf mar...@trippelsdorf.de 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 (null) This is caused by commit 53b87cf088e2 (x86, mm: Include the entire kernel memory map in trampoline_pgd) Hmm. That reverts cleanly, and the result boots fine for me. And the commit looks like exactly the kind of thing that could result in problems with exactly the right memory layout, so it could explain why the bisect failed and some kernels randomly worked for me and others didn't. So this at least looks like a very possible candidate. Does anybody have an explanation for the problem? Btw. the machine in question does not have EFI, and is a bog-standard PC (DMI string: P7H57D-V EVO, BIOS 0999 01/19/2010) Matt? Jan? 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)? -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin h...@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 0x-0x0009e7ff] usable BIOS-e820: [mem 0x0009e800-0x0009] reserved BIOS-e820: [mem 0x000e4000-0x000f] reserved BIOS-e820: [mem 0x0010-0xbdc6] usable BIOS-e820: [mem 0xbdc7-0xbdc87fff] ACPI data BIOS-e820: [mem 0xbdc88000-0xbdcdbfff] ACPI NVS BIOS-e820: [mem 0xbdcdc000-0xbfff] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xff80-0x] reserved BIOS-e820: [mem 0x0001-0x0001fbff] usable BIOS-e820: [mem 0x0001fc00-0x0001] reserved BIOS-e820: [mem 0x0002-0x00023fff] 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? Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 2012.12.15 at 11:58 -0800, Linus Torvalds wrote: On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin h...@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 0x-0x0009e7ff] usable BIOS-e820: [mem 0x0009e800-0x0009] reserved BIOS-e820: [mem 0x000e4000-0x000f] reserved BIOS-e820: [mem 0x0010-0xbdc6] usable BIOS-e820: [mem 0xbdc7-0xbdc87fff] ACPI data BIOS-e820: [mem 0xbdc88000-0xbdcdbfff] ACPI NVS BIOS-e820: [mem 0xbdcdc000-0xbfff] reserved BIOS-e820: [mem 0xfee0-0xfee00fff] reserved BIOS-e820: [mem 0xff80-0x] reserved BIOS-e820: [mem 0x0001-0x0001fbff] usable BIOS-e820: [mem 0x0001fc00-0x0001] reserved BIOS-e820: [mem 0x0002-0x00023fff] 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 0x0100-0x0009fbff] usable BIOS-e820: [mem 0x0009fc00-0x0009] reserved BIOS-e820: [mem 0x000e6000-0x000f] reserved BIOS-e820: [mem 0x0010-0xdfe8] usable BIOS-e820: [mem 0xdfe9-0xdfea7fff] ACPI data BIOS-e820: [mem 0xdfea8000-0xdfec] ACPI NVS BIOS-e820: [mem 0xdfed-0xdfef] reserved BIOS-e820: [mem 0xfff0-0x] reserved BIOS-e820: [mem 0x0001-0x00021fff] usable -- Markus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 2012.12.15 at 11:58 -0800, Linus Torvalds wrote:
On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin h...@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)?
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.
The commit message says that only some broken implementations of EFI
firmware require the mapping for the physical I/O device addresses.
So I wonder if the following simple patch might be enough?
It fixes the issue for me at least.
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index e190f7b..402e4ca 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -50,7 +50,7 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long
size,
return err;
}
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_EFI
static void ident_pte_range(unsigned long paddr, unsigned long vaddr,
pmd_t *ppmd, pmd_t *vpmd, unsigned long end)
{
--
Markus
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sat, Dec 15, 2012 at 1:04 PM, Markus Trippelsdorf mar...@trippelsdorf.de 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-surface. Including in any distro kernel that obviously will include EFI support in order to handle the generic case. I've reverted the commit. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 12/15/2012 01:06 PM, Linus Torvalds wrote: On Sat, Dec 15, 2012 at 1:04 PM, Markus Trippelsdorf mar...@trippelsdorf.de 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-surface. Including in any distro kernel that obviously will include EFI support in order to handle the generic case. I've reverted the commit. Right... we'll work on fixing it properly. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 might explain the XFS corruption I've been seeing the last couple days. Won't be able to get at the affected laptop until Monday to find out.. Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sat, Dec 15, 2012 at 1:06 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sat, Dec 15, 2012 at 1:04 PM, Markus Trippelsdorf mar...@trippelsdorf.de 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-surface. Including in any distro kernel that obviously will include EFI support in order to handle the generic case. 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. and first checking of that commit, it would have problem with system more than 512g ... static int insert_identity_mapping(resource_size_t paddr, unsigned long vaddr, unsigned long size) ... pgd_t *vpgd, *ppgd; ppgd = __va(real_mode_header-trampoline_pgd) + pgd_index(paddr); it missed one . we should use ppgd = (pgd_t *)__va(real_mode_header-trampoline_pgd) + pgd_index(paddr); Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Sat, Dec 15, 2012 at 2:05 PM, Yinghai Lu ying...@kernel.org wrote: On Sat, Dec 15, 2012 at 1:06 PM, Linus Torvalds torva...@linux-foundation.org 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 out, and just to make sure I verified that on my Macbook Air which does use EFI. It was broken by the single revert, and fixed by the additional three reverts. Sadly: and first checking of that commit, it would have problem with system more than 512g ... That particular bug isn't the cause for my non-EFI problems, since I don't have that kind of memory.. So there is something else going on in addition to the bug you found. But good eye. 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. And while I'm asking, why the f*ck did Intel do that crazy EFI thing in the first place again? Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 *remove* silly magical page tables just for EFI and use another set of silly magical page tables we need anyway (for S3 resume, SMP bootup and so on.) Reducing the sheer number of silly magical page tables has been a priority for some time -- I want to get it down to one if we can. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 memory map except indirectly. I wonder if this might explain the XFS corruption I've been seeing the last couple days. Won't be able to get at the affected laptop until Monday to find out.. It seems somewhat unlikely, but not implausible, since the trampoline page table is only in use for very brief moments and usually not very often at all, but if it is just completely screwed and we do fandango on memory... yes we could have problems. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 this over and done with. >> >> Okay, regenerated and pushed. > > Ugh. This doesn't seem to work for me at all. It causes infinite > scrolling of some text that I have no idea about. > > I started bisecting (because I thought it might be something else and > I hadn't booted after every pull), but by now the only thing I have > left is ARM and a couple of tiny OF patches .. and the x86 UAPI split. > > The split *should* have been safe, since it's mostly a "compile or > not" thing like Peter said, but we had similar problems on other > architectures, when things compiled but didn't actually work due to > missing #define's and #ifdef handling. Things like > architecture-specific macros that have default versions available when > the macro is missing etc. > > Now, maybe it's some of the other remaining commits after all, but > from where I am in the bisection it really looks like the uapi patch > is the most likely culprit. So I thought I'd let people know... > Hmmm... I can't reproduce your failure. Could you send me your config and a hint about what hardware you're seeing this on? That might help chase this down. Macs in particular are EFI machines, except they hide OF snippets inside ACPI (I kid you not.) All of that creates interesting cross-dependencies. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 trustworthy at all. Because the DT pull sure as heck doesn't look like a likely candidate for anything either. Ho humm. Anybody else see anything strange? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 *which* commit it is yet, but commit 4939e27d46fe
("Merge tag 'devicetree-for-linus' ...") is bad, and the previous
merge (the ARM mvebu one is fine).
I'll bisect to the commit, but wanted to let David off the hook, and
put the DT people on the hook. Maybe it's some odd merge artifact,
although I don't think that one had any conflicts at all.
Linus
On Fri, Dec 14, 2012 at 5:16 PM, Linus Torvalds
wrote:
>
> Ugh. This doesn't seem to work for me at all. It causes infinite
> scrolling of some text that I have no idea about.
>
> I started bisecting (because I thought it might be something else and
> I hadn't booted after every pull), but by now the only thing I have
> left is ARM and a couple of tiny OF patches .. and the x86 UAPI split.
>
> The split *should* have been safe, since it's mostly a "compile or
> not" thing like Peter said, but we had similar problems on other
> architectures, when things compiled but didn't actually work due to
> missing #define's and #ifdef handling. Things like
> architecture-specific macros that have default versions available when
> the macro is missing etc.
>
> Now, maybe it's some of the other remaining commits after all, but
> from where I am in the bisection it really looks like the uapi patch
> is the most likely culprit. So I thought I'd let people know...
>
> Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 pushed. Ugh. This doesn't seem to work for me at all. It causes infinite scrolling of some text that I have no idea about. I started bisecting (because I thought it might be something else and I hadn't booted after every pull), but by now the only thing I have left is ARM and a couple of tiny OF patches .. and the x86 UAPI split. The split *should* have been safe, since it's mostly a "compile or not" thing like Peter said, but we had similar problems on other architectures, when things compiled but didn't actually work due to missing #define's and #ifdef handling. Things like architecture-specific macros that have default versions available when the macro is missing etc. Now, maybe it's some of the other remaining commits after all, but from where I am in the bisection it really looks like the uapi patch is the most likely culprit. So I thought I'd let people know... Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 d42b3a2906a10b732ea7d7f849d49be79d242ef0:
Merge branch 'core-efi-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2012-12-14 10:08:40
-0800)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-x86-20121214
for you to fetch changes up to af170c5061dd78512c469e6e2d211980cdb2c193:
UAPI: (Scripted) Disintegrate arch/x86/include/asm (2012-12-14 22:37:13 +)
UAPI disintegration 2012-12-14
David Howells (1):
UAPI: (Scripted) Disintegrate arch/x86/include/asm
arch/x86/include/asm/Kbuild | 26 ---
arch/x86/include/asm/boot.h | 9 +-
arch/x86/include/asm/debugreg.h | 79 +---
arch/x86/include/asm/e820.h | 74 +---
arch/x86/include/asm/hw_breakpoint.h | 5 +-
arch/x86/include/asm/ist.h| 17 +-
arch/x86/include/asm/kvm_para.h | 99 +-
arch/x86/include/asm/mce.h| 119 +---
arch/x86/include/asm/msr.h| 11 +-
arch/x86/include/asm/mtrr.h | 93 +
arch/x86/include/asm/posix_types.h| 10 -
arch/x86/include/asm/processor-flags.h| 97 +-
arch/x86/include/asm/ptrace.h | 75 +---
arch/x86/include/asm/setup.h | 5 +-
arch/x86/include/asm/sigcontext.h | 216 +
arch/x86/include/asm/signal.h | 140 +-
arch/x86/include/asm/svm.h| 132 +
arch/x86/include/asm/unistd.h | 14 +-
arch/x86/include/asm/vm86.h | 128 +
arch/x86/include/asm/vmx.h| 89 +
arch/x86/include/asm/vsyscall.h | 16 +-
arch/x86/include/uapi/asm/Kbuild | 58 ++
arch/x86/include/{ => uapi}/asm/a.out.h | 0
arch/x86/include/{ => uapi}/asm/auxvec.h | 0
arch/x86/include/{ => uapi}/asm/bitsperlong.h | 0
arch/x86/include/uapi/asm/boot.h | 10 +
arch/x86/include/{ => uapi}/asm/bootparam.h | 0
arch/x86/include/{ => uapi}/asm/byteorder.h | 0
arch/x86/include/uapi/asm/debugreg.h | 80
arch/x86/include/uapi/asm/e820.h | 75
arch/x86/include/{ => uapi}/asm/errno.h | 0
arch/x86/include/{ => uapi}/asm/fcntl.h | 0
arch/x86/include/{ => uapi}/asm/hyperv.h | 0
arch/x86/include/{ => uapi}/asm/ioctl.h | 0
arch/x86/include/{ => uapi}/asm/ioctls.h | 0
arch/x86/include/{ => uapi}/asm/ipcbuf.h | 0
arch/x86/include/uapi/asm/ist.h | 29 +++
arch/x86/include/{ => uapi}/asm/kvm.h | 0
arch/x86/include/uapi/asm/kvm_para.h | 100 ++
arch/x86/include/{ => uapi}/asm/ldt.h | 0
arch/x86/include/uapi/asm/mce.h | 121
arch/x86/include/{ => uapi}/asm/mman.h| 0
arch/x86/include/{ => uapi}/asm/msgbuf.h | 0
arch/x86/include/{ => uapi}/asm/msr-index.h | 0
arch/x86/include/uapi/asm/msr.h | 15 ++
arch/x86/include/uapi/asm/mtrr.h | 117
arch/x86/include/{ => uapi}/asm/param.h | 0
arch/x86/include/{ => uapi}/asm/perf_regs.h | 0
arch/x86/include/{ => uapi}/asm/poll.h| 0
arch/x86/include/uapi/asm/posix_types.h | 9 +
arch/x86/include/{ => uapi}/asm/posix_types_32.h | 0
arch/x86/include/{ => uapi}/asm/posix_types_64.h | 0
arch/x86/include/{ => uapi}/asm/posix_types_x32.h | 0
arch/x86/include/{ => uapi}/asm/prctl.h | 0
arch/x86/include/uapi/asm/processor-flags.h | 99 ++
arch/x86/include/{ => uapi}/asm/ptrace-abi.h | 0
arch/x86/include/uapi/asm/ptrace.h| 78
arch/x86/include/{ => uapi}/asm/resource.h| 0
arch/x86/include/{ => uapi}/asm/sembuf.h | 0
arch/x86/include/{ => uapi}/asm/shmbuf.h | 0
arch/x86/include/uapi/asm/sigcontext.h| 221 ++
arch/x86/include/{ => uapi}/asm/sigcontext32.h| 0
arch/x86/include/{ => uapi}/asm/siginfo.h | 0
arch/x86/include/uapi/asm/signal.h| 145 ++
arch/x86/include/{ => uapi}/asm/socket.h | 0
Re: [GIT PULL] x86/uapi for 3.8
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 repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git >> x86-uapi-for-linus > > Unfortunately, that is broken by Al Viro's mass signalling changes. I've > regenerated it based on Linus's current master. Pull request below. > > The same merge conflict with tip/master still exists, I imagine, due to the > changes in tipbot for asm/mce.h, so if tip/master is merged first, then it > might be worth me regenerating my changes. 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. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Wed, Dec 12, 2012 at 3:48 PM, David Howells dhowe...@redhat.com wrote: H. Peter Anvin h...@linux.intel.com 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/git/tip/tip.git x86-uapi-for-linus Unfortunately, that is broken by Al Viro's mass signalling changes. I've regenerated it based on Linus's current master. Pull request below. The same merge conflict with tip/master still exists, I imagine, due to the changes in tipbot for asm/mce.h, so if tip/master is merged first, then it might be worth me regenerating my changes. 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. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
Linus Torvalds torva...@linux-foundation.org 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 d42b3a2906a10b732ea7d7f849d49be79d242ef0:
Merge branch 'core-efi-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip (2012-12-14 10:08:40
-0800)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-x86-20121214
for you to fetch changes up to af170c5061dd78512c469e6e2d211980cdb2c193:
UAPI: (Scripted) Disintegrate arch/x86/include/asm (2012-12-14 22:37:13 +)
UAPI disintegration 2012-12-14
David Howells (1):
UAPI: (Scripted) Disintegrate arch/x86/include/asm
arch/x86/include/asm/Kbuild | 26 ---
arch/x86/include/asm/boot.h | 9 +-
arch/x86/include/asm/debugreg.h | 79 +---
arch/x86/include/asm/e820.h | 74 +---
arch/x86/include/asm/hw_breakpoint.h | 5 +-
arch/x86/include/asm/ist.h| 17 +-
arch/x86/include/asm/kvm_para.h | 99 +-
arch/x86/include/asm/mce.h| 119 +---
arch/x86/include/asm/msr.h| 11 +-
arch/x86/include/asm/mtrr.h | 93 +
arch/x86/include/asm/posix_types.h| 10 -
arch/x86/include/asm/processor-flags.h| 97 +-
arch/x86/include/asm/ptrace.h | 75 +---
arch/x86/include/asm/setup.h | 5 +-
arch/x86/include/asm/sigcontext.h | 216 +
arch/x86/include/asm/signal.h | 140 +-
arch/x86/include/asm/svm.h| 132 +
arch/x86/include/asm/unistd.h | 14 +-
arch/x86/include/asm/vm86.h | 128 +
arch/x86/include/asm/vmx.h| 89 +
arch/x86/include/asm/vsyscall.h | 16 +-
arch/x86/include/uapi/asm/Kbuild | 58 ++
arch/x86/include/{ = uapi}/asm/a.out.h | 0
arch/x86/include/{ = uapi}/asm/auxvec.h | 0
arch/x86/include/{ = uapi}/asm/bitsperlong.h | 0
arch/x86/include/uapi/asm/boot.h | 10 +
arch/x86/include/{ = uapi}/asm/bootparam.h | 0
arch/x86/include/{ = uapi}/asm/byteorder.h | 0
arch/x86/include/uapi/asm/debugreg.h | 80
arch/x86/include/uapi/asm/e820.h | 75
arch/x86/include/{ = uapi}/asm/errno.h | 0
arch/x86/include/{ = uapi}/asm/fcntl.h | 0
arch/x86/include/{ = uapi}/asm/hyperv.h | 0
arch/x86/include/{ = uapi}/asm/ioctl.h | 0
arch/x86/include/{ = uapi}/asm/ioctls.h | 0
arch/x86/include/{ = uapi}/asm/ipcbuf.h | 0
arch/x86/include/uapi/asm/ist.h | 29 +++
arch/x86/include/{ = uapi}/asm/kvm.h | 0
arch/x86/include/uapi/asm/kvm_para.h | 100 ++
arch/x86/include/{ = uapi}/asm/ldt.h | 0
arch/x86/include/uapi/asm/mce.h | 121
arch/x86/include/{ = uapi}/asm/mman.h| 0
arch/x86/include/{ = uapi}/asm/msgbuf.h | 0
arch/x86/include/{ = uapi}/asm/msr-index.h | 0
arch/x86/include/uapi/asm/msr.h | 15 ++
arch/x86/include/uapi/asm/mtrr.h | 117
arch/x86/include/{ = uapi}/asm/param.h | 0
arch/x86/include/{ = uapi}/asm/perf_regs.h | 0
arch/x86/include/{ = uapi}/asm/poll.h| 0
arch/x86/include/uapi/asm/posix_types.h | 9 +
arch/x86/include/{ = uapi}/asm/posix_types_32.h | 0
arch/x86/include/{ = uapi}/asm/posix_types_64.h | 0
arch/x86/include/{ = uapi}/asm/posix_types_x32.h | 0
arch/x86/include/{ = uapi}/asm/prctl.h | 0
arch/x86/include/uapi/asm/processor-flags.h | 99 ++
arch/x86/include/{ = uapi}/asm/ptrace-abi.h | 0
arch/x86/include/uapi/asm/ptrace.h| 78
arch/x86/include/{ = uapi}/asm/resource.h| 0
arch/x86/include/{ = uapi}/asm/sembuf.h | 0
arch/x86/include/{ = uapi}/asm/shmbuf.h | 0
arch/x86/include/uapi/asm/sigcontext.h| 221 ++
arch/x86/include/{ = uapi}/asm/sigcontext32.h| 0
arch/x86/include/{ = uapi}/asm/siginfo.h | 0
arch/x86/include/uapi/asm/signal.h| 145 ++
arch/x86/include/{ = uapi}/asm/socket.h | 0
Re: [GIT PULL] x86/uapi for 3.8
On Fri, Dec 14, 2012 at 3:45 PM, David Howells dhowe...@redhat.com wrote: Linus Torvalds torva...@linux-foundation.org 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. Ugh. This doesn't seem to work for me at all. It causes infinite scrolling of some text that I have no idea about. I started bisecting (because I thought it might be something else and I hadn't booted after every pull), but by now the only thing I have left is ARM and a couple of tiny OF patches .. and the x86 UAPI split. The split *should* have been safe, since it's mostly a compile or not thing like Peter said, but we had similar problems on other architectures, when things compiled but didn't actually work due to missing #define's and #ifdef handling. Things like architecture-specific macros that have default versions available when the macro is missing etc. Now, maybe it's some of the other remaining commits after all, but from where I am in the bisection it really looks like the uapi patch is the most likely culprit. So I thought I'd let people know... Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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 *which* commit it is yet, but commit 4939e27d46fe (Merge tag 'devicetree-for-linus' ...) is bad, and the previous merge (the ARM mvebu one is fine). I'll bisect to the commit, but wanted to let David off the hook, and put the DT people on the hook. Maybe it's some odd merge artifact, although I don't think that one had any conflicts at all. Linus On Fri, Dec 14, 2012 at 5:16 PM, Linus Torvalds torva...@linux-foundation.org wrote: Ugh. This doesn't seem to work for me at all. It causes infinite scrolling of some text that I have no idea about. I started bisecting (because I thought it might be something else and I hadn't booted after every pull), but by now the only thing I have left is ARM and a couple of tiny OF patches .. and the x86 UAPI split. The split *should* have been safe, since it's mostly a compile or not thing like Peter said, but we had similar problems on other architectures, when things compiled but didn't actually work due to missing #define's and #ifdef handling. Things like architecture-specific macros that have default versions available when the macro is missing etc. Now, maybe it's some of the other remaining commits after all, but from where I am in the bisection it really looks like the uapi patch is the most likely culprit. So I thought I'd let people know... Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds torva...@linux-foundation.org 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 trustworthy at all. Because the DT pull sure as heck doesn't look like a likely candidate for anything either. Ho humm. Anybody else see anything strange? Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
On 12/14/2012 05:16 PM, Linus Torvalds wrote: On Fri, Dec 14, 2012 at 3:45 PM, David Howells dhowe...@redhat.com wrote: Linus Torvalds torva...@linux-foundation.org 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. Ugh. This doesn't seem to work for me at all. It causes infinite scrolling of some text that I have no idea about. I started bisecting (because I thought it might be something else and I hadn't booted after every pull), but by now the only thing I have left is ARM and a couple of tiny OF patches .. and the x86 UAPI split. The split *should* have been safe, since it's mostly a compile or not thing like Peter said, but we had similar problems on other architectures, when things compiled but didn't actually work due to missing #define's and #ifdef handling. Things like architecture-specific macros that have default versions available when the macro is missing etc. Now, maybe it's some of the other remaining commits after all, but from where I am in the bisection it really looks like the uapi patch is the most likely culprit. So I thought I'd let people know... Hmmm... I can't reproduce your failure. Could you send me your config and a hint about what hardware you're seeing this on? That might help chase this down. Macs in particular are EFI machines, except they hide OF snippets inside ACPI (I kid you not.) All of that creates interesting cross-dependencies. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86/uapi for 3.8
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/git/tip/tip.git x86-uapi-for-linus
Unfortunately, that is broken by Al Viro's mass signalling changes. I've
regenerated it based on Linus's current master. Pull request below.
The same merge conflict with tip/master still exists, I imagine, due to the
changes in tipbot for asm/mce.h, so if tip/master is merged first, then it
might be worth me regenerating my changes.
Should it go via tipbot?
David
---
The following changes since commit 9977d9b379cb77e0f67bd6f4563618106e58e11d:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal (2012-12-12 12:22:13
-0800)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-x86-20121212
for you to fetch changes up to c12519530533e2bdd93e5753bcd565fda35f3df0:
UAPI: (Scripted) Disintegrate arch/x86/include/asm (2012-12-12 22:58:24 +)
UAPI disintegration 2012-12-12
David Howells (1):
UAPI: (Scripted) Disintegrate arch/x86/include/asm
arch/x86/include/asm/Kbuild | 26 ---
arch/x86/include/asm/boot.h | 9 +-
arch/x86/include/asm/debugreg.h | 79 +---
arch/x86/include/asm/e820.h | 74 +---
arch/x86/include/asm/hw_breakpoint.h | 5 +-
arch/x86/include/asm/ist.h| 17 +-
arch/x86/include/asm/kvm_para.h | 99 +-
arch/x86/include/asm/mce.h| 119 +---
arch/x86/include/asm/msr.h| 11 +-
arch/x86/include/asm/mtrr.h | 93 +
arch/x86/include/asm/posix_types.h| 10 -
arch/x86/include/asm/processor-flags.h| 97 +-
arch/x86/include/asm/ptrace.h | 75 +---
arch/x86/include/asm/setup.h | 5 +-
arch/x86/include/asm/sigcontext.h | 216 +
arch/x86/include/asm/signal.h | 140 +-
arch/x86/include/asm/svm.h| 132 +
arch/x86/include/asm/unistd.h | 14 +-
arch/x86/include/asm/vm86.h | 128 +
arch/x86/include/asm/vmx.h| 89 +
arch/x86/include/asm/vsyscall.h | 16 +-
arch/x86/include/uapi/asm/Kbuild | 58 ++
arch/x86/include/{ => uapi}/asm/a.out.h | 0
arch/x86/include/{ => uapi}/asm/auxvec.h | 0
arch/x86/include/{ => uapi}/asm/bitsperlong.h | 0
arch/x86/include/uapi/asm/boot.h | 10 +
arch/x86/include/{ => uapi}/asm/bootparam.h | 0
arch/x86/include/{ => uapi}/asm/byteorder.h | 0
arch/x86/include/uapi/asm/debugreg.h | 80
arch/x86/include/uapi/asm/e820.h | 75
arch/x86/include/{ => uapi}/asm/errno.h | 0
arch/x86/include/{ => uapi}/asm/fcntl.h | 0
arch/x86/include/{ => uapi}/asm/hyperv.h | 0
arch/x86/include/{ => uapi}/asm/ioctl.h | 0
arch/x86/include/{ => uapi}/asm/ioctls.h | 0
arch/x86/include/{ => uapi}/asm/ipcbuf.h | 0
arch/x86/include/uapi/asm/ist.h | 29 +++
arch/x86/include/{ => uapi}/asm/kvm.h | 0
arch/x86/include/uapi/asm/kvm_para.h | 100 ++
arch/x86/include/{ => uapi}/asm/ldt.h | 0
arch/x86/include/uapi/asm/mce.h | 121
arch/x86/include/{ => uapi}/asm/mman.h| 0
arch/x86/include/{ => uapi}/asm/msgbuf.h | 0
arch/x86/include/{ => uapi}/asm/msr-index.h | 0
arch/x86/include/uapi/asm/msr.h | 15 ++
arch/x86/include/uapi/asm/mtrr.h | 117
arch/x86/include/{ => uapi}/asm/param.h | 0
arch/x86/include/{ => uapi}/asm/perf_regs.h | 0
arch/x86/include/{ => uapi}/asm/poll.h| 0
arch/x86/include/uapi/asm/posix_types.h | 9 +
arch/x86/include/{ => uapi}/asm/posix_types_32.h | 0
arch/x86/include/{ => uapi}/asm/posix_types_64.h | 0
arch/x86/include/{ => uapi}/asm/posix_types_x32.h | 0
arch/x86/include/{ => uapi}/asm/prctl.h | 0
arch/x86/include/uapi/asm/processor-flags.h | 99 ++
arch/x86/include/{ => uapi}/asm/ptrace-abi.h | 0
arch/x86/include/uapi/asm/ptrace.h| 78
arch/x86/include/{ => uapi}/asm/resource.h
[GIT PULL] x86/uapi for 3.8
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 conflicted merge that are already in
arch/x86/include/uapi/asm/mce.h.
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/git/tip/tip.git x86-uapi-for-linus
David Howells (1):
UAPI: (Scripted) Disintegrate arch/x86/include/asm
arch/x86/include/asm/Kbuild | 26 ---
arch/x86/include/asm/boot.h |9 +-
arch/x86/include/asm/debugreg.h | 79 +
arch/x86/include/asm/e820.h | 74 +---
arch/x86/include/asm/hw_breakpoint.h |5 +-
arch/x86/include/asm/ist.h| 17 +--
arch/x86/include/asm/kvm_para.h | 99 +-
arch/x86/include/asm/mce.h| 119 +---
arch/x86/include/asm/msr.h| 11 +-
arch/x86/include/asm/mtrr.h | 93 +-
arch/x86/include/asm/posix_types.h| 10 -
arch/x86/include/asm/processor-flags.h| 97 +-
arch/x86/include/asm/ptrace.h | 75 +---
arch/x86/include/asm/setup.h |5 +-
arch/x86/include/asm/sigcontext.h | 216 +
arch/x86/include/asm/signal.h | 140 +-
arch/x86/include/asm/svm.h| 132 +
arch/x86/include/asm/unistd.h | 14 +--
arch/x86/include/asm/vm86.h | 128 +
arch/x86/include/asm/vmx.h| 89 +
arch/x86/include/asm/vsyscall.h | 16 +--
arch/x86/include/uapi/asm/Kbuild | 58 ++
arch/x86/include/{ => uapi}/asm/a.out.h |0
arch/x86/include/{ => uapi}/asm/auxvec.h |0
arch/x86/include/{ => uapi}/asm/bitsperlong.h |0
arch/x86/include/uapi/asm/boot.h | 10 +
arch/x86/include/{ => uapi}/asm/bootparam.h |0
arch/x86/include/{ => uapi}/asm/byteorder.h |0
arch/x86/include/uapi/asm/debugreg.h | 80
arch/x86/include/uapi/asm/e820.h | 75 +++
arch/x86/include/{ => uapi}/asm/errno.h |0
arch/x86/include/{ => uapi}/asm/fcntl.h |0
arch/x86/include/{ => uapi}/asm/hyperv.h |0
arch/x86/include/{ => uapi}/asm/ioctl.h |0
arch/x86/include/{ => uapi}/asm/ioctls.h |0
arch/x86/include/{ => uapi}/asm/ipcbuf.h |0
arch/x86/include/uapi/asm/ist.h | 29 +++
arch/x86/include/{ => uapi}/asm/kvm.h |0
arch/x86/include/uapi/asm/kvm_para.h | 100 ++
arch/x86/include/{ => uapi}/asm/ldt.h |0
arch/x86/include/uapi/asm/mce.h | 121 +++
arch/x86/include/{ => uapi}/asm/mman.h|0
arch/x86/include/{ => uapi}/asm/msgbuf.h |0
arch/x86/include/{ => uapi}/asm/msr-index.h |0
arch/x86/include/uapi/asm/msr.h | 15 ++
arch/x86/include/uapi/asm/mtrr.h | 117 +++
arch/x86/include/{ => uapi}/asm/param.h |0
arch/x86/include/{ => uapi}/asm/perf_regs.h |0
arch/x86/include/{ => uapi}/asm/poll.h|0
arch/x86/include/uapi/asm/posix_types.h |9 +
arch/x86/include/{ => uapi}/asm/posix_types_32.h |0
arch/x86/include/{ => uapi}/asm/posix_types_64.h |0
arch/x86/include/{ => uapi}/asm/posix_types_x32.h |0
arch/x86/include/{ => uapi}/asm/prctl.h |0
arch/x86/include/uapi/asm/processor-flags.h | 99 +
arch/x86/include/{ => uapi}/asm/ptrace-abi.h |0
arch/x86/include/uapi/asm/ptrace.h| 78
arch/x86/include/{ => uapi}/asm/resource.h|0
arch/x86/include/{ => uapi}/asm/sembuf.h |0
arch/x86/include/{ => uapi}/asm/shmbuf.h |0
arch/x86/include/uapi/asm/sigcontext.h| 221 +
arch/x86/include/{ => uapi}/asm/sigcontext32.h|0
arch/x86/include/{ => uapi}/asm/siginfo.h |0
arch/x86/include/uapi/asm/signal.h| 145 ++
arch/x86/include/{ => uapi}/asm/socket.h |0
arch/x86/include/{ => uapi}/asm/sockios.h |0
arch/x86/include/{ => uapi}/asm/stat.h|0
arch/x86/include/{ => uapi}/asm/statfs.h |0
[GIT PULL] x86/uapi for 3.8
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 conflicted merge that are already in
arch/x86/include/uapi/asm/mce.h.
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/git/tip/tip.git x86-uapi-for-linus
David Howells (1):
UAPI: (Scripted) Disintegrate arch/x86/include/asm
arch/x86/include/asm/Kbuild | 26 ---
arch/x86/include/asm/boot.h |9 +-
arch/x86/include/asm/debugreg.h | 79 +
arch/x86/include/asm/e820.h | 74 +---
arch/x86/include/asm/hw_breakpoint.h |5 +-
arch/x86/include/asm/ist.h| 17 +--
arch/x86/include/asm/kvm_para.h | 99 +-
arch/x86/include/asm/mce.h| 119 +---
arch/x86/include/asm/msr.h| 11 +-
arch/x86/include/asm/mtrr.h | 93 +-
arch/x86/include/asm/posix_types.h| 10 -
arch/x86/include/asm/processor-flags.h| 97 +-
arch/x86/include/asm/ptrace.h | 75 +---
arch/x86/include/asm/setup.h |5 +-
arch/x86/include/asm/sigcontext.h | 216 +
arch/x86/include/asm/signal.h | 140 +-
arch/x86/include/asm/svm.h| 132 +
arch/x86/include/asm/unistd.h | 14 +--
arch/x86/include/asm/vm86.h | 128 +
arch/x86/include/asm/vmx.h| 89 +
arch/x86/include/asm/vsyscall.h | 16 +--
arch/x86/include/uapi/asm/Kbuild | 58 ++
arch/x86/include/{ = uapi}/asm/a.out.h |0
arch/x86/include/{ = uapi}/asm/auxvec.h |0
arch/x86/include/{ = uapi}/asm/bitsperlong.h |0
arch/x86/include/uapi/asm/boot.h | 10 +
arch/x86/include/{ = uapi}/asm/bootparam.h |0
arch/x86/include/{ = uapi}/asm/byteorder.h |0
arch/x86/include/uapi/asm/debugreg.h | 80
arch/x86/include/uapi/asm/e820.h | 75 +++
arch/x86/include/{ = uapi}/asm/errno.h |0
arch/x86/include/{ = uapi}/asm/fcntl.h |0
arch/x86/include/{ = uapi}/asm/hyperv.h |0
arch/x86/include/{ = uapi}/asm/ioctl.h |0
arch/x86/include/{ = uapi}/asm/ioctls.h |0
arch/x86/include/{ = uapi}/asm/ipcbuf.h |0
arch/x86/include/uapi/asm/ist.h | 29 +++
arch/x86/include/{ = uapi}/asm/kvm.h |0
arch/x86/include/uapi/asm/kvm_para.h | 100 ++
arch/x86/include/{ = uapi}/asm/ldt.h |0
arch/x86/include/uapi/asm/mce.h | 121 +++
arch/x86/include/{ = uapi}/asm/mman.h|0
arch/x86/include/{ = uapi}/asm/msgbuf.h |0
arch/x86/include/{ = uapi}/asm/msr-index.h |0
arch/x86/include/uapi/asm/msr.h | 15 ++
arch/x86/include/uapi/asm/mtrr.h | 117 +++
arch/x86/include/{ = uapi}/asm/param.h |0
arch/x86/include/{ = uapi}/asm/perf_regs.h |0
arch/x86/include/{ = uapi}/asm/poll.h|0
arch/x86/include/uapi/asm/posix_types.h |9 +
arch/x86/include/{ = uapi}/asm/posix_types_32.h |0
arch/x86/include/{ = uapi}/asm/posix_types_64.h |0
arch/x86/include/{ = uapi}/asm/posix_types_x32.h |0
arch/x86/include/{ = uapi}/asm/prctl.h |0
arch/x86/include/uapi/asm/processor-flags.h | 99 +
arch/x86/include/{ = uapi}/asm/ptrace-abi.h |0
arch/x86/include/uapi/asm/ptrace.h| 78
arch/x86/include/{ = uapi}/asm/resource.h|0
arch/x86/include/{ = uapi}/asm/sembuf.h |0
arch/x86/include/{ = uapi}/asm/shmbuf.h |0
arch/x86/include/uapi/asm/sigcontext.h| 221 +
arch/x86/include/{ = uapi}/asm/sigcontext32.h|0
arch/x86/include/{ = uapi}/asm/siginfo.h |0
arch/x86/include/uapi/asm/signal.h| 145 ++
arch/x86/include/{ = uapi}/asm/socket.h |0
arch/x86/include/{ = uapi}/asm/sockios.h |0
arch/x86/include/{ = uapi}/asm/stat.h|0
arch/x86/include/{ = uapi}/asm/statfs.h |0
arch/x86/include/uapi/asm/svm.h
Re: [GIT PULL] x86/uapi for 3.8
H. Peter Anvin h...@linux.intel.com 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/git/tip/tip.git x86-uapi-for-linus
Unfortunately, that is broken by Al Viro's mass signalling changes. I've
regenerated it based on Linus's current master. Pull request below.
The same merge conflict with tip/master still exists, I imagine, due to the
changes in tipbot for asm/mce.h, so if tip/master is merged first, then it
might be worth me regenerating my changes.
Should it go via tipbot?
David
---
The following changes since commit 9977d9b379cb77e0f67bd6f4563618106e58e11d:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal (2012-12-12 12:22:13
-0800)
are available in the git repository at:
git://git.infradead.org/users/dhowells/linux-headers.git
tags/disintegrate-x86-20121212
for you to fetch changes up to c12519530533e2bdd93e5753bcd565fda35f3df0:
UAPI: (Scripted) Disintegrate arch/x86/include/asm (2012-12-12 22:58:24 +)
UAPI disintegration 2012-12-12
David Howells (1):
UAPI: (Scripted) Disintegrate arch/x86/include/asm
arch/x86/include/asm/Kbuild | 26 ---
arch/x86/include/asm/boot.h | 9 +-
arch/x86/include/asm/debugreg.h | 79 +---
arch/x86/include/asm/e820.h | 74 +---
arch/x86/include/asm/hw_breakpoint.h | 5 +-
arch/x86/include/asm/ist.h| 17 +-
arch/x86/include/asm/kvm_para.h | 99 +-
arch/x86/include/asm/mce.h| 119 +---
arch/x86/include/asm/msr.h| 11 +-
arch/x86/include/asm/mtrr.h | 93 +
arch/x86/include/asm/posix_types.h| 10 -
arch/x86/include/asm/processor-flags.h| 97 +-
arch/x86/include/asm/ptrace.h | 75 +---
arch/x86/include/asm/setup.h | 5 +-
arch/x86/include/asm/sigcontext.h | 216 +
arch/x86/include/asm/signal.h | 140 +-
arch/x86/include/asm/svm.h| 132 +
arch/x86/include/asm/unistd.h | 14 +-
arch/x86/include/asm/vm86.h | 128 +
arch/x86/include/asm/vmx.h| 89 +
arch/x86/include/asm/vsyscall.h | 16 +-
arch/x86/include/uapi/asm/Kbuild | 58 ++
arch/x86/include/{ = uapi}/asm/a.out.h | 0
arch/x86/include/{ = uapi}/asm/auxvec.h | 0
arch/x86/include/{ = uapi}/asm/bitsperlong.h | 0
arch/x86/include/uapi/asm/boot.h | 10 +
arch/x86/include/{ = uapi}/asm/bootparam.h | 0
arch/x86/include/{ = uapi}/asm/byteorder.h | 0
arch/x86/include/uapi/asm/debugreg.h | 80
arch/x86/include/uapi/asm/e820.h | 75
arch/x86/include/{ = uapi}/asm/errno.h | 0
arch/x86/include/{ = uapi}/asm/fcntl.h | 0
arch/x86/include/{ = uapi}/asm/hyperv.h | 0
arch/x86/include/{ = uapi}/asm/ioctl.h | 0
arch/x86/include/{ = uapi}/asm/ioctls.h | 0
arch/x86/include/{ = uapi}/asm/ipcbuf.h | 0
arch/x86/include/uapi/asm/ist.h | 29 +++
arch/x86/include/{ = uapi}/asm/kvm.h | 0
arch/x86/include/uapi/asm/kvm_para.h | 100 ++
arch/x86/include/{ = uapi}/asm/ldt.h | 0
arch/x86/include/uapi/asm/mce.h | 121
arch/x86/include/{ = uapi}/asm/mman.h| 0
arch/x86/include/{ = uapi}/asm/msgbuf.h | 0
arch/x86/include/{ = uapi}/asm/msr-index.h | 0
arch/x86/include/uapi/asm/msr.h | 15 ++
arch/x86/include/uapi/asm/mtrr.h | 117
arch/x86/include/{ = uapi}/asm/param.h | 0
arch/x86/include/{ = uapi}/asm/perf_regs.h | 0
arch/x86/include/{ = uapi}/asm/poll.h| 0
arch/x86/include/uapi/asm/posix_types.h | 9 +
arch/x86/include/{ = uapi}/asm/posix_types_32.h | 0
arch/x86/include/{ = uapi}/asm/posix_types_64.h | 0
arch/x86/include/{ = uapi}/asm/posix_types_x32.h | 0
arch/x86/include/{ = uapi}/asm/prctl.h | 0
arch/x86/include/uapi/asm/processor-flags.h | 99 ++
arch/x86/include/{ = uapi}/asm/ptrace-abi.h | 0
arch/x86/include/uapi/asm/ptrace.h| 78
arch/x86/include/{ = uapi}/asm/resource.h| 0
