Linux x86_64

• Thread Index

• [PATCH v3 1/1] x86: Support APU5 in PCEngines platform driver
  • From: "Philip Prindeville" <philipp@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH v2 1/1] PCEngines make a number of SBC. APU5 has 5 mpcie slots + MSATA
  • From: "Philip Prindeville" <philipp@xxxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH 1/1] apu6: add apu6 variation to apu2 driver family
  • From: Philip Prindeville <philipp@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH 1/1] apu6: add apu6 variation to apu2 driver family
  • From: <foodeas@xxxxxxxxxxxx>
• Re: [PATCH 1/1] apu6: add apu6 variation to apu2 driver family
  • From: Ed Wildgoose <ed@xxxxxxxxxxxxxx>
• [PATCH 1/1] apu6: add apu6 variation to apu2 driver family
  • From: "Philip Prindeville" <philipp@xxxxxxxxxxxxxxxxxxxxx>
• Re: strange behavior with sigreturn() to 32bit
  • From: "Andy Lutomirski" <luto@xxxxxxxxxx>
• Re: strange behavior with sigreturn() to 32bit
  • From: stsp <stsp2@xxxxxxxxx>
• Re: strange behavior with sigreturn() to 32bit
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• strange behavior with sigreturn() to 32bit
  • From: stsp <stsp2@xxxxxxxxx>
• Re: [PATCH v3] x86/rtc_noop: Remove __init for runtime functions
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
• Re: [PATCH v3] x86/rtc_noop: Remove __init for runtime functions
  • From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@xxxxxxxxx>
• Re: [PATCH v3] x86/rtc_noop: Remove __init for runtime functions
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
• [PATCH v3] x86/rtc_noop: Remove __init for runtime functions
  • From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@xxxxxxxxx>
• Re: [PATCH v2] x86/rtc_noop: Remove init for runtime functions
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
• Re: [PATCH v2] x86/rtc_noop: Remove init for runtime functions
  • From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@xxxxxxxxx>
• Re: [PATCH v2] x86/rtc_noop: Remove init for runtime functions
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
• Re: [PATCH v2] x86/rtc_noop: Remove init for runtime functions
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
• [PATCH v2] x86/rtc_noop: Remove init for runtime functions
  • From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@xxxxxxxxx>
• Re: [PATCH] x86/rtc_noop: Remove init for runtime functions
  • From: Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>
• [PATCH] x86/rtc_noop: Remove init for runtime functions
  • From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@xxxxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Qu Wenruo <quwenruo.btrfs@xxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Qu Wenruo <quwenruo.btrfs@xxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Willy Tarreau <w@xxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Willy Tarreau <w@xxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Qu Wenruo <quwenruo.btrfs@xxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Qu Wenruo <quwenruo.btrfs@xxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Willy Tarreau <w@xxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Qu Wenruo <quwenruo.btrfs@xxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Qu Wenruo <quwenruo.btrfs@xxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Willy Tarreau <w@xxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Qu Wenruo <quwenruo.btrfs@xxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Qu Wenruo <quwenruo.btrfs@xxxxxxx>
• Re: LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• LTS kernel Linux 4.14.290 unable to boot with edk2-ovmf (x86_64 UEFI runtime)
  • From: Qu Wenruo <quwenruo.btrfs@xxxxxxx>
• Re: [PATCH] x86/coco: export cc_mkenc API
  • From: Riccardo Schirone <sirmy15@xxxxxxxxx>
• Re: [PATCH] x86/coco: export cc_mkenc API
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH] x86/coco: export cc_mkenc API
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: [PATCH] x86/coco: export cc_mkenc API
  • From: Riccardo Schirone <sirmy15@xxxxxxxxx>
• Re: [PATCH] x86/coco: export cc_mkenc API
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH] x86/coco: export cc_mkenc API
  • From: Riccardo Schirone <sirmy15@xxxxxxxxx>
• Re: [PATCH] x86/coco: export cc_mkenc API
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• [PATCH] x86/coco: export cc_mkenc API
  • From: Riccardo Schirone <rschirone91@xxxxxxxxx>
• Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: "Andy Lutomirski" <luto@xxxxxxxxxx>
• Re: [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v3 3/3] x86: Add test for arch_prctl(ARCH_VSYSCALL_CONTROL)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v3 3/3] x86: Add test for arch_prctl(ARCH_VSYSCALL_CONTROL)
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: x86, nmi: IOCK error
  • From: "Maciej W. Rozycki" <macro@xxxxxxxxxxx>
• [PATCH v3 3/3] x86: Add test for arch_prctl(ARCH_VSYSCALL_CONTROL)
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• [PATCH v3 2/3] selftests/x86/Makefile: Support per-target $(LIBS) configuration
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• [PATCH v3 1/3] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v2] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH v2] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Andrei Vagin <avagin@xxxxxxxxx>
• [PATCH v2] x86: Implement arch_prctl(ARCH_VSYSCALL_CONTROL) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: "Andy Lutomirski" <luto@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: "Andy Lutomirski" <luto@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: "Andy Lutomirski" <luto@xxxxxxxxxx>
• [PATCH] x86: Implement arch_prctl(ARCH_VSYSCALL_LOCKOUT) to disable vsyscall
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: x86, nmi: IOCK error
  • From: Muni Sekhar <munisekharrms@xxxxxxxxx>
• Re: x86, nmi: IOCK error
  • From: Jeffrey Walton <noloader@xxxxxxxxx>
• x86, nmi: IOCK error
  • From: Muni Sekhar <munisekharrms@xxxxxxxxx>
• Re: [PATCH] x86/amd_nb: add AMD family 19h model 50h PCI ids
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH] x86/amd_nb: add AMD family 19h model 50h PCI ids
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH] x86/amd_nb: add AMD family 19h model 50h PCI ids
  • From: Wei Huang <wei.huang2@xxxxxxx>
• Re: [PATCH] x86/amd_nb: add AMD family 19h model 50h PCI ids
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH] x86/amd_nb: add AMD family 19h model 50h PCI ids
  • From: Wei Huang <wei.huang2@xxxxxxx>
• Re: [PATCH] x86/amd_nb: add AMD family 19h model 50h PCI ids
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH] x86/amd_nb: add AMD family 19h model 50h PCI ids
  • From: Wei Huang <wei.huang2@xxxxxxx>
• [PATCH] x86/amd_nb: add AMD family 19h model 50h PCI ids
  • From: David Bartley <andareed@xxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Rich Felker <dalias@xxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Rich Felker <dalias@xxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Rich Felker <dalias@xxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• [PATCH v2] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: [PATCH] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: [PATCH] x86: Fix x32 System V message queue syscalls
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• [PATCH] x86: Fix x32 System V message queue syscalls
  • From: Jessica Clarke <jrtc27@xxxxxxxxxx>
• Re: Mysterious gaps in Intel cores
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Mysterious gaps in Intel cores
  • From: John Ousterhout <ouster@xxxxxxxxxxxxxxx>
• Check for preemption only when returning from interrupt ?
  • From: Taeung Song <treeze.taeung@xxxxxxxxx>
• Re: [Bug report] Kernel 5.7 become unbootable
  • From: Mikhail Gavrilov <mikhail.v.gavrilov@xxxxxxxxx>
• Re: [Bug report] Kernel 5.7 become unbootable
  • From: Arvind Sankar <nivedita@xxxxxxxxxxxx>
• Re: [Bug report] Kernel 5.7 become unbootable
  • From: Mikhail Gavrilov <mikhail.v.gavrilov@xxxxxxxxx>
• Re: [Bug report] Kernel 5.7 become unbootable
  • From: Arvind Sankar <nivedita@xxxxxxxxxxxx>
• Re: [Bug report] Kernel 5.7 become unbootable
  • From: Like Xu <like.xu@xxxxxxxxxxxxxxx>
• [Bug report] Kernel 5.7 become unbootable
  • From: Mikhail Gavrilov <mikhail.v.gavrilov@xxxxxxxxx>
• Re: [PATCH 3/5] x86/vmware: Steal time clock for VMware guest
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 3/5] x86/vmware: Steal time clock for VMware guest
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH 0/5] x86/vmware: Steal time accounting support
  • From: Alexey Makhalov <amakhalov@xxxxxxxxxx>
• Re: [PATCH 0/5] x86/vmware: Steal time accounting support
  • From: Borislav Petkov <bp@xxxxxxxxx>
• Re: [PATCH 0/5] x86/vmware: Steal time accounting support
  • From: Alexey Makhalov <amakhalov@xxxxxxxxxx>
• Re: [PATCH 0/5] x86/vmware: Steal time accounting support
  • From: Borislav Petkov <bp@xxxxxxxxx>
• [PATCH 2/5] x86/vmware: Remove vmware_sched_clock_setup()
  • From: Alexey Makhalov <amakhalov@xxxxxxxxxx>
• [PATCH 3/5] x86/vmware: Steal time clock for VMware guest
  • From: Alexey Makhalov <amakhalov@xxxxxxxxxx>
• [PATCH 0/5] x86/vmware: Steal time accounting support
  • From: Alexey Makhalov <amakhalov@xxxxxxxxxx>
• [PATCH 1/5] x86/vmware: Make vmware_select_hypercall() __init
  • From: Alexey Makhalov <amakhalov@xxxxxxxxxx>
• [PATCH 5/5] x86/vmware: Use bool type for vmw_sched_clock
  • From: Alexey Makhalov <amakhalov@xxxxxxxxxx>
• [PATCH 4/5] x86/vmware: Enable steal time accounting
  • From: Alexey Makhalov <amakhalov@xxxxxxxxxx>
• Re: [Ask for Help]LBR usage in kernel
  • From: "Xu, Like" <like.xu@xxxxxxxxx>
• [Ask for Help]LBR usage in kernel
  • From: 陈弋玺 <jasoncyx@xxxxxxx>
• "oneshot" interrupt causes another interrupt to be fired erroneously in Intel Haswell system
  • From: Kar Hin Ong <kar.hin.ong@xxxxxx>
• RE: Re: "oneshot" interrupt causes another interrupt to be fired erroneously in Haswell system
  • From: Kar Hin Ong <kar.hin.ong@xxxxxx>
• RE: Re: "oneshot" interrupt causes another interrupt to be fired erroneously in Haswell system
  • From: Kar Hin Ong <kar.hin.ong@xxxxxx>
• Re: "oneshot" interrupt causes another interrupt to be fired erroneously in Haswell system
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• RE: Re: "oneshot" interrupt causes another interrupt to be fired erroneously in Haswell system
  • From: Kar Hin Ong <kar.hin.ong@xxxxxx>
• Re: "oneshot" interrupt causes another interrupt to be fired erroneously in Haswell system
  • From: Bjorn Helgaas <helgaas@xxxxxxxxxx>
• "oneshot" interrupt causes another interrupt to be fired erroneously in Haswell system
  • From: Kar Hin Ong <kar.hin.ong@xxxxxx>
• Re: [PATCH] doc: x86: fix MSR_K8_SYSCFG value in amd-memory-encryption.rst
  • From: "Phillips, Kim" <kim.phillips@xxxxxxx>
• [PATCH] doc: x86: fix MSR_K8_SYSCFG value in amd-memory-encryption.rst
  • From: Clement Sciascia <clement.sciascia@xxxxxxxxxxxx>
• Do DMA mappings get cleared on suspend?
  • From: Paul Pawlowski <mrarmdev@xxxxxxxxx>
• Firing an interrupt pin induces the occurrence of another interrupt
  • From: Kar Hin Ong <kar.hin.ong@xxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Detecting the availability of VSYSCALL
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Detecting the availability of VSYSCALL
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Question about mitigating Zombieload
  • From: zvuln <zvuln@xxxxxxxxxxxxxx>
• Re: Device Description for FPGA Components on x86 system
  • From: "Enrico Weigelt, metux IT consult" <lkml@xxxxxxxxx>
• Re: Device Description for FPGA Components on x86 system
  • From: Federico Vaga <federico.vaga@xxxxxxx>
• Re: Device Description for FPGA Components on x86 system
  • From: Alan Tull <atull@xxxxxxxxxx>
• Re: Device Description for FPGA Components on x86 system
  • From: Federico Vaga <federico.vaga@xxxxxxx>
• Re: Device Description for FPGA Components on x86 system
  • From: Eric Schwarz <eas@xxxxxxxxxxxxxxxxxxx>
• Re: Device Description for FPGA Components on x86 system
  • From: Federico Vaga <federico.vaga@xxxxxxx>
• Device Description for FPGA Components on x86 system
  • From: Federico Vaga <federico.vaga@xxxxxxx>
• Re: [PATCH 1/1] x86/boot/compressed/64: Set EFER.LME=1 in 32-bit trampoline code before returning to long mode
  • From: Wei Huang <wei@xxxxxxxxxx>
• Re: [PATCH 1/1] x86/boot/compressed/64: Set EFER.LME=1 in 32-bit trampoline code before returning to long mode
  • From: Benjamin Gilbert <bgilbert@xxxxxxxxxx>
• Re: [PATCH 1/1] x86/boot/compressed/64: Set EFER.LME=1 in 32-bit trampoline code before returning to long mode
  • From: Wei Huang <wei@xxxxxxxxxx>
• Re: [BUG]Uncalibrated TSC is not accurate enough as a time keeper
  • From: Florian Weimer <fw@xxxxxxxxxxxxx>
• [BUG]Uncalibrated TSC is not accurate enough as a time keeper
  • From: Da Shi Cao <dscao999@xxxxxxxxx>
• Re: thread stalls on broadwell systems
  • From: Florian Weimer <fw@xxxxxxxxxxxxx>
• thread stalls on broadwell systems
  • From: "Cao, Lei" <Lei.Cao@xxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Dmitry Malkin <d.malkin@xxxxxxxxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Dmitry Malkin <d.malkin@xxxxxxxxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Dmitry Malkin <d.malkin@xxxxxxxxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Benjamin Gilbert <bgilbert@xxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Gabriel C <nix.or.die@xxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Gabriel C <nix.or.die@xxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Benjamin Gilbert <bgilbert@xxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Benjamin Gilbert <bgilbert@xxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Bernhard Rosenkraenzer" <bero@xxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Gabriel C <nix.or.die@xxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Benjamin Gilbert <bgilbert@xxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>
• Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
  • From: Benjamin Gilbert <bgilbert@xxxxxxxxxx>
• Re: [PATCH 00/11] Add support for Hygon's Dhyana Family 18h processor
  • From: Borislav Petkov <bp@xxxxxxxxx>
• [PATCH 10/11] driver/edac: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 04/11] x86/perf: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 08/11] driver/acpi: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 02/11] x86/pci: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 07/11] x86/xen: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 09/11] driver/cpufreq: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 06/11] x86/kvm: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 05/11] x86/mce: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 03/11] x86/cpu/bug: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 00/11] Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 01/11] x86/cpu: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• [PATCH 11/11] tools/cpupower: Add support for Hygon's Dhyana Family 18h processor
  • From: Pu Wen <puwen@xxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] selftests/x86: Detect -no-pie availability
  • From: Shuah Khan <shuah@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] selftests/x86: Detect -no-pie availability
  • From: Shuah Khan <shuah@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• [PATCH] pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• [PATCH] selftests/x86: Detect -no-pie availability
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• [PATCH] selftests/x86: Detect -no-pie availability
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: [REGRESSION] testing/selftests/x86/ pkeys build failures
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [REGRESSION] testing/selftests/x86/ pkeys build failures (was: Re: [PATCH] mm, x86: pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics)
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• Re: [REGRESSION] testing/selftests/x86/ pkeys build failures
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• [REGRESSION] testing/selftests/x86/ pkeys build failures (was: Re: [PATCH] mm, x86: pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics)
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• [PATCH] mm, x86: pkeys: Introduce PKEY_ALLOC_SIGNALINHERIT and change signal semantics
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Ram Pai <linuxram@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: pkeys: Support setting access rights for signal handlers
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• pkeys: Support setting access rights for signal handlers
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: MPK: pkey_free and key reuse
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: MPK: removing a pkey
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: MPK: pkey_free and key reuse
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: MPK: pkey_free and key reuse
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: MPK: pkey_free and key reuse
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: MPK: removing a pkey
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: MPK: removing a pkey
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: MPK: removing a pkey
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: MPK: removing a pkey (was: pkey_free and key reuse)
  • From: Vlastimil Babka <vbabka@xxxxxxx>
• Re: MPK: pkey_free and key reuse
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• Re: MPK: pkey_free and key reuse
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: MPK: pkey_free and key reuse
  • From: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
• MPK: pkey_free and key reuse
  • From: Florian Weimer <fweimer@xxxxxxxxxx>
• Re: Debugging hung Xeon platform... nmi_watchdog=1 not helping
  • From: Jonathon Reinhart <jonathon.reinhart@xxxxxxxxx>
• Re: Debugging hung Xeon platform... nmi_watchdog=1 not helping
  • From: Adrien Mahieux <adrien.mahieux@xxxxxxxxx>
• Debugging hung Xeon platform... nmi_watchdog=1 not helping
  • From: Philip Prindeville <philipp_subx@xxxxxxxxxxxxxxxxxxxxx>
• Re: um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU
  • From: Thomas Meyer <thomas@xxxxxxxx>
• Re: um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU
  • From: Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx>
• Re: um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU
  • From: Richard Weinberger <richard@xxxxxx>
• Re: um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU
  • From: Richard Weinberger <richard@xxxxxx>
• Re: um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU
  • From: Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx>
• Re: um: PTRACE_SETREGSET failure with XSTATE on Kabylake CPU
  • From: Richard Weinberger <richard@xxxxxx>
• Re: WARNING: CPU: 0 PID: 1752 at arch/x86/kernel/traps.c:788
  • From: Richard Weinberger <richard@xxxxxx>
• Re: WARNING: CPU: 0 PID: 1752 at arch/x86/kernel/traps.c:788
  • From: Paolo Bonzini <pbonzini@xxxxxxxxxx>
• Re: WARNING: CPU: 0 PID: 1752 at arch/x86/kernel/traps.c:788
  • From: Andy Lutomirski <luto@xxxxxxxxxx>
• Get NMI debug details
  • From: Adrien Mahieux <adrien.mahieux@xxxxxxxxx>
• WARNING: CPU: 0 PID: 1752 at arch/x86/kernel/traps.c:788
  • From: Richard Weinberger <richard@xxxxxx>
• Re: Getting the way a SIGSEGV append when catching a SIGSEGV from within
  • From: Richard Weinberger <richard@xxxxxx>
• Re: Getting the way a SIGSEGV append when catching a SIGSEGV from within
  • From: none <ytrezq@xxxxxxxxxx>
• Re: Getting the way a SIGSEGV append when catching a SIGSEGV from within
  • From: Richard Weinberger <richard.weinberger@xxxxxxxxx>
• Getting the way a SIGSEGV append when catching a SIGSEGV from within
  • From: none <ytrezq@xxxxxxxxxx>
• Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• RE: Kernel crashes in __migration_entry_wait
  • From: Dashi DS1 Cao <caods1@xxxxxxxxxx>
• Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>
• RIP saved during GP processing and backtrace
  • From: Dashi DS1 Cao <caods1@xxxxxxxxxx>
• Re: [x86-64] Compressed kernel does not boot when built with binutils 2.27 and CONFIG_RELOCATABLE is not set
  • From: "H.J. Lu" <hjl.tools@xxxxxxxxx>
• [x86-64] Compressed kernel does not boot when built with binutils 2.27 and CONFIG_RELOCATABLE is not set
  • From: Carlos Chinea <carlos.chinea@xxxxxxxxx>
• Re: [x86-64] Compressed kernel does not boot when built with binutils 2.27 and CONFIG_RELOCATABLE is not set
  • From: Carlos Chinea <carlos.chinea@xxxxxxxxx>
• Re: [x86-64] Compressed kernel does not boot when built with binutils 2.27 and CONFIG_RELOCATABLE is not set
  • From: "H.J. Lu" <hjl.tools@xxxxxxxxx>
• Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• RE: Kernel crashes in __migration_entry_wait
  • From: "Odzioba, Lukasz" <lukasz.odzioba@xxxxxxxxx>
• Kernel crashes in __migration_entry_wait
  • From: Dashi DS1 Cao <caods1@xxxxxxxxxx>
• Protection Fault in __migration_entry_wait
  • From: Dashi DS1 Cao <caods1@xxxxxxxxxx>
• Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [kernel-hardening] [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: "ZhaoJunmin Zhao(Junmin)" <zhaojunmin@xxxxxxxxxx>
• Re: [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• [RFC PATCH v3 2/2] xpfo: Only put previous userspace pages into the hot cache
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• [RFC PATCH v3 1/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• [RFC PATCH v3 0/2] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• Re: [kernel-hardening] [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• Re: [kernel-hardening] [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [kernel-hardening] [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Mark Rutland <mark.rutland@xxxxxxx>
• Re: [RFC PATCH v2 3/3] block: Always use a bounce buffer when XPFO is enabled
  • From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
• Re: [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• [RFC PATCH v2 1/3] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• [RFC PATCH v2 3/3] block: Always use a bounce buffer when XPFO is enabled
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• Re: [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• Re: [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache
  • From: Dave Hansen <dave.hansen@xxxxxxxxx>
• [RFC PATCH v2 2/3] xpfo: Only put previous userspace pages into the hot cache
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• [RFC PATCH v2 3/3] block: Always use a bounce buffer when XPFO is enabled
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• [RFC PATCH v2 1/3] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• [RFC PATCH v2 0/3] Add support for eXclusive Page Frame Ownership (XPFO)
  • From: Juerg Haefliger <juerg.haefliger@xxxxxxx>
• Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
• Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx>
• Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• [added to the 3.18 stable tree] x86/mm/kmmio: Fix mmiotrace for hugepages
  • From: Sasha Levin <sasha.levin@xxxxxxxxxx>
• [added to the 4.1 stable tree] x86/mm/kmmio: Fix mmiotrace for hugepages
  • From: Sasha Levin <sasha.levin@xxxxxxxxxx>
• Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• [PATCH 4.5 160/200] x86/mm/kmmio: Fix mmiotrace for hugepages
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH 4.4 137/163] x86/mm/kmmio: Fix mmiotrace for hugepages
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• Re: [Nouveau] RFC: [PATCH] x86/kmmio: fix mmiotrace for hugepages
  • From: Pierre Moreau <pierre.morrow@xxxxxxx>
• Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: "Michael S. Tsirkin" <mst@xxxxxxxxxx>
• Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: Ingo Molnar <mingo@xxxxxxxxxx>
• x86 memory barrier: why does Linux prefer MFENCE to Locked ADD?
  • From: Dexuan Cui <decui@xxxxxxxxxxxxx>
• RFC: [PATCH] x86/kmmio: fix mmiotrace for hugepages
  • From: Karol Herbst <nouveau@xxxxxxxxxxxxxx>
• kernel 4.4.0 OOPS: "x86/mm: Found insecure W+X mapping at address ..."
  • From: suse.dev@xxxxxx
• Re: [PATCH] x86, msr: Save an instruction in amd64 rdtsc, rdmsr, and
  • From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
• Re: [PATCH] x86, msr: Save an instruction in amd64 rdtsc, rdmsr, and
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [PATCH] x86, msr: Save an instruction in amd64 rdtsc, rdmsr, and
  • From: Borislav Petkov <bp@xxxxxxx>
• Re: [PATCH] x86, msr: Save an instruction in amd64 rdtsc, rdmsr, and
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH] x86, msr: Save an instruction in amd64 rdtsc, rdmsr, and
  • From: Andy Lutomirski <luto@xxxxxxxxxxxxxx>
• Re: [PATCH] x86, msr: Save an instruction in amd64 rdtsc, rdmsr, and
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• Re: [PATCH] x86, msr: Save an instruction in amd64 rdtsc, rdmsr, and
  • From: Borislav Petkov <bp@xxxxxxx>
• [PATCH] x86, msr: Save an instruction in amd64 rdtsc, rdmsr, and
  • From: "George Spelvin" <linux@xxxxxxxxxxx>
• one core Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
  • From: Rafał Sanocki <rafal.sanocki@xxxxxxxxx>
• possible copyright infringement
  • From: Ali AlipourR <alipoor90@xxxxxxxxx>
• [PATCHv3 00/10] ACCESS_ONCE and non-scalar accesses
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• Re: [PATCHv2 04/10] x86/spinlock: Replace ACCESS_ONCE with READ_ONCE/ASSIGN_ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 00/10] ACCESS_ONCE and non-scalar accesses
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 01/10] KVM: s390: Fix ipte locking
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 02/10] kernel: Provide READ_ONCE and ASSIGN_ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 04/10] x86/spinlock: Replace ACCESS_ONCE with READ_ONCE/ASSIGN_ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 05/10] x86: Replace ACCESS_ONCE in gup with READ_ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 07/10] arm64: Replace ACCESS_ONCE for spinlock code with READ_ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 03/10] mm: replace ACCESS_ONCE with READ_ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 09/10] tighten rules for ACCESS ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 06/10] mips: Replace ACCESS_ONCE in gup with READ_ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 08/10] arm: Replace ACCESS_ONCE for spinlock code with READ_ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCHv2 10/10] KVM: s390: change ipte lock from barrier to READ_ONCE
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: David Howells <dhowells@xxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• Re: [PATCH/RFC 6/7] arm64: Replace ACCESS_ONCE for spinlock code with barriers
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: David Howells <dhowells@xxxxxxxxxx>
• [PATCH/RFC 3/7] x86: Rework ACCESS_ONCE for spinlock code
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCH/RFC 5/7] mips: Replace ACCESS_ONCE in gup with a barrier
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCH/RFC 0/7] ACCESS_ONCE and non-scalar accesses
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCH/RFC 6/7] arm64: Replace ACCESS_ONCE for spinlock code with barriers
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCH/RFC 2/7] mm: replace page table access via ACCESS_ONCE with barriers
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCH 1/7] KVM: s390: Fix ipte locking
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCH/RFC 4/7] x86: Replace ACCESS_ONCE in gup with a barrier
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCH/RFC 7/7] kernel: Force ACCESS_ONCE to work only on scalar types
  • From: Christian Borntraeger <borntraeger@xxxxxxxxxx>
• [PATCH v6 3/7] x86: wire up preadv2 and pwritev2
  • From: Milosz Tanski <milosz@xxxxxxxxx>
• [PATCH v5 3/7] x86: wire up preadv2 and pwritev2
  • From: Milosz Tanski <milosz@xxxxxxxxx>
• RE: Reducing dependence on BIOS for allocating memory at PCI root port?
  • From: Rajat Jain <rajatjain@xxxxxxxxxxx>
• Re: Reducing dependence on BIOS for allocating memory at PCI root port?
  • From: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
• Reducing dependence on BIOS for allocating memory at PCI root port?
  • From: Rajat Jain <rajatjain@xxxxxxxxxxx>
• Re: Displaylink Attached Display Adapater and Monitor Not Recognized
  • From: Dennis Gesker <dennis@xxxxxxxxxx>
• Displaylink Attached Display Adapater and Monitor Not Recognized -- 2nd Try
  • From: Dennis Gesker <dennis@xxxxxxxxxx>
• Displaylink Attached Display Adapater and Monitor Not Recognized
  • From: Dennis Gesker <dennis@xxxxxxxxxx>
• RE: [Question] Why should we check irq_fpu_usable before accessing using ASENI instructions.
  • From: justin mattock <justin.mattock@xxxxxxxxxxx>
• [Question] Why should we check irq_fpu_usable before accessing using ASENI instructions.
  • From: Guruswamy Basavaiah <guru2018@xxxxxxxxx>
• Re: flush_dcache_page from user space.
  • From: Arun KS <getarunks@xxxxxxxxx>
• Re: flush_dcache_page from user space.
  • From: ratheesh kannoth <ratheesh.ksz@xxxxxxxxx>
• Re: flush_dcache_page from user space.
  • From: Arun KS <getarunks@xxxxxxxxx>
• flush_dcache_page from user space.
  • From: ratheesh kannoth <ratheesh.ksz@xxxxxxxxx>
• how to use memmap= option
  • From: Long Wind <longwind2009@xxxxxxxxx>
• ft1000-usb staging driver fix for kernel-3.10.17-x86_64
  • From: Martin Sechny <martin.sechny@xxxxxxxx>
• ia32 emulation on Pentium I
  • From: Dmitry Mikushin <dmitry@xxxxxxxxxxxxx>
• [PATCH] x86/mm/numa: fix becoming single node on numa machine with 32-bit kernel.
  • From: Lans Zhang <jia.zhang@xxxxxxxxxxxxx>
• Re: debugging x86 kernel using a hardware debugger
  • From: Manish yippie <manishtestg@xxxxxxxxx>
• Re: debugging x86 kernel using a hardware debugger
  • From: Zhenzhong Duan <zhenzhong.duan@xxxxxxxxxx>
• debugging x86 kernel using a hardware debugger
  • From: Manish yippie <manishtestg@xxxxxxxxx>
• [PATCH] x86-64: fix too early pointer increment
  • From: Mike Marciniszyn <mike.marciniszyn@xxxxxxxxx>
• [PATCH] x86_64: use __BOOT_DS instead_of __KERNEL_DS for safety.
  • From: gmail <lans.zhang2008@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: Mike Bakhterev <mike.bakhterev@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: Mike Bakhterev <mike.bakhterev@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: Mike Bakhterev <mike.bakhterev@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: Mike Bakhterev <mike.bakhterev@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: Mike Bakhterev <mike.bakhterev@xxxxxxxxx>
• Re: PROBLEM: i5-3317u MCE during UEFI boot
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• PROBLEM: i5-3317u MCE during UEFI boot
  • From: Mike Bakhterev <mike.bakhterev@xxxxxxxxx>
• Boot message with 3.6: Fast TSC calibration failed
  • From: Ralf Jung <post@xxxxxxxx>
• Question on shared memory across processes with Linux/x86_64
  • From: Super Groomers <supergroomers@xxxxxxxxx>
• Strange performance difference i386/x86_64
  • From: Brian Candler <brian@xxxxxxxxxxxxxx>
• PROT_NONE mappings
  • From: admin@xxxxxxxxxxx
• low cpu usage,hihg load average
  • From: sky <sky@xxxxxxxxx>
• Re: CPU clock throttled prints..
  • From: "Justin P. Mattock" <justinmattock@xxxxxxxxx>
• Re: CPU clock throttled prints..
  • From: Chen Gong <gong.chen@xxxxxxxxxxxxxxx>
• Re: [PATCH] cpu idle ticks show twice in xen pvm guest
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: [PATCH] cpu idle ticks show twice in xen pvm guest
  • From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
• Re: [PATCH] cpu idle ticks show twice in xen pvm guest
  • From: Ferenc Wagner <wferi@xxxxxxx>
• Re: [PATCH] enable pvhvm vcpu placement in kernel
  • From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
• Re: [PATCH] enable pvhvm vcpu placement in kernel
  • From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
• Re: [PATCH] cpu idle ticks show twice in xen pvm guest
  • From: DuanZhenzhong <zhenzhong.duan@xxxxxxxxxx>
• Re: [PATCH] cpu idle ticks show twice in xen pvm guest
  • From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
• Re: [PATCH] cpu idle ticks show twice in xen pvm guest
  • From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
• [PATCH] cpu idle ticks show twice in xen pvm guest
  • From: Zhenzhong Duan <zhenzhong.duan@xxxxxxxxxx>
• CPU clock throttled prints..
  • From: "R, Durgadoss" <durgadoss.r@xxxxxxxxx>
• re: CPU clock throttled prints..
  • From: "R, Durgadoss" <durgadoss.r@xxxxxxxxx>
• compatible with X86_32 and X86_64
  • From: zheng.zhijian@xxxxxxxxxx
• Re: Interrupt while fetching data from memory or PCIe memory mapped devices
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Interrupt while fetching data from memory or PCIe memory mapped devices
  • From: Ricardo Martínez <rmartinez@xxxxxxxxxxxx>
• Re: Fwd: Re: Boot failure 2.6.33 - 2.6.33-git12 - 2.6.34-rc2 inclusive
  • From: Sid Boyce <sboyce@xxxxxxxxxxxxxxxx>
• Re: Fwd: Re: Boot failure 2.6.33 - 2.6.33-git12 - 2.6.34-rc2 inclusive
  • From: Sid Boyce <sboyce@xxxxxxxxxxxxxxxx>
• Re: Fwd: Re: Boot failure 2.6.33 - 2.6.33-git12 inclusive
  • From: Sid Boyce <sboyce@xxxxxxxxxxxxxxxx>
• Fwd: Re: Boot failure 2.6.33 - 2.6.33-git12 inclusive
  • From: Sid Boyce <sboyce@xxxxxxxxxxxxxxxx>
• %fs base in x86-64
  • From: Eduardo Cruz <eduardohmdacruz@xxxxxxxxx>
• AMD64 multicore problem
  • From: "S.Beck" <sebastian.bw@xxxxxxxxxx>
• Re: [PATCH 0/4] x86-64: fix vclock_gettime()
  • From: Petr Tesarik <ptesarik@xxxxxxx>
• Re: [PATCH 0/4] x86-64: fix vclock_gettime()
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Re: [PATCH 0/4] x86-64: fix vclock_gettime()
  • From: Petr Tesarik <ptesarik@xxxxxxx>
• Re: [PATCH 0/4] x86-64: fix vclock_gettime()
  • From: Petr Tesarik <ptesarik@xxxxxxx>
• Re: [PATCH 0/4] x86-64: fix vclock_gettime()
  • From: Andi Kleen <andi@xxxxxxxxxxxxxx>
• Support for 32bit pointers in long mode
  • From: Goswin von Brederlow <goswin-v-b@xxxxxx>
• Re: [PATCH 1/2] x86: Add getter/setter static inlines for x86 descriptors
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH 1/2] x86: Add getter/setter static inlines for x86 descriptors
  • From: Joe Damato <ice799@xxxxxxxxx>
• Re: [PATCH 1/2] x86: Add getter/setter static inlines for x86 descriptors
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• [PATCH 2/2] x86: Replace direct access to descriptor fields with getter/setters
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 1/2] x86: Add getter/setter static inlines for x86 descriptors
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 0/2] x86: Remove direct access to internal x86 descriptor fields
  • From: Joe Damato <ice799@xxxxxxxxx>
• Re: [PATCH 09/12] x86: Add static initiazlier for descriptors
  • From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
• Re: [PATCH 12/12] x86: Use struct fields instead of bitmasks
  • From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
• Re: [PATCH 04/12] x86: Add macros for gate_desc
  • From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
• Re: [PATCH 02/12] x86: Use new gate_struct for gate_desc
  • From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
• Re: [PATCH 03/12] x86: Cleanup usage of struct desc_struct
  • From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
• Re: [PATCH 00/12] x86: Cleanup idt, gdt/ldt/tss structs
  • From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
• Re: [PATCH 00/12] x86: Cleanup idt, gdt/ldt/tss structs
  • From: Joe Damato <ice799@xxxxxxxxx>
• Re: [PATCH 00/12] x86: Cleanup idt, gdt/ldt/tss structs
  • From: "H. Peter Anvin" <hpa@xxxxxxxxx>
• Re: [PATCH 00/12] x86: Cleanup idt, gdt/ldt/tss structs
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 00/12] x86: Cleanup idt, gdt/ldt/tss structs
  • From: Ingo Molnar <mingo@xxxxxxx>
• Re: [PATCH 00/12] x86: Cleanup idt, gdt/ldt/tss structs
  • From: walter harms <wharms@xxxxxx>
• Re: [PATCH 00/12] x86: Cleanup idt, gdt/ldt/tss structs
  • From: Willy Tarreau <w@xxxxxx>
• [PATCH 01/12] x86: Cleanup x86 descriptors, remove a/b fields from structs
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 04/12] x86: Add macros for gate_desc
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 08/12] x86: Use static intializer for IDT entries
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 11/12] x86: Use macros for getting/setting descriptors
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 12/12] x86: Use struct fields instead of bitmasks
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 03/12] x86: Cleanup usage of struct desc_struct
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 10/12] x86: Use static initializers for descriptors
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 07/12] x86: Add a static initializer for IDTs
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 09/12] x86: Add static initiazlier for descriptors
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 06/12] x86: Refactor pack_descriptor
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 05/12] x86: Refactor pack_gate for gate_desc
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 00/12] x86: Cleanup idt, gdt/ldt/tss structs
  • From: Joe Damato <ice799@xxxxxxxxx>
• [PATCH 02/12] x86: Use new gate_struct for gate_desc
  • From: Joe Damato <ice799@xxxxxxxxx>
• Re: x86: newb question - how to build everything which deps on x86
  • From: Chris Snook <csnook@xxxxxxxxxx>
• x86: newb question - how to build everything which deps on x86
  • From: Joe Damato <ice799@xxxxxxxxx>
• Re: initrd problem with AMD opteron dual core
  • From: Andi Kleen <ak@xxxxxxx>
• Re: initrd problem with AMD opteron dual core
  • From: Sergio Monteiro Basto <sergio@xxxxxxxxxxxxxxxxxx>
• initrd problem with AMD opteron dual core
  • From: jean-francois simon <jfs@xxxxxxxxxx>
• Re: Only 3348 MB of a 4 GB memory?
  • From: Andi Kleen <ak@xxxxxxx>
• Only 3348 MB of a 4 GB memory?
  • From: "Jared C. Davis" <jared@xxxxxxxxxxxxx>
• escape key
  • From: James Lockie <bjlockie@xxxxxxxxx>
• Best way to declare a symbol table and register it with the kernel?
  • From: "Rajesh Bhattacharya" <rajesh.bhattacharya@xxxxxxxxx>
• Re: [PATCH] x86_64: Do not use -ffunction-sections for modules
  • From: Andi Kleen <ak@xxxxxxx>
• Re: [discuss] [PATCH] [40/66] x86_64: Quieten down microcode update driver
  • From: Andi Kleen <ak@xxxxxxx>
• RE: [discuss] [PATCH] [40/66] x86_64: Quieten down microcode update driver
  • From: "Jin, Gordon" <gordon.jin@xxxxxxxxx>
• Re: [discuss] [PATCH] [40/66] x86_64: Quieten down microcode update driver
  • From: Andi Kleen <ak@xxxxxxx>
• RE: [discuss] [PATCH] [40/66] x86_64: Quieten down microcode update driver
  • From: "Jin, Gordon" <gordon.jin@xxxxxxxxx>
• Re: [PATCH] [65/66] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets
  • From: Dave Jones <davej@xxxxxxxxxx>
• Re: [PATCH] [65/66] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets
  • From: Andi Kleen <ak@xxxxxxx>
• Re: [PATCH] [65/66] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets
  • From: Dave Jones <davej@xxxxxxxxxx>
• Re: [PATCH] [65/66] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets
  • From: Andi Kleen <ak@xxxxxxx>
• Re: [PATCH] [65/66] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets
  • From: Dave Jones <davej@xxxxxxxxxx>
• Re: [PATCH] [65/66] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets
  • From: Andi Kleen <ak@xxxxxxx>
• Re: [PATCH] [40/66] x86_64: Quieten down microcode update driver
  • From: Tigran Aivazian <tigran_aivazian@xxxxxxxxxxxx>
• Re: [PATCH] [65/66] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets
  • From: Dave Jones <davej@xxxxxxxxxx>
• Re: [PATCH] [2/66] x86_64: Quieten hangcheck driver
  • From: Joel Becker <Joel.Becker@xxxxxxxxxx>
• Re: [PATCH] [2/66] x86_64: Quieten hangcheck driver
  • From: Andi Kleen <ak@xxxxxxx>
• Re: [PATCH] [2/66] x86_64: Quieten hangcheck driver
  • From: Joel Becker <Joel.Becker@xxxxxxxxxx>
• Re: [PATCH] [2/66] x86_64: Quieten hangcheck driver
  • From: Andi Kleen <ak@xxxxxxx>
• Re: [PATCH] [2/66] x86_64: Quieten hangcheck driver
  • From: Joel Becker <Joel.Becker@xxxxxxxxxx>
• Re: [PATCH] [2/66] x86_64: Quieten hangcheck driver
  • From: Andi Kleen <ak@xxxxxxx>
• Re: [PATCH] [2/66] x86_64: Quieten hangcheck driver
  • From: Joel Becker <Joel.Becker@xxxxxxxxxx>
• [PATCH] [66/66] x86_64: Enable SIS AGP driver on x86-64 for EM64T systems
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [65/66] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [64/66] x86_64: Handle empty PXMs that only contain hotplug memory
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [63/66] x86_64: Reserve SRAT hotadd memory on x86-64
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [62/66] x86_64: Support memory hotadd without sparsemem
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [61/66] x86_64: Report SIGSEGV for IRET faults
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [60/66] x86_64: Initialize powernow_data[] for all siblings
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [58/66] x86_64: group memnodemap and memnodeshift in a memnode structure
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [59/66] x86_64: Remove bogus special case in AMD core parsing.
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [57/66] x86_64: Eliminate register_die_notifier symbol exported
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [56/66] x86_64: Search K8 devices on more devices.
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [55/66] x86_64: Make local_t 64bit instead of 32bit
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [54/66] x86_64: Make GART_IOMMU kconfig help text more specific (trivial)
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [52/66] cpufreq: Fix handling for CPU hotplug
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [53/66] x86_64: Remove CONFIG_UNORDERED_IO
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [51/66] x86_64: Let the cpufreq driver manage AMD Dual-Core CPUs being tied together.
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [50/66] i386/x86-64: List Intel LaGrange AKA SMX in /proc/cpuinfo
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [49/66] x86_64: free_bootmem_node needs __pa in allocate_aperture
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [48/66] x86_64: timer interrupt lockup due to pending interrupt
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [47/66] x86_64: Use cpumask bitops for cpu_vm_mask
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [46/66] x86_64: Try to allocate node memmap near the end of node
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [45/66] x86_64: Force broadcast timer on AMD systems with C3 too.
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [44/66] x86_64: Change default setting for noexec32 to match i386 kernel
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [39/66] x86_64: Basic reorder infrastructure
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [43/66] x86_64: Reorder one field of the PDA to reduce padding
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [42/66] x86_64: Limit max number of CPUs to 255
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [41/66] x86_64: fix orphaned bits of timer init messages
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [40/66] x86_64: Quieten down microcode update driver
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [38/66] x86_64: Always use IO-APIC routing for timer.
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [37/66] x86_64: Don't invoke OOM killer during dma_alloc_coherent()
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [36/66] x86_64: Don't invoke OOM killer while allocating floppy DMA buffers
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [35/66] x86_64: Reename CMOS update warning
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [34/66] x86_64: Fix formatting in time.c
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [33/66] x86_64: Handle years beyond 2100
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [32/66] x86_64: Patch to make the head.S-must-be-first-in-vmlinux order explicit
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [31/66] x86_64: Add __init to fixmap functions that are only called during boot
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [30/66] x86_64: Implement early DMI scanning
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [29/66] x86_64: Clean up and tweak ACPI blacklist year code
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [28/66] x86_64: s/Overwrite/Override/ in arch/x86-64
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [26/66] x86_64: prefetch the mmap_sem in the fault path
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [27/66] x86_64: Move kernel to 2MB
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [24/66] x86_64: to use lapic ids instead of initial apic ids
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [25/66] x86_64: Implement compat code for raw1394 read/write
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [21/66] x86_64: Clean up white space in traps.c
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [23/66] x86_64: miscellaneous cleanup
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [22/66] x86_64: Make pfn_valid work early in boot
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [20/66] x86_64: Fix wrong PCI ID for ALI M1695 AGP bridge
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [19/66] x86_64: Don't define string functions to builtin
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [18/66] x86_64: Check that early arguments are words on their own
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [17/66] x86_64: remove dead do_softirq_thunk
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [16/66] x86_64: actively synchronize vmalloc area when registering certain callbacks
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [15/66] x86_64: Use cpu_relax in poll loop in GART IOMMU
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [14/66] x86_64: Report local APIC ID when initializing CPU
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [13/66] x86_64: Don't need to read PIT in timer handler when PM timer is used
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [12/66] x86_64: cleanup allocating logical cpu numbers in x86_64
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [11/66] x86_64: save FPU context slightly later
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [10/66] x86_64: eliminate set_debug()
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [9/66] x86_64: disallow multi-byte hardware execution breakpoints
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [8/66] x86_64: cpu_pda array to macro followup correction
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [7/66] x86_64: Rename struct node in x86-64 NUMA code to struct boot node
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [6/66] x86_64: {set,clear,test}_bit() related cleanup
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [3/66] x86_64: Use correct PUD for memory hotadd
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [4/66] x86-64: Use -mtune=generic for generic kernels
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [1/66] x86_64: Update defconfig
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [5/66] x86_64: Increase the variability of the process stack on 64bit architectures
  • From: "Andi Kleen" <ak@xxxxxxx>
• [PATCH] [2/66] x86_64: Quieten hangcheck driver
  • From: "Andi Kleen" <ak@xxxxxxx>
• 2.6.17 merge status & review
  • From: Andi Kleen <ak@xxxxxxx>