Linux Sparc

• Thread Index

• Re: [PATCH] sparc64: Oracle DAX infrastructure
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc64: Oracle DAX infrastructure
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• [PATCH v8 00/11] complete deferred page initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 07/11] sparc64: optimized struct page zeroing
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 02/11] sparc64/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 00/11] complete deferred page initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 08/11] mm: zero reserved and unavailable struct pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 10/11] arm64/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 04/11] sparc64: simplify vmemmap_populate
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 06/11] mm: zero struct pages during initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 09/11] x86/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 05/11] mm: defining memblock_virt_alloc_try_nid_raw
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 03/11] mm: deferred_init_memmap improvements
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 11/11] mm: stop zeroing memory during allocation in vmemmap
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v8 01/11] x86/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [PATCH] sparc64: Oracle DAX infrastructure
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc64: Oracle DAX infrastructure
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH] sparc64: Oracle DAX infrastructure
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc64: Oracle DAX infrastructure
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH] sparc64: Oracle DAX infrastructure
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH] sparc64: Oracle DAX infrastructure
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH V3] vDSO for SPARC
  • From: Nick Alcock <nick.alcock@xxxxxxxxxx>
• Re: [PATCH V3] vDSO for SPARC
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH] sparc64: mmu_context: Add missing include files
  • From: Guenter Roeck <linux@xxxxxxxxxxxx>
• Re: [PATCH V3] vDSO for SPARC
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [GIT] Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Handle additional cases of no fault loads
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Handle additional cases of no fault loads
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH v2] sparc64: Handle additional cases of no fault loads
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH] sparc64: Handle additional cases of no fault loads
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH] sparc64: Handle additional cases of no fault loads
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Steven Sistare <steven.sistare@xxxxxxxxxx>
• [PATCH] sparc64: Handle additional cases of no fault loads
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Pavel Machek <pavel@xxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Anthony Yznaga <anthony.yznaga@xxxxxxxxxx>
• [PATCH v2 0/7] Remove the parent_node() for each arch
  • From: Dou Liyang <douly.fnst@xxxxxxxxxxxxxx>
• [PATCH v2 5/7] sparc64/topology: Remove the unused parent_node() macro
  • From: Dou Liyang <douly.fnst@xxxxxxxxxxxxxx>
• [PATCH 22/31] sparc/led: Use separate static data field with with static timer
  • From: Kees Cook <keescook@xxxxxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: RFC: Driver for Oracle Data Analytics Accelerator
  • From: Alexandre Chartre <alexandre.chartre@xxxxxxxxxx>
• Re: RFC: Driver for Oracle Data Analytics Accelerator
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v7 08/11] mm: zero reserved and unavailable struct pages
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v7 08/11] mm: zero reserved and unavailable struct pages
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH v7 07/11] sparc64: optimized struct page zeroing
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v7 07/11] sparc64: optimized struct page zeroing
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: RFC: Driver for Oracle Data Analytics Accelerator
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: RFC: Driver for Oracle Data Analytics Accelerator
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: RFC: Driver for Oracle Data Analytics Accelerator
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RFC: Driver for Oracle Data Analytics Accelerator
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v7 07/11] sparc64: optimized struct page zeroing
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v7 02/11] sparc64/mm: setting fields in deferred pages
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v7 04/11] sparc64: simplify vmemmap_populate
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RFC: Driver for Oracle Data Analytics Accelerator
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [RFC 2/2] sparc64: Oracle DAX driver
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• [RFC 1/2] sparc64: Oracle DAX infrastructure
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• RFC: Driver for Oracle Data Analytics Accelerator
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH silo] second/tilo: make all inline functions static
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc64: vcc: make ktermios const
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v3 0/3] Define CPU_BIG_ENDIAN or warn for inconsistencies
  • From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
• Re: [PATCH v3 0/3] Define CPU_BIG_ENDIAN or warn for inconsistencies
  • From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH v7 09/11] x86/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 04/11] sparc64: simplify vmemmap_populate
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 07/11] sparc64: optimized struct page zeroing
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 10/11] arm64/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 08/11] mm: zero reserved and unavailable struct pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 02/11] sparc64/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 01/11] x86/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 03/11] mm: deferred_init_memmap improvements
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 06/11] mm: zero struct pages during initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 05/11] mm: defining memblock_virt_alloc_try_nid_raw
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 11/11] mm: stop zeroing memory during allocation in vmemmap
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v7 00/11] complete deferred page initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [PATCH] sparc: leon: grpci1: constify of_device_id
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc: leon: grpci2: constify of_device_id
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH sparc-next] sparc64: vcc: Check for IS_ERR() instead of NULL
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH] sparc64: vcc: make ktermios const
  • From: Bhumika Goyal <bhumirks@xxxxxxxxx>
• Re: [PATCH] Fix compat_sys_sigpending breakage introduced by v4.13-rc1~6^2~12
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH] Fix compat_sys_sigpending breakage introduced by v4.13-rc1~6^2~12
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• [PATCH] sbus: Delete an error message for a failed memory allocation in uctrl_probe()
  • From: SF Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
• [PATCH] sparc: leon: grpci1: constify of_device_id
  • From: Arvind Yadav <arvind.yadav.cs@xxxxxxxxx>
• [PATCH] sparc: leon: grpci2: constify of_device_id
  • From: Arvind Yadav <arvind.yadav.cs@xxxxxxxxx>
• [PATCH sparc-next] sparc64: vcc: Check for IS_ERR() instead of NULL
  • From: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Anthony Yznaga <anthony.yznaga@xxxxxxxxxx>
• Re: [PATCH v2 1/1] futex: remove duplicated code and fix UB
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• [PATCH silo] second/tilo: make all inline functions static
  • From: Aaro Koskinen <aaro.koskinen@xxxxxx>
• Re: [PATCH v2 1/1] futex: remove duplicated code and fix UB
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH v2 1/1] futex: remove duplicated code and fix UB
  • From: Jiri Slaby <jslaby@xxxxxxx>
• Re: Bisected: E3500 crash on boot just befoire v4.8
  • From: Atish Patra <atish.patra@xxxxxxxxxx>
• Re: Bisected: E3500 crash on boot just befoire v4.8
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Bisected: E3500 crash on boot just befoire v4.8
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: arch/sparc/kernel/nmi.c: warning: array subscript is above array bounds
  • From: David Miller <davem@xxxxxxxxxxxxx>
• arch/sparc/kernel/nmi.c: warning: array subscript is above array bounds
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Abdul Haleem <abdhalee@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH resend] timers: Fix excessive granularity of new timers after a nohz idle
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: [PATCH resend] timers: Fix excessive granularity of new timers after a nohz idle
  • From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Meelis Roos <mroos@xxxxxxxx>
• [PATCH resend] timers: Fix excessive granularity of new timers after a nohz idle
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH 1/3] signal: replace sigset_to_compat() with put_compat_sigset()
  • From: "Dmitry V. Levin" <ldv@xxxxxxxxxxxx>
• [GIT] Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: speed up etrap/rtrap on NG2 and later processors
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: mroos@xxxxxxxx
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: David Miller <davem@xxxxxxxxxxxxx>
• RE: [PATCH v3 net 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  • From: "Tantilov, Emil S" <emil.s.tantilov@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: [xfstests, sparc64] git kernel OOPS 4.13.0-rc5+
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• Re: [xfstests, sparc64] git kernel OOPS 4.13.0-rc5+
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [xfstests, sparc64] git kernel OOPS 4.13.0-rc5+
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [xfstests, sparc64] git kernel OOPS 4.13.0-rc5+
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [xfstests, sparc64] git kernel OOPS 4.13.0-rc5+
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• [PATCH v3 net 0/2 RESEND] net: ixgbe: Use new flag to disable Relaxed Ordering
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• [PATCH v3 net 2/2 RESEND] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• [PATCH v3 net 1/2 RESEND] Revert commit 1a8b6d76dc5b ("net:add one common config...")
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• [xfstests, sparc64] git kernel OOPS 4.13.0-rc5+
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• Re: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [PATCH] sparc64: speed up etrap/rtrap on NG2 and later processors
  • From: Greg Onufer <gonufer@xxxxxxxxxxxxx>
• Re: [PATCH] sparc64: speed up etrap/rtrap on NG2 and later processors
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH v2] sparc64: speed up etrap/rtrap on NG2 and later processors
  • From: Anthony Yznaga <anthony.yznaga@xxxxxxxxxx>
• Re: [PATCH] sparc64: speed up etrap/rtrap on NG2 and later processors
  • From: Anthony Yznaga <anthony.yznaga@xxxxxxxxxx>
• [PATCH v3 net 1/2] Revert commit 1a8b6d76dc5b ("net:add one common config...")
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• [PATCH v3 net 0/2] net: ixgbe: Use new flag to disable Relaxed Ordering
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• [PATCH v3 net 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• Re: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• RE: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  • From: "Tantilov, Emil S" <emil.s.tantilov@xxxxxxxxx>
• [PATCH] sparc64: speed up etrap/rtrap on NG2 and later processors
  • From: Anthony Yznaga <anthony.yznaga@xxxxxxxxxx>
• Re: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• Re: [v6 05/15] mm: don't accessed uninitialized struct pages
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 01/15] x86/mm: reserve only exiting low pages
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 05/15] mm: don't accessed uninitialized struct pages
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Meelis Roos <mroos@xxxxxxxx>
• RE: [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  • From: "Tantilov, Emil S" <emil.s.tantilov@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Christoph Hellwig <hch@xxxxxx>
• [PATCH net v2 0/2] net: ixgbe: Use new flag to disable Relaxed Ordering
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• [PATCH net v2 2/2] net: ixgbe: Use new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• [PATCH net v2 1/2] Revert commit 1a8b6d76dc5b ("net:add one common config...")
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• Re: [PATCH net 0/2] net: ixgbe: Use new flag to disable Relaxed Ordering
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Bjorn Helgaas <helgaas@xxxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [PATCH] sparc64: remove unnecessary log message
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH net 2/2] net: ixgbe: Use new IXGBE_FLAG2_ROOT_NO_RELAXED_ORDERING flag
  • From: Alexander Duyck <alexander.duyck@xxxxxxxxx>
• [PATCH] sparc64: remove unnecessary log message
  • From: Tushar Dave <tushar.n.dave@xxxxxxxxxx>
• Re: [PATCH net 0/2] net: ixgbe: Use new flag to disable Relaxed Ordering
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v7 2/9] mm, swap: Add infrastructure for saving page metadata on swap
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• [PATCH net 1/2] Revert commit 1a8b6d76dc5b ("net:add one common config...")
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• [PATCH net 2/2] net: ixgbe: Use new IXGBE_FLAG2_ROOT_NO_RELAXED_ORDERING flag
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• [PATCH net 0/2] net: ixgbe: Use new flag to disable Relaxed Ordering
  • From: Ding Tianhong <dingtianhong@xxxxxxxxxx>
• Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v7 2/9] mm, swap: Add infrastructure for saving page metadata on swap
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v6 0/3] sparc64: Add 16GB hugepage support
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 00/13] Enable Virtual Console Concentrator (VCC)
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2
  • From: Anthony Yznaga <anthony.yznaga@xxxxxxxxxx>
• Re: Niagara2 & Could not register hvapi ATU err=-22
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: Niagara2 & Could not register hvapi ATU err=-22
  • From: Tushar Dave <tushar.n.dave@xxxxxxxxxx>
• [PATCH v2 13/13] sparc64: vcc: Add install & cleanup TTY operations
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 12/13] sparc64: vcc: Add break_ctl TTY operation
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 10/13] sparc64: vcc: Add write & write_room TTY operations
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 09/13] sparc64: vcc: Add hangup TTY operation
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 11/13] sparc64: vcc: Add chars_in_buffer TTY operation
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 08/13] sparc64: vcc: Add open & close TTY operations
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 07/13] sparc64: vcc: Enable LDC event processing engine
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 06/13] sparc64: vcc: Add RX & TX timer for delayed LDC operation
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 04/13] sparc64: vcc: Enable VCC port probe and removal
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 03/13] sparc64: vcc: TTY driver initialization and cleanup
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 02/13] sparc64: vcc: Add VCC debug message macros
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 01/13] sparc64: vcc: Enable VCC module in linux
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 00/13] Enable Virtual Console Concentrator (VCC)
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v2 05/13] sparc64: vcc: Create sysfs attribute group
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [sparc64] kernel OOPS with gcc 7.1 / 7.2
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [sparc64] kernel OOPS with gcc 7.1 / 7.2
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Bjorn Helgaas <helgaas@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• 4.13.0-rc4 sparc64: can't allocate MSI-X affinity masks for 2 vectors
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Niagara2 & Could not register hvapi ATU err=-22
  • From: Meelis Roos <mroos@xxxxxxxx>
• Niagara2 crypto engine questions
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [v6 15/15] mm: debug for raw alloctor
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 05/15] mm: don't accessed uninitialized struct pages
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH V3] vDSO for SPARC
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• Re: [v6 15/15] mm: debug for raw alloctor
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 01/15] x86/mm: reserve only exiting low pages
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 05/15] mm: don't accessed uninitialized struct pages
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 02/15] x86/mm: setting fields in deferred pages
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 01/15] x86/mm: reserve only exiting low pages
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 15/15] mm: debug for raw alloctor
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 05/15] mm: don't accessed uninitialized struct pages
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 02/15] x86/mm: setting fields in deferred pages
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 01/15] x86/mm: reserve only exiting low pages
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH 03/11] serial: sunsab: constify uart_ops structures
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 04/11] serial: sunsu: constify uart_ops structures
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH] sparc: kernel/pcic: silence gcc 7.x warning in pcibios_fixup_bus()
  • From: Thomas Petazzoni <thomas.petazzoni@xxxxxxxxxxxxxxxxxx>
• [PATCH 03/11] serial: sunsab: constify uart_ops structures
  • From: Julia Lawall <Julia.Lawall@xxxxxxx>
• [PATCH 04/11] serial: sunsu: constify uart_ops structures
  • From: Julia Lawall <Julia.Lawall@xxxxxxx>
• Re: [PATCH 2/3] sparc64: Add 16GB hugepage support
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [PATCH 2/3] sparc64: Add 16GB hugepage support
  • From: Xose Vazquez Perez <xose.vazquez@xxxxxxxxx>
• Re: [PATCH v2 0/4] Update memcpy, memset etc. for M7/M8 architectures
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [PATCH v6 2/3] sparc64: Add 16GB hugepage support
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH v6 3/3] sparc64: Cleanup hugepage table walk functions
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH v6 1/3] sparc64: Support huge PUD case in get_user_pages
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH v6 0/3] sparc64: Add 16GB hugepage support
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [sparc-next:master 2/7] arch/sparc/kernel/head_64.S:892: Warning: .space or .fill with negative value, ignored
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 15/15] mm: debug for raw alloctor
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 14/15] mm: optimize early system hash allocations
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 13/15] mm: stop zeroing memory during allocation in vmemmap
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 09/15] sparc64: optimized struct page zeroing
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 08/15] mm: zero struct pages during initialization
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 05/15] mm: don't accessed uninitialized struct pages
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 02/15] x86/mm: setting fields in deferred pages
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 01/15] x86/mm: reserve only exiting low pages
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 00/15] complete deferred page initialization
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 00/15] complete deferred page initialization
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 15/15] mm: debug for raw alloctor
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 14/15] mm: optimize early system hash allocations
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 13/15] mm: stop zeroing memory during allocation in vmemmap
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 09/15] sparc64: optimized struct page zeroing
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 08/15] mm: zero struct pages during initialization
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [PATCH V3] vDSO for SPARC
  • From: Nick Alcock <nick.alcock@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx>
• Re: [v6 05/15] mm: don't accessed uninitialized struct pages
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 04/15] mm: discard memblock data later
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 02/15] x86/mm: setting fields in deferred pages
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 01/15] x86/mm: reserve only exiting low pages
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [v6 00/15] complete deferred page initialization
  • From: Michal Hocko <mhocko@xxxxxxxxxx>
• Re: [sparc-next:master 2/7] arch/sparc/kernel/head_64.S:892: Warning: .space or .fill with negative value, ignored
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [sparc-next:master 2/7] arch/sparc/kernel/head_64.S:892: Warning: .space or .fill with negative value, ignored
  • From: Anthony Yznaga <anthony.yznaga@xxxxxxxxxx>
• Re: [PATCH V3] vDSO for SPARC
  • From: Nagarathnam Muthusamy <nagarathnam.muthusamy@xxxxxxxxxx>
• Re: [PATCH] mm: add pmd_t initializer __pmd() to work around a GCC bug.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH V3] vDSO for SPARC
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc64: update comments in U3memcpy
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH V2] vDSO for SPARC
  • From: Nagarathnam Muthusamy <nagarathnam.muthusamy@xxxxxxxxxx>
• Re: [PATCH v2 0/4] Update memcpy, memset etc. for M7/M8 architectures
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH V3] vDSO for SPARC
  • From: Nagarathnam Muthusamy <nagarathnam.muthusamy@xxxxxxxxxx>
• Re: [PATCH] mm: add pmd_t initializer __pmd() to work around a GCC bug.
  • From: "Zi Yan" <zi.yan@xxxxxxxxxxxxxx>
• Re: [sparc-next:master 2/7] arch/sparc/kernel/head_64.S:892: Warning: .space or .fill with negative value, ignored
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] mm: add pmd_t initializer __pmd() to work around a GCC bug.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• WTD: Hacker for SPARC port of TXR Language
  • From: Kaz Kylheku <kaz@xxxxxxxxxxx>
• Re: [PATCH] mm: add pmd_t initializer __pmd() to work around a GCC bug.
  • From: "Zi Yan" <zi.yan@xxxxxxxxxxxxxx>
• Re: [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• Re: [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()
  • From: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
• [sparc-next:master 2/7] arch/sparc/kernel/head_64.S:892: Warning: .space or .fill with negative value, ignored
  • From: kbuild test robot <fengguang.wu@xxxxxxxxx>
• [GIT] Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sunvdc: prevent sunvdc panic when mpgroup disk added to guest domain
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH V2] vDSO for SPARC
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 0/2] sparc64: Use low latency path to resume idle cpu
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v5 0/3] sparc64: Add 16GB hugepage support
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH v7 6/9] sparc64: Add auxiliary vectors to report platform ADI properties
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• [PATCH v7 2/9] mm, swap: Add infrastructure for saving page metadata on swap
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• [PATCH v7 8/9] mm: Clear arch specific VM flags on protection change
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• [PATCH v7 9/9] sparc64: Add support for ADI (Application Data Integrity)
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• [PATCH v7 0/9] Application Data Integrity feature introduced by SPARC M7
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• [PATCH v7 3/9] sparc64: Add support for ADI register fields, ASIs and traps
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• [PATCH v7 7/9] mm: Add address parameter to arch_validate_prot()
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• [PATCH v7 4/9] sparc64: Add HV fault type handlers for ADI related faults
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• [PATCH v7 1/9] signals, sparc: Add signal codes for ADI violations
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• [PATCH v7 5/9] sparc64: Add handler for "Memory Corruption Detected" trap
  • From: Khalid Aziz <khalid.aziz@xxxxxxxxxx>
• RE: [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Will Deacon <will.deacon@xxxxxxx>
• Re: [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Will Deacon <will.deacon@xxxxxxx>
• [PATCH v2 4/4] arch/sparc: Add accurate exception reporting in M7memcpy
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [PATCH v2 1/4] arch/sparc: Separate the exception handlers from NG4memcpy
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [PATCH v2 0/4] Update memcpy, memset etc. for M7/M8 architectures
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [PATCH v2 2/4] arch/sparc: Rename exception handlers
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [PATCH v2 3/4] arch/sparc: Optimized memcpy, memset, copy_to_user, copy_from_user for M7/M8
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [v6 03/15] sparc64/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 00/15] complete deferred page initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 06/15] sparc64: simplify vmemmap_populate
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 10/15] x86/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 13/15] mm: stop zeroing memory during allocation in vmemmap
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 04/15] mm: discard memblock data later
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 01/15] x86/mm: reserve only exiting low pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 09/15] sparc64: optimized struct page zeroing
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 15/15] mm: debug for raw alloctor
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 08/15] mm: zero struct pages during initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 14/15] mm: optimize early system hash allocations
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 05/15] mm: don't accessed uninitialized struct pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 02/15] x86/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v6 12/15] mm: explicitly zero pagetable memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [PATCH v1 07/13] sparc64: vcc: Enable LDC event processing engine
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v1 06/13] sparc64: vcc: Add RX & TX timer for delayed LDC operation
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] Fix compat_sys_sigpending breakage introduced by v4.13-rc1~6^2~12
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] Fix compat_sys_sigpending breakage introduced by v4.13-rc1~6^2~12
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• [PATCH] Fix compat_sys_sigpending breakage introduced by v4.13-rc1~6^2~12
  • From: "Dmitry V. Levin" <ldv@xxxxxxxxxxxx>
• [PATCH] sparc64: update comments in U3memcpy
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [GIT] Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] uapi: fix another asm/shmbuf.h userspace compilation error
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [v5 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [v5 09/15] sparc64: optimized struct page zeroing
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Mikael Pettersson <mikpelinux@xxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [v5 09/15] sparc64: optimized struct page zeroing
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [v5 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [v5 05/15] mm: don't accessed uninitialized struct pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 12/15] mm: explicitly zero pagetable memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 13/15] mm: stop zeroing memory during allocation in vmemmap
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 14/15] mm: optimize early system hash allocations
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 00/15] complete deferred page initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 02/15] x86/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 06/15] sparc64: simplify vmemmap_populate
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 15/15] mm: debug for raw alloctor
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 03/15] sparc64/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 01/15] x86/mm: reserve only exiting low pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 09/15] sparc64: optimized struct page zeroing
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 04/15] mm: discard memblock data later
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 07/15] mm: defining memblock_virt_alloc_try_nid_raw
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 08/15] mm: zero struct pages during initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v5 10/15] x86/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [PATCH RFC 3/4] arch/sparc: Optimized memcpy, memset, copy_to_user, copy_from_user for M7
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Mikael Pettersson <mikpelinux@xxxxxxxxx>
• [PATCH v1 04/13] sparc64: vcc: Enable VCC port probe and removal
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 13/13] sparc64: vcc: Add install & cleanup TTY operations
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 12/13] sparc64: vcc: Add break_ctl TTY operation
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 10/13] sparc64: vcc: Add write & write_room TTY operations
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 11/13] sparc64: vcc: Add chars_in_buffer TTY operation
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 03/13] sparc64: vcc: TTY driver initialization and cleanup
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 09/13] sparc64: vcc: Add hangup TTY operation
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 06/13] sparc64: vcc: Add RX & TX timer for delayed LDC operation
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 08/13] sparc64: vcc: Add open & close TTY operations
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 07/13] sparc64: vcc: Enable LDC event processing engine
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 05/13] sparc64: vcc: Create sysfs attribute group
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 00/13] Enable Virtual Console Concentrator (VCC)
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 01/13] sparc64: vcc: Enable VCC module in linux
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH v1 02/13] sparc64: vcc: Add VCC debug message macros
  • From: Jag Raman <jag.raman@xxxxxxxxxx>
• [PATCH] mm: add pmd_t initializer __pmd() to work around a GCC bug.
  • From: Zi Yan <zi.yan@xxxxxxxx>
• Re: [v4 09/15] sparc64: optimized struct page zeroing
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [v4 13/15] mm: stop zeroing memory during allocation in vmemmap
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [v4 14/15] mm: optimize early system hash allocations
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: [v4 04/15] mm: discard memblock data later
  • From: kbuild test robot <lkp@xxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [v4 01/15] x86/mm: reserve only exiting low pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 03/15] sparc64/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 09/15] sparc64: optimized struct page zeroing
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 10/15] x86/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 05/15] mm: don't accessed uninitialized struct pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 02/15] x86/mm: setting fields in deferred pages
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 00/15] complete deferred page initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 13/15] mm: stop zeroing memory during allocation in vmemmap
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 11/15] arm64/kasan: explicitly zero kasan shadow memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 14/15] mm: optimize early system hash allocations
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 08/15] mm: zero struct pages during initialization
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 15/15] mm: debug for raw alloctor
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 04/15] mm: discard memblock data later
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 07/15] mm: defining memblock_virt_alloc_try_nid_raw
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 12/15] mm: explicitly zero pagetable memory
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [v4 06/15] sparc64: simplify vmemmap_populate
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: pci: Add generic pcibios_{fixup_bus,align_resource}
  • From: Bjorn Helgaas <helgaas@xxxxxxxxxx>
• Re: Sparc64 kernel rcu_sched stalls
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Sparc64 kernel rcu_sched stalls (was: Reproducer for sparc64 kernel lock-up bug)
  • From: Pierre Muller <pierre@xxxxxxxxxxxxxx>
• Re: [mmotm:master 50/189] include/linux/swapops.h:220:9: error: implicit declaration of function '__pmd'
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [mmotm:master 50/189] include/linux/swapops.h:220:9: error: implicit declaration of function '__pmd'
  • From: "Zi Yan" <zi.yan@xxxxxxxxxxxxxx>
• Re: [mmotm:master 50/189] include/linux/swapops.h:220:9: error: implicit declaration of function '__pmd'
  • From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH] sunhme: fix up GREG_STAT and GREG_IMASK register offsets
  • From: Mark Cave-Ayland <mark.cave-ayland@xxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Mikael Pettersson <mikpelinux@xxxxxxxxx>
• Re: [PATCH] sunhme: fix up GREG_STAT and GREG_IMASK register offsets
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Mikael Pettersson <mikpelinux@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: [PATCH RFC 3/4] arch/sparc: Optimized memcpy, memset, copy_to_user, copy_from_user for M7
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v3] sparc64: Increase max_phys_bits to 51 and VA bits to 53 for M8.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 2/3] sparc64: recognize and support sparc M8 cpu type
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 1/3] sparc64: properly name the cpu constants
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH v5 3/3] sparc64: Cleanup hugepage table walk functions
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH v5 2/3] sparc64: Add 16GB hugepage support
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH v5 1/3] sparc64: Support huge PUD case in get_user_pages
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH v5 0/3] sparc64: Add 16GB hugepage support
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Mikael Pettersson <mikpelinux@xxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Anatoly Pugachev <matorola@xxxxxxxxx>
• Re: [PATCH v3] sparc64: Increase max_phys_bits to 51 and VA bits to 53 for M8.
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• Re: [PATCH v3] sparc64: Increase max_phys_bits to 51 and VA bits to 53 for M8.
  • From: Greg Onufer <greg@xxxxxxxxxxxxx>
• [PATCH v3] sparc64: Increase max_phys_bits to 51 and VA bits to 53 for M8.
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Boqun Feng <boqun.feng@xxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Mikael Pettersson <mikpelinux@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH RFC 3/4] arch/sparc: Optimized memcpy, memset, copy_to_user, copy_from_user for M7
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [PATCH RFC 4/4] arch/sparc: Add accurate exception reporting in M7memcpy
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [PATCH RFC 1/4] arch/sparc: Separate the exception handlers from NG4memcpy
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• [PATCH RFC 2/4] arch/sparc: Rename exception handlers
  • From: Babu Moger <babu.moger@xxxxxxxxxx>
• Re: [PATCH v3 1/3] arch: Define CPU_BIG_ENDIAN for all fixed big endian archs
  • From: Helge Deller <deller@xxxxxx>
• strace-4.18 test suite oopses sparc64 4.12 and 4.13-rc kernels
  • From: Mikael Pettersson <mikpelinux@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• [PATCH] sunhme: fix up GREG_STAT and GREG_IMASK register offsets
  • From: Mark Cave-Ayland <mark.cave-ayland@xxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: Reproducer for sparc64 kernel lock-up bug
  • From: Pierre Muller <pierre@xxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Nicholas Piggin <npiggin@xxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: Reproducer for sparc64 kernel lock-up bug
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: sunhme: incorrect global register offsets?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• sunhme: incorrect global register offsets?
  • From: Mark Cave-Ayland <mark.cave-ayland@xxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/3] sparc64: Increase max_phys_bits to 51 for M8.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/3] sparc64: Add 16GB hugepage support
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 3/3] sparc64: Increase max_phys_bits to 51 for M8.
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• Re: [PATCH 2/3] sparc64: Add 16GB hugepage support
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 08/11] sparc64/topology: Remove the unused parent_node() macro
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• [PATCH 08/11] sparc64/topology: Remove the unused parent_node() macro
  • From: Dou Liyang <douly.fnst@xxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: [PATCH v2 3/3] sparc64: Increase max_phys_bits to 51 for M8.
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx>
• Re: [PATCH v1 0/4] Context domains
  • From: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: [PATCH v1 0/4] Context domains
  • From: Bob Picco <bob.picco@xxxxxxxxxx>
• Re: RCU stall warnings...
  • From: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
• Re: RCU stall warnings...
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU stall warnings...
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• Re: RCU stall warnings...
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: RCU stall warnings...
  • From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
• RCU stall warnings...
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2 3/3] sparc64: Increase max_phys_bits to 51 for M8.
  • From: Allen <allen.pais@xxxxxxxxxx>
• Re: [PATCH v2 3/3] sparc64: Increase max_phys_bits to 51 for M8.
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH v2 3/3] sparc64: Increase max_phys_bits to 51 for M8.
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• [PATCH v2 3/3] sparc64: Increase max_phys_bits to 51 for M8.
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• [PATCH v2 2/3] sparc64: recognize and support sparc M8 cpu type
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• [PATCH v2 1/3] sparc64: properly name the cpu constants
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: Allen <allen.pais@xxxxxxxxxx>
• Re: Reproducer for sparc64 kernel lock-up bug
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Reproducer for sparc64 kernel lock-up bug
  • From: Pierre Muller <pierre@xxxxxxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH v2 2/2] sparc64: Use CPU_POKE to resume idle cpu
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• [PATCH v2 0/2] sparc64: Use low latency path to resume idle cpu
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• [PATCH v2 1/2] sparc64: Add a new hypercall CPU_POKE
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• Re: [PATCH V2] vDSO for SPARC
  • From: Nagarathnam Muthusamy <nagarathnam.muthusamy@xxxxxxxxxx>
• Reproducer for sparc64 kernel lock-up bug
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• [PATCH] sunvdc: prevent sunvdc panic when mpgroup disk added to guest domain
  • From: Jim Quigley <Jim.Quigley@xxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: Richard Mortimer <richm@xxxxxxxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: Allen <allen.pais@xxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: Allen <allen.pais@xxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: Allen <allen.pais@xxxxxxxxxx>
• Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• Re: [PATCH v1 0/4] Context domains
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v1 3/4] sparc64: context domains
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v1 0/4] Context domains
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/3] sparc64: 5-Level page table support for sparc
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• Re: [PATCH 2/2] sparc64: Use cpu_poke to resume idle cpu
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu
  • From: Vijay Kumar <vijay.ac.kumar@xxxxxxxxxx>
• Re: [PATCH V2] vDSO for SPARC
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH v1 2/4] sparc64: tlb mondo replacement with smp_call_function_many
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v1 1/4] sparc64: interface to get random tick
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v1 0/4] Context domains
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v1 3/4] sparc64: context domains
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• [PATCH v1 4/4] sparc64: add boot line core to context domain parameter
  • From: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: jane.chu@xxxxxxxxxx
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: jane.chu@xxxxxxxxxx
• Re: [PATCH] sparc64: prevent sunvdc panic when mpgroup disk added to guest domain
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc64: prevent sunvdc panic when mpgroup disk added to guest domain
  • From: Jim Quigley <jim.quigley@xxxxxxxxxx>
• Re: [PATCH] sparc64: prevent sunvdc panic when mpgroup disk added to guest domain
  • From: Jim Quigley <jim.quigley@xxxxxxxxxx>
• Re: [PATCH 2/3] sparc64: Add 16GB hugepage support
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/2] sparc64: Use cpu_poke to resume idle cpu
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 0/2] sparc64: Use low latency path to resume idle cpu
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH] sparc64: prevent sunvdc panic when mpgroup disk added to guest domain
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• Re: [PATCH] sparc64: Register hugepages during arch init
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [RESEND PATCH] sparc: defconfig: Cleanup from old Kconfig options
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] sparc64: prevent sunvdc panic when mpgroup disk added to guest domain
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH 2/3] sparc64: 5-Level page table support for sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [RESEND PATCH] sparc: defconfig: Cleanup from old Kconfig options
  • From: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: jane.chu@xxxxxxxxxx
• Re: [RESEND PATCH] sparc: defconfig: Cleanup from old Kconfig options
  • From: Sam Ravnborg <sam@xxxxxxxxxxxx>
• [PATCH] sparc64: prevent sunvdc panic when mpgroup disk added to guest domain
  • From: Jim Quigley <Jim.Quigley@xxxxxxxxxx>
• [PATCH 3/3] sparc64: Increase max_phys_bits to 51 for M8.
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• [PATCH 2/3] sparc64: 5-Level page table support for sparc
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• [PATCH 1/3] sparc64: recognize and support sparc M8 cpu type
  • From: Allen Pais <allen.pais@xxxxxxxxxx>
• [RESEND PATCH] sparc: defconfig: Cleanup from old Kconfig options
  • From: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH] sparc64: Register hugepages during arch init
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: [PATCH] sbus: Convert to using %pOF instead of full_name
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] tty: Convert to using %pOF instead of full_name
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH] sbus: Convert to using %pOF instead of full_name
  • From: Rob Herring <robh@xxxxxxxxxx>
• [PATCH] tty: Convert to using %pOF instead of full_name
  • From: Rob Herring <robh@xxxxxxxxxx>
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v3] sparc64: Prevent perf from running during super critical sections
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH 3/7] signal/sparc: Document a conflict with SI_USER with SIGFPE
  • From: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
• Re: [PATCH 3/8] signal/sparc: Document a conflict with SI_USER with SIGFPE
  • From: ebiederm@xxxxxxxxxxxx (Eric W. Biederman)
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: jane.chu@xxxxxxxxxx
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [GIT] Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH v3] sparc64: Prevent perf from running during super critical sections
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH] [PING] Fix TIOCGPTPEER ioctl definition
  • From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
• [PATCH] [PING] Fix TIOCGPTPEER ioctl definition
  • From: Gleb Fotengauer-Malinovskiy <glebfm@xxxxxxxxxxxx>
• Re: [PATCH net-next] sunvnet: add support for IPv6 checksum offloads
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Prevent perf from running during super critical sections
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Prevent perf from running during super critical sections
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Prevent perf from running during super critical sections
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH v2] sparc64: Prevent perf from running during super critical sections
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH v2] sparc64: Prevent perf from running during super critical sections
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [PATCH v2] sparc64: Prevent perf from running during super critical sections
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: [PATCH] sparc64: Prevent perf from running during super critical sections
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• Re: Trying out debian sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Trying out debian sparc64
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Trying out debian sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: Trying out debian sparc64
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Trying out debian sparc64
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: [PATCH] sparc64: Prevent perf from running during super critical sections
  • From: Julian Calaby <julian.calaby@xxxxxxxxx>
• Trying out debian sparc64
  • From: Meelis Roos <mroos@xxxxxxxx>
• [PATCH] sparc64: Prevent perf from running during super critical sections
  • From: Rob Gardner <rob.gardner@xxxxxxxxxx>
• [PATCH 2/3] sparc64: Add 16GB hugepage support
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH 1/3] sparc64: Support huge PUD case in get_user_pages
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH 3/3] sparc64: Cleanup hugepage table walk functions
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• [PATCH 0/3] Add 16GB hugepage support
  • From: Nitin Gupta <nitin.m.gupta@xxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [sparc-next] SPARC64: Fix sun4v DMA panic
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [sparc-next] SPARC64: Fix sun4v DMA panic
  • From: Christoph Hellwig <hch@xxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: Tushar Dave <tushar.n.dave@xxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: David Miller <davem@xxxxxxxxxxxxx>
• [GIT] Sparc
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: Al Viro <viro@xxxxxxxxxxxxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: Tushar Dave <tushar.n.dave@xxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: Tushar Dave <tushar.n.dave@xxxxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: Tushar Dave <tushar.n.dave@xxxxxxxxxx>
• [sparc-next] SPARC64: Fix sun4v DMA panic
  • From: Tushar Dave <tushar.n.dave@xxxxxxxxxx>
• [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: Jane Chu <jane.chu@xxxxxxxxxx>
• Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: Aleksa Sarai <asarai@xxxxxxx>
• RE: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: David Laight <David.Laight@xxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: James Hogan <james.hogan@xxxxxxxxxx>
• Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: Arnd Bergmann <arnd@xxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: Aleksa Sarai <asarai@xxxxxxx>
• [PATCH] tty: Fix TIOCGPTPEER ioctl definition
  • From: Gleb Fotengauer-Malinovskiy <glebfm@xxxxxxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: tndave <tushar.n.dave@xxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: sun4v+DMA related boot crash on 4.13-git
  • From: tndave <tushar.n.dave@xxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: David Miller <davem@xxxxxxxxxxxxx>
• Re: [PATCH] arch/sparc: Measure receiver forward progress to avoid send mondo timeout
  • From: jane.chu@xxxxxxxxxx
• sun4v+DMA related boot crash on 4.13-git
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: in:imklog segfault in 4.12+git on most sparc64's
  • From: John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx>
• in:imklog segfault in 4.12+git on most sparc64's
  • From: Meelis Roos <mroos@xxxxxxxx>
• Re: Spontaneous reboots seem to have been fixed - not
  • From: Meelis Roos <mroos@xxxxxxxx>