[GIT PULL] x86/uapi for 3.8

[GIT PULL] x86/uapi for 3.8

[H. Peter Anvin]

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                   |  132 ++++++++++++
 arch/x86/include/{ => uapi}/asm/swab.h            |    0
 arch/x86/include/{ => uapi}/asm/termbits.h        |    0
 arch/x86/include/{ => uapi}/asm/termios.h         |    0
 arch/x86/include/{ => uapi}/asm/types.h           |    0
 arch/x86/include/{ => uapi}/asm/ucontext.h        |    0
 arch/x86/include/uapi/asm/unistd.h                |   17 ++
 arch/x86/include/uapi/asm/vm86.h                  |  129 ++++++++++++
 arch/x86/include/uapi/asm/vmx.h                   |  109 ++++++++++
 arch/x86/include/uapi/asm/vsyscall.h              |   17 ++
 78 files changed, 1587 insertions(+), 1428 deletions(-)
 rename arch/x86/include/{ => uapi}/asm/a.out.h (100%)
 rename arch/x86/include/{ => uapi}/asm/auxvec.h (100%)
 rename arch/x86/include/{ => uapi}/asm/bitsperlong.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/boot.h
 rename arch/x86/include/{ => uapi}/asm/bootparam.h (100%)
 rename arch/x86/include/{ => uapi}/asm/byteorder.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/debugreg.h
 create mode 100644 arch/x86/include/uapi/asm/e820.h
 rename arch/x86/include/{ => uapi}/asm/errno.h (100%)
 rename arch/x86/include/{ => uapi}/asm/fcntl.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/hw_breakpoint.h
 rename arch/x86/include/{ => uapi}/asm/hyperv.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ioctl.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ioctls.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ipcbuf.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/ist.h
 rename arch/x86/include/{ => uapi}/asm/kvm.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/kvm_para.h
 rename arch/x86/include/{ => uapi}/asm/ldt.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/mce.h
 rename arch/x86/include/{ => uapi}/asm/mman.h (100%)
 rename arch/x86/include/{ => uapi}/asm/msgbuf.h (100%)
 rename arch/x86/include/{ => uapi}/asm/msr-index.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/msr.h
 create mode 100644 arch/x86/include/uapi/asm/mtrr.h
 rename arch/x86/include/{ => uapi}/asm/param.h (100%)
 rename arch/x86/include/{ => uapi}/asm/perf_regs.h (100%)
 rename arch/x86/include/{ => uapi}/asm/poll.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/posix_types.h
 rename arch/x86/include/{ => uapi}/asm/posix_types_32.h (100%)
 rename arch/x86/include/{ => uapi}/asm/posix_types_64.h (100%)
 rename arch/x86/include/{ => uapi}/asm/posix_types_x32.h (100%)
 rename arch/x86/include/{ => uapi}/asm/prctl.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/processor-flags.h
 rename arch/x86/include/{ => uapi}/asm/ptrace-abi.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/ptrace.h
 rename arch/x86/include/{ => uapi}/asm/resource.h (100%)
 rename arch/x86/include/{ => uapi}/asm/sembuf.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/setup.h
 rename arch/x86/include/{ => uapi}/asm/shmbuf.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/sigcontext.h
 rename arch/x86/include/{ => uapi}/asm/sigcontext32.h (100%)
 rename arch/x86/include/{ => uapi}/asm/siginfo.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/signal.h
 rename arch/x86/include/{ => uapi}/asm/socket.h (100%)
 rename arch/x86/include/{ => uapi}/asm/sockios.h (100%)
 rename arch/x86/include/{ => uapi}/asm/stat.h (100%)
 rename arch/x86/include/{ => uapi}/asm/statfs.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/svm.h
 rename arch/x86/include/{ => uapi}/asm/swab.h (100%)
 rename arch/x86/include/{ => uapi}/asm/termbits.h (100%)
 rename arch/x86/include/{ => uapi}/asm/termios.h (100%)
 rename arch/x86/include/{ => uapi}/asm/types.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ucontext.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/unistd.h
 create mode 100644 arch/x86/include/uapi/asm/vm86.h
 create mode 100644 arch/x86/include/uapi/asm/vmx.h
 create mode 100644 arch/x86/include/uapi/asm/vsyscall.h

Re: [GIT PULL] x86/uapi for 3.8

[David Howells]

H. Peter Anvin <hpa@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 +0000)

----------------------------------------------------------------
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
 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                   | 132 +++++++++++++
 arch/x86/include/{ => uapi}/asm/swab.h            |   0
 arch/x86/include/{ => uapi}/asm/termbits.h        |   0
 arch/x86/include/{ => uapi}/asm/termios.h         |   0
 arch/x86/include/{ => uapi}/asm/types.h           |   0
 arch/x86/include/{ => uapi}/asm/ucontext.h        |   0
 arch/x86/include/uapi/asm/unistd.h                |  17 ++
 arch/x86/include/uapi/asm/vm86.h                  | 129 +++++++++++++
 arch/x86/include/uapi/asm/vmx.h                   | 109 +++++++++++
 arch/x86/include/uapi/asm/vsyscall.h              |  17 ++
 78 files changed, 1587 insertions(+), 1428 deletions(-)
 rename arch/x86/include/{ => uapi}/asm/a.out.h (100%)
 rename arch/x86/include/{ => uapi}/asm/auxvec.h (100%)
 rename arch/x86/include/{ => uapi}/asm/bitsperlong.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/boot.h
 rename arch/x86/include/{ => uapi}/asm/bootparam.h (100%)
 rename arch/x86/include/{ => uapi}/asm/byteorder.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/debugreg.h
 create mode 100644 arch/x86/include/uapi/asm/e820.h
 rename arch/x86/include/{ => uapi}/asm/errno.h (100%)
 rename arch/x86/include/{ => uapi}/asm/fcntl.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/hw_breakpoint.h
 rename arch/x86/include/{ => uapi}/asm/hyperv.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ioctl.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ioctls.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ipcbuf.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/ist.h
 rename arch/x86/include/{ => uapi}/asm/kvm.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/kvm_para.h
 rename arch/x86/include/{ => uapi}/asm/ldt.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/mce.h
 rename arch/x86/include/{ => uapi}/asm/mman.h (100%)
 rename arch/x86/include/{ => uapi}/asm/msgbuf.h (100%)
 rename arch/x86/include/{ => uapi}/asm/msr-index.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/msr.h
 create mode 100644 arch/x86/include/uapi/asm/mtrr.h
 rename arch/x86/include/{ => uapi}/asm/param.h (100%)
 rename arch/x86/include/{ => uapi}/asm/perf_regs.h (100%)
 rename arch/x86/include/{ => uapi}/asm/poll.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/posix_types.h
 rename arch/x86/include/{ => uapi}/asm/posix_types_32.h (100%)
 rename arch/x86/include/{ => uapi}/asm/posix_types_64.h (100%)
 rename arch/x86/include/{ => uapi}/asm/posix_types_x32.h (100%)
 rename arch/x86/include/{ => uapi}/asm/prctl.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/processor-flags.h
 rename arch/x86/include/{ => uapi}/asm/ptrace-abi.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/ptrace.h
 rename arch/x86/include/{ => uapi}/asm/resource.h (100%)
 rename arch/x86/include/{ => uapi}/asm/sembuf.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/setup.h
 rename arch/x86/include/{ => uapi}/asm/shmbuf.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/sigcontext.h
 rename arch/x86/include/{ => uapi}/asm/sigcontext32.h (100%)
 rename arch/x86/include/{ => uapi}/asm/siginfo.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/signal.h
 rename arch/x86/include/{ => uapi}/asm/socket.h (100%)
 rename arch/x86/include/{ => uapi}/asm/sockios.h (100%)
 rename arch/x86/include/{ => uapi}/asm/stat.h (100%)
 rename arch/x86/include/{ => uapi}/asm/statfs.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/svm.h
 rename arch/x86/include/{ => uapi}/asm/swab.h (100%)
 rename arch/x86/include/{ => uapi}/asm/termbits.h (100%)
 rename arch/x86/include/{ => uapi}/asm/termios.h (100%)
 rename arch/x86/include/{ => uapi}/asm/types.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ucontext.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/unistd.h
 create mode 100644 arch/x86/include/uapi/asm/vm86.h
 create mode 100644 arch/x86/include/uapi/asm/vmx.h
 create mode 100644 arch/x86/include/uapi/asm/vsyscall.h

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Wed, Dec 12, 2012 at 3:48 PM, David Howells <dhowells@redhat.com> wrote:
> H. Peter Anvin <hpa@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

Re: [GIT PULL] x86/uapi for 3.8

[David Howells]

Linus Torvalds <torvalds@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 +0000)

----------------------------------------------------------------
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
 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                   | 132 +++++++++++++
 arch/x86/include/{ => uapi}/asm/swab.h            |   0
 arch/x86/include/{ => uapi}/asm/termbits.h        |   0
 arch/x86/include/{ => uapi}/asm/termios.h         |   0
 arch/x86/include/{ => uapi}/asm/types.h           |   0
 arch/x86/include/{ => uapi}/asm/ucontext.h        |   0
 arch/x86/include/uapi/asm/unistd.h                |  17 ++
 arch/x86/include/uapi/asm/vm86.h                  | 129 +++++++++++++
 arch/x86/include/uapi/asm/vmx.h                   | 109 +++++++++++
 arch/x86/include/uapi/asm/vsyscall.h              |  17 ++
 78 files changed, 1587 insertions(+), 1428 deletions(-)
 rename arch/x86/include/{ => uapi}/asm/a.out.h (100%)
 rename arch/x86/include/{ => uapi}/asm/auxvec.h (100%)
 rename arch/x86/include/{ => uapi}/asm/bitsperlong.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/boot.h
 rename arch/x86/include/{ => uapi}/asm/bootparam.h (100%)
 rename arch/x86/include/{ => uapi}/asm/byteorder.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/debugreg.h
 create mode 100644 arch/x86/include/uapi/asm/e820.h
 rename arch/x86/include/{ => uapi}/asm/errno.h (100%)
 rename arch/x86/include/{ => uapi}/asm/fcntl.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/hw_breakpoint.h
 rename arch/x86/include/{ => uapi}/asm/hyperv.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ioctl.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ioctls.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ipcbuf.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/ist.h
 rename arch/x86/include/{ => uapi}/asm/kvm.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/kvm_para.h
 rename arch/x86/include/{ => uapi}/asm/ldt.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/mce.h
 rename arch/x86/include/{ => uapi}/asm/mman.h (100%)
 rename arch/x86/include/{ => uapi}/asm/msgbuf.h (100%)
 rename arch/x86/include/{ => uapi}/asm/msr-index.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/msr.h
 create mode 100644 arch/x86/include/uapi/asm/mtrr.h
 rename arch/x86/include/{ => uapi}/asm/param.h (100%)
 rename arch/x86/include/{ => uapi}/asm/perf_regs.h (100%)
 rename arch/x86/include/{ => uapi}/asm/poll.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/posix_types.h
 rename arch/x86/include/{ => uapi}/asm/posix_types_32.h (100%)
 rename arch/x86/include/{ => uapi}/asm/posix_types_64.h (100%)
 rename arch/x86/include/{ => uapi}/asm/posix_types_x32.h (100%)
 rename arch/x86/include/{ => uapi}/asm/prctl.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/processor-flags.h
 rename arch/x86/include/{ => uapi}/asm/ptrace-abi.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/ptrace.h
 rename arch/x86/include/{ => uapi}/asm/resource.h (100%)
 rename arch/x86/include/{ => uapi}/asm/sembuf.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/setup.h
 rename arch/x86/include/{ => uapi}/asm/shmbuf.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/sigcontext.h
 rename arch/x86/include/{ => uapi}/asm/sigcontext32.h (100%)
 rename arch/x86/include/{ => uapi}/asm/siginfo.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/signal.h
 rename arch/x86/include/{ => uapi}/asm/socket.h (100%)
 rename arch/x86/include/{ => uapi}/asm/sockios.h (100%)
 rename arch/x86/include/{ => uapi}/asm/stat.h (100%)
 rename arch/x86/include/{ => uapi}/asm/statfs.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/svm.h
 rename arch/x86/include/{ => uapi}/asm/swab.h (100%)
 rename arch/x86/include/{ => uapi}/asm/termbits.h (100%)
 rename arch/x86/include/{ => uapi}/asm/termios.h (100%)
 rename arch/x86/include/{ => uapi}/asm/types.h (100%)
 rename arch/x86/include/{ => uapi}/asm/ucontext.h (100%)
 create mode 100644 arch/x86/include/uapi/asm/unistd.h
 create mode 100644 arch/x86/include/uapi/asm/vm86.h
 create mode 100644 arch/x86/include/uapi/asm/vmx.h
 create mode 100644 arch/x86/include/uapi/asm/vsyscall.h

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Fri, Dec 14, 2012 at 3:45 PM, David Howells <dhowells@redhat.com> wrote:
> Linus Torvalds <torvalds@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

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

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
<torvalds@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

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds
<torvalds@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

Re: [GIT PULL] x86/uapi for 3.8

[H. Peter Anvin]

On 12/14/2012 05:16 PM, Linus Torvalds wrote:
> On Fri, Dec 14, 2012 at 3:45 PM, David Howells <dhowells@redhat.com> wrote:
>> Linus Torvalds <torvalds@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

Re: [GIT PULL] x86/uapi for 3.8

[Markus Trippelsdorf]

On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
> On Fri, Dec 14, 2012 at 5:41 PM, Linus Torvalds
> <torvalds@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.fleming@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 <jbeulich@suse.com>
    Signed-off-by: Matt Fleming <matt.fleming@intel.com>

-- 
Markus

Re: [GIT PULL] x86/uapi for 3.8

[Markus Trippelsdorf]

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
> > <torvalds@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.fleming@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 <jbeulich@suse.com>
>     Signed-off-by: Matt Fleming <matt.fleming@intel.com>
> 

Adding Matt to CC.

-- 
Markus

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf
<markus@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

Re: [GIT PULL] x86/uapi for 3.8

[H. Peter Anvin]

On 12/15/2012 10:35 AM, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf
> <markus@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

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Matt is on vacation, and I'm partly offline for the weekend, but that
> definitely seems suspicious.  Do we have a memory map of the affected
> machine(s)?

Here's mine.

  e820: BIOS-provided physical RAM map:
  BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
  BIOS-e820: [mem 0x000000000009e800-0x000000000009ffff] reserved
  BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
  BIOS-e820: [mem 0x0000000000100000-0x00000000bdc6ffff] usable
  BIOS-e820: [mem 0x00000000bdc70000-0x00000000bdc87fff] ACPI data
  BIOS-e820: [mem 0x00000000bdc88000-0x00000000bdcdbfff] ACPI NVS
  BIOS-e820: [mem 0x00000000bdcdc000-0x00000000bfffffff] reserved
  BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
  BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
  BIOS-e820: [mem 0x0000000100000000-0x00000001fbffffff] usable
  BIOS-e820: [mem 0x00000001fc000000-0x00000001ffffffff] reserved
  BIOS-e820: [mem 0x0000000200000000-0x000000023fffffff] usable

but as mentioned, there's bound to be some particular kernel layout
that triggers this, because I definitely ran a few kernels with that
commit in it without problems (and clearly other people are too).
Looking at my boot log, I had successful boots with both 6a57d104c8cb
and c2714334b944, which contains that commit.

It might also be that it causes some massive corruption at boot time,
but it then requires that that particular memory is actually used. So
maybe it's not so much about the memory map except indirectly.

But that commit *does* look a lot more likely than the things I looked at.

Markus, how did you happen to pinpoint that particular commit? Is it
entirely repeatable for you?

              Linus

Re: [GIT PULL] x86/uapi for 3.8

[Markus Trippelsdorf]

On 2012.12.15 at 11:58 -0800, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> >
> > Matt is on vacation, and I'm partly offline for the weekend, but that
> > definitely seems suspicious.  Do we have a memory map of the affected
> > machine(s)?
> 
> Here's mine.
> 
>   e820: BIOS-provided physical RAM map:
>   BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
>   BIOS-e820: [mem 0x000000000009e800-0x000000000009ffff] reserved
>   BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
>   BIOS-e820: [mem 0x0000000000100000-0x00000000bdc6ffff] usable
>   BIOS-e820: [mem 0x00000000bdc70000-0x00000000bdc87fff] ACPI data
>   BIOS-e820: [mem 0x00000000bdc88000-0x00000000bdcdbfff] ACPI NVS
>   BIOS-e820: [mem 0x00000000bdcdc000-0x00000000bfffffff] reserved
>   BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
>   BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
>   BIOS-e820: [mem 0x0000000100000000-0x00000001fbffffff] usable
>   BIOS-e820: [mem 0x00000001fc000000-0x00000001ffffffff] reserved
>   BIOS-e820: [mem 0x0000000200000000-0x000000023fffffff] usable
> 
> but as mentioned, there's bound to be some particular kernel layout
> that triggers this, because I definitely ran a few kernels with that
> commit in it without problems (and clearly other people are too).
> Looking at my boot log, I had successful boots with both 6a57d104c8cb
> and c2714334b944, which contains that commit.
> 
> It might also be that it causes some massive corruption at boot time,
> but it then requires that that particular memory is actually used. So
> maybe it's not so much about the memory map except indirectly.
> 
> But that commit *does* look a lot more likely than the things I looked at.
> 
> Markus, how did you happen to pinpoint that particular commit? Is it
> entirely repeatable for you?

Yes, although at one point during bisecting the BUG disappeared and the
screen went simply black during boot and X never started. I marked this
as bad and continued the bisection.

Here is my mem-map:

e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0000000000000100-0x000000000009fbff] usable
BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000e6000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x00000000dfe8ffff] usable
BIOS-e820: [mem 0x00000000dfe90000-0x00000000dfea7fff] ACPI data
BIOS-e820: [mem 0x00000000dfea8000-0x00000000dfecffff] ACPI NVS
BIOS-e820: [mem 0x00000000dfed0000-0x00000000dfefffff] reserved
BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
BIOS-e820: [mem 0x0000000100000000-0x000000021fffffff] usable

-- 
Markus

Re: [GIT PULL] x86/uapi for 3.8

[Markus Trippelsdorf]

On 2012.12.15 at 11:58 -0800, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 11:41 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> >
> > Matt is on vacation, and I'm partly offline for the weekend, but that
> > definitely seems suspicious.  Do we have a memory map of the affected
> > machine(s)?
> 
> 
> 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

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Sat, Dec 15, 2012 at 1:04 PM, Markus Trippelsdorf
<markus@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

Re: [GIT PULL] x86/uapi for 3.8

[H. Peter Anvin]

On 12/15/2012 01:06 PM, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 1:04 PM, Markus Trippelsdorf
> <markus@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.

Re: [GIT PULL] x86/uapi for 3.8

[Dave Jones]

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

Re: [GIT PULL] x86/uapi for 3.8

[Yinghai Lu]

On Sat, Dec 15, 2012 at 1:06 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Sat, Dec 15, 2012 at 1:04 PM, Markus Trippelsdorf
> <markus@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

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Sat, Dec 15, 2012 at 2:05 PM, Yinghai Lu <yinghai@kernel.org> wrote:
> On Sat, Dec 15, 2012 at 1:06 PM, Linus Torvalds <torvalds@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

Re: [GIT PULL] x86/uapi for 3.8

[H. Peter Anvin]

>
> 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.

Re: [GIT PULL] x86/uapi for 3.8

[H. Peter Anvin]

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.

Re: [GIT PULL] x86/uapi for 3.8

[Matt Fleming]

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
> > > <torvalds@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.fleming@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 <jbeulich@suse.com>
> >     Signed-off-by: Matt Fleming <matt.fleming@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.fleming@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 <jbeulich@suse.com>
Signed-off-by: Matt Fleming <matt.fleming@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 ident_pmd_range(unsigned long paddr, unsigned long vaddr,
+			    pud_t *ppud, pud_t *vpud, unsigned long end)
+{
+	pmd_t *ppmd = pmd_offset(ppud, paddr);
+	pmd_t *vpmd = pmd_offset(vpud, vaddr);
+	unsigned long next;
+
+	do {
+		next = pmd_addr_end(vaddr, end);
+
+		if (!pmd_present(*ppmd)) {
+			pte_t *ppte = (pte_t *)get_zeroed_page(GFP_KERNEL);
+			if (!ppte)
+				return 1;
+
+			set_pmd(ppmd, __pmd(_KERNPG_TABLE | __pa(ppte)));
+		}
+
+		ident_pte_range(paddr, vaddr, ppmd, vpmd, next);
+
+		paddr += PMD_SIZE;
+	} while (ppmd++, vpmd++, vaddr = next, vaddr != end);
+
+	return 0;
+}
+
+static int ident_pud_range(unsigned long paddr, unsigned long vaddr,
+			    pgd_t *ppgd, pgd_t *vpgd, unsigned long end)
+{
+	pud_t *ppud = pud_offset(ppgd, paddr);
+	pud_t *vpud = pud_offset(vpgd, vaddr);
+	unsigned long next;
+
+	do {
+		next = pud_addr_end(vaddr, end);
+
+		if (!pud_present(*ppud)) {
+			pmd_t *ppmd = (pmd_t *)get_zeroed_page(GFP_KERNEL);
+			if (!ppmd)
+				return 1;
+
+			set_pud(ppud, __pud(_KERNPG_TABLE | __pa(ppmd)));
+		}
+
+		if (ident_pmd_range(paddr, vaddr, ppud, vpud, next))
+			return 1;
+
+		paddr += PUD_SIZE;
+	} while (ppud++, vpud++, vaddr = next, vaddr != end);
+
+	return 0;
+}
+
+static int insert_identity_mapping(resource_size_t paddr, unsigned long vaddr,
+				    unsigned long size)
+{
+	unsigned long end = vaddr + size;
+	unsigned long next;
+	pgd_t *vpgd, *ppgd;
+
+	/* Don't map over the guard hole. */
+	if (paddr >= 0x800000000000 || paddr + size > 0x800000000000)
+		return 1;
+
+	ppgd = __va(real_mode_header->trampoline_pgd) + pgd_index(paddr);
+
+	vpgd = pgd_offset_k(vaddr);
+	do {
+		next = pgd_addr_end(vaddr, end);
+
+		if (!pgd_present(*ppgd)) {
+			pud_t *ppud = (pud_t *)get_zeroed_page(GFP_KERNEL);
+			if (!ppud)
+				return 1;
+
+			set_pgd(ppgd, __pgd(_KERNPG_TABLE | __pa(ppud)));
+		}
+
+		if (ident_pud_range(paddr, vaddr, ppgd, vpgd, next))
+			return 1;
+
+		paddr += PGDIR_SIZE;
+	} while (ppgd++, vpgd++, vaddr = next, vaddr != end);
+
+	return 0;
+}
+#else
+static inline int insert_identity_mapping(resource_size_t paddr,
+					  unsigned long vaddr,
+					  unsigned long size)
+{
+	return 0;
+}
+#endif /* CONFIG_X86_64 */
+
 /*
  * Remap an arbitrary physical address space into the kernel virtual
  * address space. Needed when the kernel wants to access high addresses
@@ -163,6 +270,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
 	ret_addr = (void __iomem *) (vaddr + offset);
 	mmiotrace_ioremap(unaligned_phys_addr, unaligned_size, ret_addr);
 
+	if (insert_identity_mapping(phys_addr, vaddr, size))
+		printk(KERN_WARNING "ioremap: unable to map 0x%llx in identity pagetable\n",
+					(unsigned long long)phys_addr);
+
 	/*
 	 * Check if the request spans more than any BAR in the iomem resource
 	 * tree.
diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
index cbca565..8e6ab61 100644
--- a/arch/x86/realmode/init.c
+++ b/arch/x86/realmode/init.c
@@ -78,8 +78,21 @@ void __init setup_real_mode(void)
 	*trampoline_cr4_features = read_cr4();
 
 	trampoline_pgd = (u64 *) __va(real_mode_header->trampoline_pgd);
-	trampoline_pgd[0] = __pa(level3_ident_pgt) + _KERNPG_TABLE;
-	trampoline_pgd[511] = __pa(level3_kernel_pgt) + _KERNPG_TABLE;
+
+	/*
+	 * Create an identity mapping for all of physical memory.
+	 */
+	for (i = 0; i <= pgd_index(max_pfn << PAGE_SHIFT); i++) {
+		int index = pgd_index(PAGE_OFFSET) + i;
+
+		trampoline_pgd[i] = (u64)pgd_val(swapper_pg_dir[index]);
+	}
+
+	/*
+	 * Copy the upper-half of the kernel pages tables.
+	 */
+	for (i = pgd_index(PAGE_OFFSET); i < PTRS_PER_PGD; i++)
+		trampoline_pgd[i] = (u64)pgd_val(swapper_pg_dir[i]);
 #endif
 }
 
-- 
1.7.11.7

Re: [GIT PULL] x86/uapi for 3.8

[Matt Fleming]

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.

Re: [GIT PULL] x86/uapi for 3.8

[Markus Trippelsdorf]

[-- Attachment #1: Type: text/plain, Size: 2401 bytes --]

On 2012.12.16 at 12:43 +0000, 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
> > > > <torvalds@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.fleming@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 <jbeulich@suse.com>
> > >     Signed-off-by: Matt Fleming <matt.fleming@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

[-- Attachment #2: dmesg --]
[-- Type: text/plain, Size: 31901 bytes --]

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 0x0000000000000100-0x000000000009fbff] usable
BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000e6000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x00000000dfe8ffff] usable
BIOS-e820: [mem 0x00000000dfe90000-0x00000000dfea7fff] ACPI data
BIOS-e820: [mem 0x00000000dfea8000-0x00000000dfecffff] ACPI NVS
BIOS-e820: [mem 0x00000000dfed0000-0x00000000dfefffff] reserved
BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
BIOS-e820: [mem 0x0000000100000000-0x000000021fffffff] usable
NX (Execute Disable) protection: active
DMI present.
DMI: System manufacturer System Product Name/M4A78T-E, BIOS 3503    04/13/2011
e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
e820: remove [mem 0x000a0000-0x000fffff] usable
e820: last_pfn = 0x220000 max_arch_pfn = 0x400000000
MTRR default type: uncachable
MTRR fixed ranges enabled:
  00000-9FFFF write-back
  A0000-EFFFF uncachable
  F0000-FFFFF write-protect
MTRR variable ranges enabled:
  0 base 000000000000 mask FFFF80000000 write-back
  1 base 000080000000 mask FFFFC0000000 write-back
  2 base 0000C0000000 mask FFFFE0000000 write-back
  3 base 0000F0000000 mask FFFFF8000000 write-combining
  4 disabled
  5 disabled
  6 disabled
  7 disabled
TOM2: 0000000220000000 aka 8704M
x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106
e820: last_pfn = 0xdfe90 max_arch_pfn = 0x400000000
initial memory mapped: [mem 0x00000000-0x1fffffff]
Base memory trampoline at [ffff880000099000] 99000 size 24576
Using GB pages for direct mapping
init_memory_mapping: [mem 0x00000000-0xdfe8ffff]
 [mem 0x00000000-0xbfffffff] page 1G
 [mem 0xc0000000-0xdfdfffff] page 2M
 [mem 0xdfe00000-0xdfe8ffff] page 4k
kernel direct mapping tables up to 0xdfe8ffff @ [mem 0x1fffd000-0x1fffffff]
init_memory_mapping: [mem 0x100000000-0x21fffffff]
 [mem 0x100000000-0x1ffffffff] page 1G
 [mem 0x200000000-0x21fffffff] page 2M
kernel direct mapping tables up to 0x21fffffff @ [mem 0xdfe8e000-0xdfe8ffff]
ACPI: RSDP 00000000000fb880 00024 (v02 ACPIAM)
ACPI: XSDT 00000000dfe90100 0005C (v01 041311 XSDT1656 20110413 MSFT 00000097)
ACPI: FACP 00000000dfe90290 000F4 (v03 041311 FACP1656 20110413 MSFT 00000097)
ACPI BIOS Bug: Warning: Optional FADT field Pm2ControlBlock has zero address or length: 0x0000000000000000/0x1 (20121018/tbfadt-598)
ACPI: DSDT 00000000dfe90450 0E6FE (v01  A1152 A1152000 00000000 INTL 20060113)
ACPI: FACS 00000000dfea8000 00040
ACPI: APIC 00000000dfe90390 0007C (v01 041311 APIC1656 20110413 MSFT 00000097)
ACPI: MCFG 00000000dfe90410 0003C (v01 041311 OEMMCFG  20110413 MSFT 00000097)
ACPI: OEMB 00000000dfea8040 00072 (v01 041311 OEMB1656 20110413 MSFT 00000097)
ACPI: SRAT 00000000dfe9f450 000E8 (v01 AMD    FAM_F_10 00000002 AMD  00000001)
ACPI: HPET 00000000dfe9f540 00038 (v01 041311 OEMHPET  20110413 MSFT 00000097)
ACPI: SSDT 00000000dfe9f580 0088C (v01 A M I  POWERNOW 00000001 AMD  00000001)
ACPI: Local APIC address 0xfee00000
 [ffffea0000000000-ffffea00087fffff] PMD -> [ffff880217600000-ffff88021f5fffff] on node 0
Zone ranges:
  DMA      [mem 0x00010000-0x00ffffff]
  DMA32    [mem 0x01000000-0xffffffff]
  Normal   [mem 0x100000000-0x21fffffff]
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x00010000-0x0009efff]
  node   0: [mem 0x00100000-0xdfe8ffff]
  node   0: [mem 0x100000000-0x21fffffff]
On node 0 totalpages: 2096671
  DMA zone: 64 pages used for memmap
  DMA zone: 6 pages reserved
  DMA zone: 3913 pages, LIFO batch:0
  DMA32 zone: 14267 pages used for memmap
  DMA32 zone: 898773 pages, LIFO batch:31
  Normal zone: 18432 pages used for memmap
  Normal zone: 1161216 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x84] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x85] disabled)
ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 4, version 33, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: HPET id: 0x8300 base: 0xfed00000
smpboot: Allowing 4 CPUs, 0 hotplug CPUs
nr_irqs_gsi: 40
e820: [mem 0xdff00000-0xffefffff] available for PCI devices
setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
PERCPU: Embedded 23 pages/cpu @ffff88021fc00000 s73280 r0 d20928 u524288
pcpu-alloc: s73280 r0 d20928 u524288 alloc=1*2097152
pcpu-alloc: [0] 0 1 2 3 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 2063902
Kernel command line: root=PARTUUID=1E3384D0-CAE6-41BB-8CD6-4F640164EFD7 init=/sbin/minit fbcon=rotate:3 drm_kms_helper.poll=0 quiet
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
__ex_table already sorted, skipping sort
Memory: 8167052k/8912896k available (4895k kernel code, 526212k absent, 219632k reserved, 3705k data, 444k init)
SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:4352 nr_irqs:712 16
Extended CMOS year: 2000
Console: colour VGA+ 80x25
console [tty0] enabled
hpet clockevent registered
tsc: Fast TSC calibration using PIT
tsc: Detected 3211.074 MHz processor
Calibrating delay loop (skipped), value calculated using timer frequency.. 6424.73 BogoMIPS (lpj=10703580)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 256
tseg: 0000000000
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
mce: CPU supports 6 MCE banks
LVT offset 0 assigned for vector 0xf9
process: using AMD E400 aware idle routine
Last level iTLB entries: 4KB 512, 2MB 16, 4MB 8
Last level dTLB entries: 4KB 512, 2MB 128, 4MB 64
tlb_flushall_shift: 4
Freeing SMP alternatives: 16k freed
ACPI: Core revision 20121018
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
smpboot: CPU0: AMD Phenom(tm) II X4 955 Processor (fam: 10, model: 04, stepping: 02)
Performance Events: AMD PMU driver.
... version:                0
... bit width:              48
... generic registers:      4
... value mask:             0000ffffffffffff
... max period:             00007fffffffffff
... fixed-purpose events:   0
... event mask:             000000000000000f
MCE: In-kernel MCE decoding enabled.
process: System has AMD C1E enabled
process: Switch to broadcast mode on CPU1
process: Switch to broadcast mode on CPU2
smpboot: Booting Node   0, Processors  #1 #2 #3 OK
Brought up 4 CPUs
smpboot: Total of 4 processors activated (25698.95 BogoMIPS)
process: Switch to broadcast mode on CPU3
process: Switch to broadcast mode on CPU0
devtmpfs: initialized
NET: Registered protocol family 16
node 0 link 0: io port [1000, ffffff]
TOM: 00000000e0000000 aka 3584M
Fam 10h mmconf [mem 0xe0000000-0xefffffff]
node 0 link 0: mmio [a0000, bffff]
node 0 link 0: mmio [e0000000, efffffff] ==> none
node 0 link 0: mmio [f0000000, fbcfffff]
node 0 link 0: mmio [fbd00000, fbefffff]
node 0 link 0: mmio [fbf00000, ffefffff]
TOM2: 0000000220000000 aka 8704M
bus: [bus 00-07] on node 0 link 0
bus: 00 [io  0x0000-0xffff]
bus: 00 [mem 0x000a0000-0x000bffff]
bus: 00 [mem 0xf0000000-0xffffffff]
bus: 00 [mem 0x220000000-0xfcffffffff]
ACPI: bus type pci registered
PCI: Using configuration type 1 for base access
PCI: Using configuration type 1 for extended access
bio: create slab <bio-0> at 0
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: EC: Look up EC in DSDT
ACPI: Executed 3 blocks of module-level executable AML code
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOAPIC for interrupt routing
PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
pci_root PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM
pci_root PNP0A03:00: Unable to request _OSC control (_OSC support mask: 0x08)
PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]
pci_bus 0000:00: root bus resource [mem 0xdff00000-0xdfffffff]
pci_bus 0000:00: root bus resource [mem 0xf0000000-0xfebfffff]
pci 0000:00:00.0: [1022:9600] type 00 class 0x060000
pci 0000:00:01.0: [1022:9602] type 01 class 0x060400
pci 0000:00:06.0: [1022:9606] type 01 class 0x060400
pci 0000:00:06.0: PME# supported from D0 D3hot D3cold
pci 0000:00:11.0: [1002:4391] type 00 class 0x010601
pci 0000:00:11.0: reg 10: [io  0xc000-0xc007]
pci 0000:00:11.0: reg 14: [io  0xb000-0xb003]
pci 0000:00:11.0: reg 18: [io  0xa000-0xa007]
pci 0000:00:11.0: reg 1c: [io  0x9000-0x9003]
pci 0000:00:11.0: reg 20: [io  0x8000-0x800f]
pci 0000:00:11.0: reg 24: [mem 0xfbcffc00-0xfbcfffff]
pci 0000:00:12.0: [1002:4397] type 00 class 0x0c0310
pci 0000:00:12.0: reg 10: [mem 0xfbcfd000-0xfbcfdfff]
pci 0000:00:12.1: [1002:4398] type 00 class 0x0c0310
pci 0000:00:12.1: reg 10: [mem 0xfbcfe000-0xfbcfefff]
pci 0000:00:12.2: [1002:4396] type 00 class 0x0c0320
pci 0000:00:12.2: reg 10: [mem 0xfbcff800-0xfbcff8ff]
pci 0000:00:12.2: supports D1 D2
pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
pci 0000:00:13.0: [1002:4397] type 00 class 0x0c0310
pci 0000:00:13.0: reg 10: [mem 0xfbcfb000-0xfbcfbfff]
pci 0000:00:13.1: [1002:4398] type 00 class 0x0c0310
pci 0000:00:13.1: reg 10: [mem 0xfbcfc000-0xfbcfcfff]
pci 0000:00:13.2: [1002:4396] type 00 class 0x0c0320
pci 0000:00:13.2: reg 10: [mem 0xfbcff400-0xfbcff4ff]
pci 0000:00:13.2: supports D1 D2
pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
pci 0000:00:14.0: [1002:4385] type 00 class 0x0c0500
pci 0000:00:14.1: [1002:439c] type 00 class 0x01018a
pci 0000:00:14.1: reg 10: [io  0x0000-0x0007]
pci 0000:00:14.1: reg 14: [io  0x0000-0x0003]
pci 0000:00:14.1: reg 18: [io  0x0000-0x0007]
pci 0000:00:14.1: reg 1c: [io  0x0000-0x0003]
pci 0000:00:14.1: reg 20: [io  0xff00-0xff0f]
pci 0000:00:14.2: [1002:4383] type 00 class 0x040300
pci 0000:00:14.2: reg 10: [mem 0xfbcf4000-0xfbcf7fff 64bit]
pci 0000:00:14.2: PME# supported from D0 D3hot D3cold
pci 0000:00:14.3: [1002:439d] type 00 class 0x060100
pci 0000:00:14.4: [1002:4384] type 01 class 0x060401
pci 0000:00:14.5: [1002:4399] type 00 class 0x0c0310
pci 0000:00:14.5: reg 10: [mem 0xfbcfa000-0xfbcfafff]
pci 0000:00:18.0: [1022:1200] type 00 class 0x060000
pci 0000:00:18.1: [1022:1201] type 00 class 0x060000
pci 0000:00:18.2: [1022:1202] type 00 class 0x060000
pci 0000:00:18.3: [1022:1203] type 00 class 0x060000
pci 0000:00:18.4: [1022:1204] type 00 class 0x060000
pci 0000:01:05.0: [1002:9614] type 00 class 0x030000
pci 0000:01:05.0: reg 10: [mem 0xf0000000-0xf7ffffff pref]
pci 0000:01:05.0: reg 14: [io  0xd000-0xd0ff]
pci 0000:01:05.0: reg 18: [mem 0xfbee0000-0xfbeeffff]
pci 0000:01:05.0: reg 24: [mem 0xfbd00000-0xfbdfffff]
pci 0000:01:05.0: supports D1 D2
pci 0000:01:05.1: [1002:960f] type 00 class 0x040300
pci 0000:01:05.1: reg 10: [mem 0xfbefc000-0xfbefffff]
pci 0000:01:05.1: supports D1 D2
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
pci 0000:00:01.0:   bridge window [mem 0xfbd00000-0xfbefffff]
pci 0000:00:01.0:   bridge window [mem 0xf0000000-0xf7ffffff 64bit pref]
pci 0000:02:00.0: [1969:1026] type 00 class 0x020000
pci 0000:02:00.0: reg 10: [mem 0xfbfc0000-0xfbffffff 64bit]
pci 0000:02:00.0: reg 18: [io  0xec00-0xec7f]
pci 0000:02:00.0: PME# supported from D3hot D3cold
pci 0000:00:06.0: PCI bridge to [bus 02]
pci 0000:00:06.0:   bridge window [io  0xe000-0xefff]
pci 0000:00:06.0:   bridge window [mem 0xfbf00000-0xfbffffff]
pci 0000:00:14.4: PCI bridge to [bus 03] (subtractive decode)
pci 0000:00:14.4:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
pci 0000:00:14.4:   bridge window [io  0x0d00-0xffff] (subtractive decode)
pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
pci 0000:00:14.4:   bridge window [mem 0x000d0000-0x000dffff] (subtractive decode)
pci 0000:00:14.4:   bridge window [mem 0xdff00000-0xdfffffff] (subtractive decode)
pci 0000:00:14.4:   bridge window [mem 0xf0000000-0xfebfffff] (subtractive decode)
pci_bus 0000:00: on NUMA node 0
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCE6._PRT]
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI: Invalid Power Resource to register!
ACPI _OSC control for PCIe not granted, disabling ASPM
ACPI: PCI Interrupt Link [LNKA] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 4 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) *0, disabled.
SCSI subsystem initialized
libata version 3.00 loaded.
ACPI: bus type usb registered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Initialized.
PCI: Using ACPI for IRQ routing
PCI: pci_cache_line_size set to 64 bytes
e820: reserve RAM buffer [mem 0x0009fc00-0x0009ffff]
e820: reserve RAM buffer [mem 0xdfe90000-0xdfffffff]
hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
hpet0: 4 comparators, 32-bit 14.318180 MHz counter
Switching to clocksource hpet
pnp: PnP ACPI init
ACPI: bus type pnp registered
system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
pnp 00:01: [dma 4]
pnp 00:01: Plug and Play ACPI device, IDs PNP0200 (active)
pnp 00:02: Plug and Play ACPI device, IDs PNP0b00 (active)
pnp 00:03: Plug and Play ACPI device, IDs PNP0800 (active)
pnp 00:04: Plug and Play ACPI device, IDs PNP0c04 (active)
pnp 00:05: Plug and Play ACPI device, IDs PNP0103 (active)
system 00:06: [mem 0xfec00000-0xfec00fff] could not be reserved
system 00:06: [mem 0xfee00000-0xfee00fff] has been reserved
system 00:06: Plug and Play ACPI device, IDs PNP0c02 (active)
system 00:07: [io  0x04d0-0x04d1] has been reserved
system 00:07: [io  0x040b] has been reserved
system 00:07: [io  0x04d6] has been reserved
system 00:07: [io  0x0c00-0x0c01] has been reserved
system 00:07: [io  0x0c14] has been reserved
system 00:07: [io  0x0c50-0x0c51] has been reserved
system 00:07: [io  0x0c52] has been reserved
system 00:07: [io  0x0c6c] has been reserved
system 00:07: [io  0x0c6f] has been reserved
system 00:07: [io  0x0cd0-0x0cd1] has been reserved
system 00:07: [io  0x0cd2-0x0cd3] has been reserved
system 00:07: [io  0x0cd4-0x0cd5] has been reserved
system 00:07: [io  0x0cd6-0x0cd7] has been reserved
system 00:07: [io  0x0cd8-0x0cdf] has been reserved
system 00:07: [io  0x0b00-0x0b3f] has been reserved
system 00:07: [io  0x0800-0x089f] has been reserved
system 00:07: [io  0x0b00-0x0b0f] has been reserved
system 00:07: [io  0x0b20-0x0b3f] has been reserved
system 00:07: [io  0x0900-0x090f] has been reserved
system 00:07: [io  0x0910-0x091f] has been reserved
system 00:07: [io  0xfe00-0xfefe] has been reserved
system 00:07: [mem 0xdff00000-0xdfffffff] has been reserved
system 00:07: [mem 0xffb80000-0xffbfffff] has been reserved
system 00:07: [mem 0xfec10000-0xfec1001f] has been reserved
system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
system 00:08: [io  0x0230-0x023f] has been reserved
system 00:08: [io  0x0290-0x029f] has been reserved
system 00:08: [io  0x0f40-0x0f4f] has been reserved
system 00:08: [io  0x0a30-0x0a3f] has been reserved
system 00:08: Plug and Play ACPI device, IDs PNP0c02 (active)
system 00:09: [mem 0xe0000000-0xefffffff] has been reserved
system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
system 00:0a: [mem 0x00000000-0x0009ffff] could not be reserved
system 00:0a: [mem 0x000c0000-0x000cffff] could not be reserved
system 00:0a: [mem 0x000e0000-0x000fffff] could not be reserved
system 00:0a: [mem 0x00100000-0xdfefffff] could not be reserved
system 00:0a: [mem 0xfec00000-0xffffffff] could not be reserved
system 00:0a: Plug and Play ACPI device, IDs PNP0c01 (active)
pnp: PnP ACPI: found 11 devices
ACPI: ACPI bus type pnp unregistered
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [io  0xd000-0xdfff]
pci 0000:00:01.0:   bridge window [mem 0xfbd00000-0xfbefffff]
pci 0000:00:01.0:   bridge window [mem 0xf0000000-0xf7ffffff 64bit pref]
pci 0000:00:06.0: PCI bridge to [bus 02]
pci 0000:00:06.0:   bridge window [io  0xe000-0xefff]
pci 0000:00:06.0:   bridge window [mem 0xfbf00000-0xfbffffff]
pci 0000:00:14.4: PCI bridge to [bus 03]
pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff]
pci_bus 0000:00: resource 8 [mem 0xdff00000-0xdfffffff]
pci_bus 0000:00: resource 9 [mem 0xf0000000-0xfebfffff]
pci_bus 0000:01: resource 0 [io  0xd000-0xdfff]
pci_bus 0000:01: resource 1 [mem 0xfbd00000-0xfbefffff]
pci_bus 0000:01: resource 2 [mem 0xf0000000-0xf7ffffff 64bit pref]
pci_bus 0000:02: resource 0 [io  0xe000-0xefff]
pci_bus 0000:02: resource 1 [mem 0xfbf00000-0xfbffffff]
pci_bus 0000:03: resource 4 [io  0x0000-0x0cf7]
pci_bus 0000:03: resource 5 [io  0x0d00-0xffff]
pci_bus 0000:03: resource 6 [mem 0x000a0000-0x000bffff]
pci_bus 0000:03: resource 7 [mem 0x000d0000-0x000dffff]
pci_bus 0000:03: resource 8 [mem 0xdff00000-0xdfffffff]
pci_bus 0000:03: resource 9 [mem 0xf0000000-0xfebfffff]
NET: Registered protocol family 2
TCP established hash table entries: 65536 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
TCP: reno registered
UDP hash table entries: 4096 (order: 5, 131072 bytes)
UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
NET: Registered protocol family 1
pci 0000:00:01.0: MSI quirk detected; subordinate MSI disabled
pci 0000:01:05.0: Boot video device
PCI: CLS 64 bytes, default 64
PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
software IO TLB [mem 0xdbe8e000-0xdfe8dfff] (64MB) mapped at [ffff8800dbe8e000-ffff8800dfe8dfff]
kvm: Nested Virtualization enabled
kvm: Nested Paging enabled
LVT offset 1 assigned for vector 0x400
IBS: LVT offset 1 assigned
perf: AMD IBS detected (0x0000001f)
microcode: CPU0: patch_level=0x010000db
microcode: CPU1: patch_level=0x010000db
microcode: CPU2: patch_level=0x010000db
microcode: CPU3: patch_level=0x010000db
microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
9p: Installing v9fs 9p2000 file system support
msgmni has been set to 15951
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered (default)
ACPI: processor limited to max C-state 1
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE0000
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used)
radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 4083534 kiB
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
[TTM] Initializing DMA pool allocator
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
radeon 0000:01:05.0: WB enabled
radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00 and cpu addr 0xffff8802163d8c00
radeon 0000:01:05.0: setting latency timer to 64
[drm] ring test on 0 succeeded in 0 usecs
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA-1
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm]     CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD3
[drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm]   Encoders:
[drm]     DFP3: INTERNAL_KLDSCP_LVTMA
[drm] radeon: power management initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF0000000
[drm] size 7299072
[drm] fb depth is 24
[drm]    pitch is 6912
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 131x105
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.24.0 20080528 for 0000:01:05.0 on minor 0
loop: module loaded
ahci 0000:00:11.0: version 3.0
ahci 0000:00:11.0: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc 
scsi0 : ahci
scsi1 : ahci
scsi2 : ahci
scsi3 : ahci
scsi4 : ahci
scsi5 : ahci
ata1: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffd00 irq 22
ata2: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffd80 irq 22
ata3: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffe00 irq 22
ata4: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcffe80 irq 22
ata5: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcfff00 irq 22
ata6: SATA max UDMA/133 abar m1024@0xfbcffc00 port 0xfbcfff80 irq 22
scsi6 : pata_atiixp
scsi7 : pata_atiixp
ata7: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14
ata8: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-pci 0000:00:12.2: EHCI Host Controller
ehci-pci 0000:00:12.2: new USB bus registered, assigned bus number 1
QUIRK: Enable AMD PLL fix
ehci-pci 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
ehci-pci 0000:00:12.2: applying AMD SB600/SB700 USB freeze workaround
ehci-pci 0000:00:12.2: debug port 1
ehci-pci 0000:00:12.2: irq 17, io mem 0xfbcff800
ehci-pci 0000:00:12.2: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
ehci-pci 0000:00:13.2: EHCI Host Controller
ehci-pci 0000:00:13.2: new USB bus registered, assigned bus number 2
ehci-pci 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
ehci-pci 0000:00:13.2: applying AMD SB600/SB700 USB freeze workaround
ehci-pci 0000:00:13.2: debug port 1
ehci-pci 0000:00:13.2: irq 19, io mem 0xfbcff400
ehci-pci 0000:00:13.2: USB 2.0 started, EHCI 1.00
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 6 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:12.0: OHCI Host Controller
ohci_hcd 0000:00:12.0: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:12.0: irq 16, io mem 0xfbcfd000
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
ohci_hcd 0000:00:12.1: OHCI Host Controller
ohci_hcd 0000:00:12.1: new USB bus registered, assigned bus number 4
ohci_hcd 0000:00:12.1: irq 16, io mem 0xfbcfe000
ata7.00: ATAPI: HL-DT-STDVD-RAM GH22NP20, 1.03, max UDMA/66
ata7.00: configured for UDMA/66
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 3 ports detected
ohci_hcd 0000:00:13.0: OHCI Host Controller
ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 5
ohci_hcd 0000:00:13.0: irq 18, io mem 0xfbcfb000
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 3 ports detected
ohci_hcd 0000:00:13.1: OHCI Host Controller
ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 6
ohci_hcd 0000:00:13.1: irq 18, io mem 0xfbcfc000
hub 6-0:1.0: USB hub found
hub 6-0:1.0: 3 ports detected
ohci_hcd 0000:00:14.5: OHCI Host Controller
ohci_hcd 0000:00:14.5: new USB bus registered, assigned bus number 7
ohci_hcd 0000:00:14.5: irq 18, io mem 0xfbcfa000
ata5: SATA link down (SStatus 0 SControl 300)
ata6: SATA link down (SStatus 0 SControl 300)
ata4: SATA link down (SStatus 0 SControl 300)
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1: SATA link down (SStatus 0 SControl 300)
ata3.00: ATA-8: OCZ VERTEX-TURBO, 1.7, max UDMA/133
ata3.00: 62533296 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
ata2.00: ATA-8: ST1500DL003-9VT16L, CC32, max UDMA/133
ata2.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 31/32)
ata3.00: failed to get Identify Device Data, Emask 0x1
ata2.00: failed to get Identify Device Data, Emask 0x1
ata2.00: failed to get Identify Device Data, Emask 0x1
ata2.00: configured for UDMA/133
scsi 1:0:0:0: Direct-Access     ATA      ST1500DL003-9VT1 CC32 PQ: 0 ANSI: 5
ata3.00: failed to get Identify Device Data, Emask 0x1
ata3.00: configured for UDMA/133
sd 1:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
scsi 2:0:0:0: Direct-Access     ATA      OCZ VERTEX-TURBO 1.7  PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 2:0:0:0: [sdb] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB)
sd 2:0:0:0: Attached scsi generic sg1 type 0
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
scsi 6:0:0:0: CD-ROM            HL-DT-ST DVD-RAM GH22NP20 1.03 PQ: 0 ANSI: 5
 sdb: sdb1 sdb2
sd 2:0:0:0: [sdb] Attached SCSI disk
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 6:0:0:0: Attached scsi CD-ROM sr0
sr 6:0:0:0: Attached scsi generic sg2 type 5
 sda: unknown partition table
sd 1:0:0:0: [sda] Attached SCSI disk
hub 7-0:1.0: USB hub found
hub 7-0:1.0: 2 ports detected
usbcore: registered new interface driver usblp
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
i8042: PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mousedev: PS/2 mouse device common for all mice
rtc_cmos 00:02: RTC can wake from S4
rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
i2c /dev entries driver
EDAC MC: Ver: 3.0.0
AMD64 EDAC driver v3.4.0
EDAC amd64: DRAM ECC enabled.
EDAC amd64: F10h detected (node 0).
EDAC MC: DCT0 chip selects:
EDAC amd64: MC: 0:  1024MB 1:  1024MB
EDAC amd64: MC: 2:  1024MB 3:  1024MB
EDAC amd64: MC: 4:     0MB 5:     0MB
EDAC amd64: MC: 6:     0MB 7:     0MB
EDAC MC: DCT1 chip selects:
EDAC amd64: MC: 0:  1024MB 1:  1024MB
EDAC amd64: MC: 2:  1024MB 3:  1024MB
EDAC amd64: MC: 4:     0MB 5:     0MB
EDAC amd64: MC: 6:     0MB 7:     0MB
EDAC amd64: using x4 syndromes.
EDAC amd64: MCT channel count: 2
EDAC amd64: CS0: Unbuffered DDR3 RAM
EDAC amd64: CS1: Unbuffered DDR3 RAM
EDAC amd64: CS2: Unbuffered DDR3 RAM
EDAC amd64: CS3: Unbuffered DDR3 RAM
EDAC MC0: Giving out device to 'amd64_edac' 'F10h': DEV 0000:00:18.2
EDAC PCI0: Giving out device to module 'amd64_edac' controller 'EDAC PCI controller': DEV '0000:00:18.2' (POLLED)
cpuidle: using governor ladder
cpuidle: using governor menu
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usb 1-1: new high-speed USB device number 2 using ehci-pci
snd_hda_intel 0000:01:05.1: setting latency timer to 64
hda-codec: No codec parser is available
usbcore: registered new interface driver snd-usb-audio
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
ctnetlink v0.93: registering with nfnetlink.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP: cubic registered
NET: Registered protocol family 17
9pnet: Installing 9P2000 support
registered taskstats version 1
rtc_cmos 00:02: setting system clock to 2012-12-16 13:22:38 UTC (1355664158)
acpi-cpufreq: overriding BIOS provided _PSD data
ALSA device list:
  #0: HDA ATI SB at 0xfbcf4000 irq 16
  #1: HDA ATI HDMI at 0xfbefc000 irq 19
EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 8:18.
devtmpfs: mounted
Freeing unused kernel memory: 444k freed
Write protecting the kernel read-only data: 8192k
Freeing unused kernel memory: 1244k freed
Freeing unused kernel memory: 216k freed
usblp 1-1:1.0: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x06BC pid 0x01C9
EXT4-fs (sdb2): re-mounted. Opts: (null)
EXT4-fs (sda): mounted filesystem with ordered data mode. Opts: (null)
ATL1E 0000:02:00.0: irq 40 for MSI/MSI-X
tsc: Refined TSC clocksource calibration: 3210.827 MHz
Switching to clocksource tsc
usb 4-2: new full-speed USB device number 2 using ohci_hcd
logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-0000:00:12.1-2/input2
input: Logitech Unifying Device. Wireless PID:101b as /devices/pci0000:00/0000:00:12.1/usb4/4-2/4-2:1.2/0003:046D:C52B.0003/input/input0
logitech-djdevice 0003:046D:C52B.0004: input,hidraw1: USB HID v1.11 Mouse [Logitech Unifying Device. Wireless PID:101b] on usb-0000:00:12.1-2:1
usb 4-3: new low-speed USB device number 3 using ohci_hcd
input: HID 046a:0011 as /devices/pci0000:00/0000:00:12.1/usb4/4-3/4-3:1.0/input/input1
hid-generic 0003:046A:0011.0005: input,hidraw2: USB HID v1.10 Keyboard [HID 046a:0011] on usb-0000:00:12.1-3/input0
ATL1E 0000:02:00.0 eth0: NIC Link is Up <100 Mbps Full Duplex>
Adding 4194300k swap on /var/cache/swapfile.img.  Priority:-1 extents:9 across:629080060k 

Re: [GIT PULL] x86/uapi for 3.8

[Matt Fleming]

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?

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Sun, Dec 16, 2012 at 6:54 AM, Matt Fleming <matt.fleming@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

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds
<torvalds@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

Re: [GIT PULL] x86/uapi for 3.8

[H. Peter Anvin]

On 12/16/2012 02:07 PM, Linus Torvalds wrote:
> On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds
> <torvalds@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

Re: [GIT PULL] x86/uapi for 3.8

[Matt Fleming]

On Sun, 2012-12-16 at 14:07 -0800, Linus Torvalds wrote:
> On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds
> <torvalds@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.

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Sun, Dec 16, 2012 at 2:40 PM, Matt Fleming <matt.fleming@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

Re: [GIT PULL] x86/uapi for 3.8

[Markus Trippelsdorf]

On 2012.12.16 at 14:07 -0800, Linus Torvalds wrote:
> On Sun, Dec 16, 2012 at 12:12 PM, Linus Torvalds
> <torvalds@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

Re: [GIT PULL] x86/uapi for 3.8

[Jan Beulich]

>>> On 15.12.12 at 19:35, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf
> <markus@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

Re: [GIT PULL] x86/uapi for 3.8

[Linus Torvalds]

On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich <JBeulich@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

Re: [GIT PULL] x86/uapi for 3.8

[Jan Beulich]

>>> On 17.12.12 at 16:44, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich <JBeulich@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

Re: [GIT PULL] x86/uapi for 3.8

[H. Peter Anvin]

On 12/17/2012 08:00 AM, Jan Beulich wrote:
>>>> On 17.12.12 at 16:44, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich <JBeulich@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

Re: [GIT PULL] x86/uapi for 3.8

[Jan Beulich]

>>> On 17.12.12 at 17:39, "H. Peter Anvin" <hpa@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

Re: [GIT PULL] x86/uapi for 3.8

[H. Peter Anvin]

On 12/17/2012 09:03 AM, Jan Beulich wrote:
>>>> On 17.12.12 at 17:39, "H. Peter Anvin" <hpa@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

Re: [GIT PULL] x86/uapi for 3.8

[Jan Beulich]

>>> On 17.12.12 at 18:15, "H. Peter Anvin" <hpa@linux.intel.com> wrote:
> On 12/17/2012 09:03 AM, Jan Beulich wrote:
>>>>> On 17.12.12 at 17:39, "H. Peter Anvin" <hpa@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