Re: [PATCH 2/2] Fix efi_call

On Thu, May 12, 2016 at 12:41:49PM +0100, Matt Fleming wrote: > On Wed, 11 May, at 02:55:45PM, Alex Thorlton wrote: > Nice. Your fix looks good, so I've put it in the urgent queue and > tagged it for stable. Great! Thanks, Matt. - Alex

Re: [PATCH 2/2] Fix efi_call

On Thu, May 12, 2016 at 12:41:49PM +0100, Matt Fleming wrote: > On Wed, 11 May, at 02:55:45PM, Alex Thorlton wrote: > Nice. Your fix looks good, so I've put it in the urgent queue and > tagged it for stable. Great! Thanks, Matt. - Alex

Re: [PATCH 2/2] Fix efi_call

On Thu, May 12, 2016 at 08:48:35AM +0200, Ingo Molnar wrote: > I suppose the SGI/UV code is the only one using 7 arguments or more? Might > make > sense to point that out in the changelog. First off, to everybody, sorry for the delayed responses. I've been AFK for a few days and forgot to set

Re: [PATCH 2/2] Fix efi_call

On Thu, May 12, 2016 at 08:48:35AM +0200, Ingo Molnar wrote: > I suppose the SGI/UV code is the only one using 7 arguments or more? Might > make > sense to point that out in the changelog. First off, to everybody, sorry for the delayed responses. I've been AFK for a few days and forgot to set

[tip:efi/urgent] x86/efi: Fix 7th argument to efi_call()

Commit-ID: bea23c757f66d91dac8fdadd94da0cba6b0b66bc Gitweb: http://git.kernel.org/tip/bea23c757f66d91dac8fdadd94da0cba6b0b66bc Author: Alex Thorlton <athorl...@sgi.com> AuthorDate: Fri, 13 May 2016 21:34:42 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 16

[tip:efi/urgent] x86/efi: Fix 7th argument to efi_call()

Commit-ID: bea23c757f66d91dac8fdadd94da0cba6b0b66bc Gitweb: http://git.kernel.org/tip/bea23c757f66d91dac8fdadd94da0cba6b0b66bc Author: Alex Thorlton AuthorDate: Fri, 13 May 2016 21:34:42 +0100 Committer: Ingo Molnar CommitDate: Mon, 16 May 2016 12:38:06 +0200 x86/efi: Fix 7th argument

[PATCH 1/2] Create UV efi_call macros

get everyone's thoughts on how we might best reach that goal instead of just trying to come up with a new implementation on my own. By itself, this commit does get our machines booting, but it needs the small fix to the efi_call assembly code for our modules to work. Signed-off-by: Alex Thorlton <

[PATCH 1/2] Create UV efi_call macros

get everyone's thoughts on how we might best reach that goal instead of just trying to come up with a new implementation on my own. By itself, this commit does get our machines booting, but it needs the small fix to the efi_call assembly code for our modules to work. Signed-off-by: Alex Thorlton

[RFC PATCH 0/2] Fix EFI runtime calls on SGI UV

<tra...@sgi.com> Cc: Matt Fleming <m...@codeblueprint.co.uk> Cc: Borislav Petkov <b...@suse.de> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: x...@kernel.org Cc: linux-...@vger.ker

[PATCH 2/2] Fix efi_call

arguments working again. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Dimitri Sivanich <sivan...@sgi.com> Cc: Russ Anderson <r...@sgi.com> Cc: Mike Travis <tra...@sgi.com> Cc: Matt Fleming <m...@codeblueprint.co.uk> Cc: Borislav Petkov <b...@suse.de> Cc:

[PATCH 2/2] Fix efi_call

arguments working again. Signed-off-by: Alex Thorlton Cc: Dimitri Sivanich Cc: Russ Anderson Cc: Mike Travis Cc: Matt Fleming Cc: Borislav Petkov Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: linux-...@vger.kernel.org --- arch/x86/pl

[RFC PATCH 0/2] Fix EFI runtime calls on SGI UV

Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: linux-...@vger.kernel.org Alex Thorlton (2): Create UV efi_call macros Fix efi_call arch/x86/include/asm/efi.h | 3 ++ arch/x86/platform/efi/efi_stub_64.S | 2 +- arch/x86/platform

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, May 09, 2016 at 10:55:24PM +0100, Matt Fleming wrote: > On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote: > > > > If you think we're violating EFI rules by accessing these registers from > > both sides of the fence, please let me know. I'd like to make sure that

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, May 09, 2016 at 10:55:24PM +0100, Matt Fleming wrote: > On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote: > > > > If you think we're violating EFI rules by accessing these registers from > > both sides of the fence, please let me know. I'd like to make sure that

Re: [PATCH] x86/platform/UV: Bring back the call to map_low_mmrs in uv_system_init

On Thu, May 05, 2016 at 09:53:29AM +0200, Ingo Molnar wrote: > I suppose this patch should go upstream via x86/urgent, as both of the > dependent > commits are already upstream: > > d2f7cbe7b26a x86/efi: Runtime services virtual mapping > d394f2d9d8e1 x86/platform/UV: Remove EFI memmap

Re: [PATCH] x86/platform/UV: Bring back the call to map_low_mmrs in uv_system_init

On Thu, May 05, 2016 at 09:53:29AM +0200, Ingo Molnar wrote: > I suppose this patch should go upstream via x86/urgent, as both of the > dependent > commits are already upstream: > > d2f7cbe7b26a x86/efi: Runtime services virtual mapping > d394f2d9d8e1 x86/platform/UV: Remove EFI memmap

[tip:x86/platform] x86/platform/UV: Bring back the call to map_low_mmrs in uv_system_init

Commit-ID: 08914f436bdd2ed60923f49cbc402307aba20fe4 Gitweb: http://git.kernel.org/tip/08914f436bdd2ed60923f49cbc402307aba20fe4 Author: Alex Thorlton <athorl...@sgi.com> AuthorDate: Wed, 4 May 2016 17:39:52 -0500 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu, 5 Ma

[tip:x86/platform] x86/platform/UV: Bring back the call to map_low_mmrs in uv_system_init

Commit-ID: 08914f436bdd2ed60923f49cbc402307aba20fe4 Gitweb: http://git.kernel.org/tip/08914f436bdd2ed60923f49cbc402307aba20fe4 Author: Alex Thorlton AuthorDate: Wed, 4 May 2016 17:39:52 -0500 Committer: Ingo Molnar CommitDate: Thu, 5 May 2016 09:55:02 +0200 x86/platform/UV: Bring back

[PATCH] x86/platform/UV: Bring back the call to map_low_mmrs in uv_system_init

, we're going to add the call to map_low_mmrs back into uv_system_init, and then fix up our EFI runtime calls to use the appropriate page table. For now, UV2+ will still need efi=old_map to boot, but there will be other changes soon that should eliminate the need for this. Signed-off-by: Alex Thorlton &l

[PATCH] x86/platform/UV: Bring back the call to map_low_mmrs in uv_system_init

, we're going to add the call to map_low_mmrs back into uv_system_init, and then fix up our EFI runtime calls to use the appropriate page table. For now, UV2+ will still need efi=old_map to boot, but there will be other changes soon that should eliminate the need for this. Signed-off-by: Alex Thorlton

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Wed, May 04, 2016 at 12:36:36PM +0200, Borislav Petkov wrote: > On Tue, May 03, 2016 at 01:47:51PM -0500, Alex Thorlton wrote: > > I think this will work for us, for the most part. Only issue is that > > the efi_call_virt macro is only accessible from inside > > runti

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Wed, May 04, 2016 at 12:36:36PM +0200, Borislav Petkov wrote: > On Tue, May 03, 2016 at 01:47:51PM -0500, Alex Thorlton wrote: > > I think this will work for us, for the most part. Only issue is that > > the efi_call_virt macro is only accessible from inside > > runti

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Tue, May 03, 2016 at 11:48:20AM +0200, Borislav Petkov wrote: > On Mon, May 02, 2016 at 07:10:36PM -0500, Alex Thorlton wrote: > > +#define uv_call_virt(f, args...) \ > > +({ \ > > +

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Tue, May 03, 2016 at 11:48:20AM +0200, Borislav Petkov wrote: > On Mon, May 02, 2016 at 07:10:36PM -0500, Alex Thorlton wrote: > > +#define uv_call_virt(f, args...) \ > > +({ \ > > +

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, May 02, 2016 at 05:27:19PM -0500, Alex Thorlton wrote: > Thanks for the help. I'll get back to you when I know a bit more about > what's happening with our runtime callbacks! I've made a bit of progress here. I was able to switch over to a very slightly modified version of efi_cal

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, May 02, 2016 at 05:27:19PM -0500, Alex Thorlton wrote: > Thanks for the help. I'll get back to you when I know a bit more about > what's happening with our runtime callbacks! I've made a bit of progress here. I was able to switch over to a very slightly modified version of efi_cal

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, May 02, 2016 at 12:02:22PM +0200, Borislav Petkov wrote: > On Fri, Apr 29, 2016 at 10:41:19AM -0500, Alex Thorlton wrote: > > You can see here that we've made it past the MMR read in uv_system_init, > > but we die inside of our first EFI callback. In this example, it looks

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, May 02, 2016 at 12:02:22PM +0200, Borislav Petkov wrote: > On Fri, Apr 29, 2016 at 10:41:19AM -0500, Alex Thorlton wrote: > > You can see here that we've made it past the MMR read in uv_system_init, > > but we die inside of our first EFI callback. In this example, it looks

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Sat, Apr 30, 2016 at 11:12:09PM +0100, Matt Fleming wrote: > On Fri, 29 Apr, at 10:41:19AM, Alex Thorlton wrote: > > > > You can see here that we've made it past the MMR read in uv_system_init, > > but we die inside of our first EFI callback. In this example, it looks

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Sat, Apr 30, 2016 at 11:12:09PM +0100, Matt Fleming wrote: > On Fri, 29 Apr, at 10:41:19AM, Alex Thorlton wrote: > > > > You can see here that we've made it past the MMR read in uv_system_init, > > but we die inside of our first EFI callback. In this example, it looks

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Thu, Apr 28, 2016 at 02:57:11PM +0200, Borislav Petkov wrote: > > After d2f7cbe7b26a74 ("x86/efi: Runtime services virtual mapping") was > > introduced (I'm sure you remember the BIOS issue we had a while back) we > > had to fall back to using EFI_OLD_MEMMAP, so for a while we relied on > >

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Thu, Apr 28, 2016 at 02:57:11PM +0200, Borislav Petkov wrote: > > After d2f7cbe7b26a74 ("x86/efi: Runtime services virtual mapping") was > > introduced (I'm sure you remember the BIOS issue we had a while back) we > > had to fall back to using EFI_OLD_MEMMAP, so for a while we relied on > >

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Fri, Apr 29, 2016 at 10:01:15AM +0100, Matt Fleming wrote: > On Wed, 27 Apr, at 10:41:32AM, Alex Thorlton wrote: > > > > From what I know, this works because the first PGD entry (the one > > containing the identity mappings) of the trampoline_pgd is shared with &g

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Fri, Apr 29, 2016 at 10:01:15AM +0100, Matt Fleming wrote: > On Wed, 27 Apr, at 10:41:32AM, Alex Thorlton wrote: > > > > From what I know, this works because the first PGD entry (the one > > containing the identity mappings) of the trampoline_pgd is shared with &g

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Thu, Apr 28, 2016 at 12:51:22AM +0200, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 10:41:32AM -0500, Alex Thorlton wrote: > > A bit of digging will tell us that this is the failing line: > > > > m_n_config.v = uv_read_local_mmr(UVH_RH_GAM_CONFIG_MMR ); > > Th

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Thu, Apr 28, 2016 at 12:51:22AM +0200, Borislav Petkov wrote: > On Wed, Apr 27, 2016 at 10:41:32AM -0500, Alex Thorlton wrote: > > A bit of digging will tell us that this is the failing line: > > > > m_n_config.v = uv_read_local_mmr(UVH_RH_GAM_CONFIG_MMR ); > > Th

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Wed, Apr 27, 2016 at 10:41:32AM -0500, Alex Thorlton wrote: Adding Boris to Cc. > Hey guys, > > We've hit an issue that we haven't seen before on recent community > kernels. Hoping that you can provide some insight. > > Late last week I hit this bad paging request in uv_

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Wed, Apr 27, 2016 at 10:41:32AM -0500, Alex Thorlton wrote: Adding Boris to Cc. > Hey guys, > > We've hit an issue that we haven't seen before on recent community > kernels. Hoping that you can provide some insight. > > Late last week I hit this bad paging request in uv_

[BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

Hey guys, We've hit an issue that we haven't seen before on recent community kernels. Hoping that you can provide some insight. Late last week I hit this bad paging request in uv_system_init on one of our small UV systems: 8<--- [0.355998] UV: Found UV2000/3000 hub [0.360088] BUG:

[BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

Hey guys, We've hit an issue that we haven't seen before on recent community kernels. Hoping that you can provide some insight. Late last week I hit this bad paging request in uv_system_init on one of our small UV systems: 8<--- [0.355998] UV: Found UV2000/3000 hub [0.360088] BUG:

Re: [PATCH 14/18] prctl: make PR_SET_THP_DISABLE wait for mmap_sem killable

nd reduce the chances of timely OOM > resolving. Wait for the lock in the killable mode and return with EINTR > if the task got killed while waiting. > > Cc: Alex Thorlton <athorl...@sgi.com> > Acked-by: Vlastimil Babka <vba...@suse.cz> > Signed-off-by: Michal Hocko <

Re: [PATCH 14/18] prctl: make PR_SET_THP_DISABLE wait for mmap_sem killable

s of timely OOM > resolving. Wait for the lock in the killable mode and return with EINTR > if the task got killed while waiting. > > Cc: Alex Thorlton > Acked-by: Vlastimil Babka > Signed-off-by: Michal Hocko Looks good to me - I wrote that bit of code so I think this can get an:

[tip:x86/platform] x86/platform/uv: Disable UV BAU by default

Commit-ID: 1c532e00a0c649ac6f0703e8c2e095c9c1d30625 Gitweb: http://git.kernel.org/tip/1c532e00a0c649ac6f0703e8c2e095c9c1d30625 Author: Alex Thorlton <athorl...@sgi.com> AuthorDate: Thu, 31 Mar 2016 14:18:29 -0500 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 1 Ap

[tip:x86/platform] x86/platform/uv: Disable UV BAU by default

Commit-ID: 1c532e00a0c649ac6f0703e8c2e095c9c1d30625 Gitweb: http://git.kernel.org/tip/1c532e00a0c649ac6f0703e8c2e095c9c1d30625 Author: Alex Thorlton AuthorDate: Thu, 31 Mar 2016 14:18:29 -0500 Committer: Ingo Molnar CommitDate: Fri, 1 Apr 2016 11:45:54 +0200 x86/platform/uv: Disable

[PATCH v2] x86/platform/uv: Disable UV BAU by default

depending on the system version. I've also added a bit of documentation for the new parameter to Documentation/kernel-parameters.txt. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Reviewed-by: Hedi Berriche <h...@sgi.com> Cc: Hedi Berriche <h...@sgi.com> Cc: Thomas Gleixner <t...@lin

[PATCH v2] x86/platform/uv: Disable UV BAU by default

depending on the system version. I've also added a bit of documentation for the new parameter to Documentation/kernel-parameters.txt. Signed-off-by: Alex Thorlton Reviewed-by: Hedi Berriche Cc: Hedi Berriche Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Jonathan Corbet

Re: [PATCH 1/2] Disable UV BAU by default

On Wed, Mar 23, 2016 at 06:20:26PM +0100, Thomas Gleixner wrote: > On Wed, 23 Mar 2016, Alex Thorlton wrote: > > This was actually what I initially wrote, but we decided to go with the > > on/off switch instead, because, in the UV4 time-frame, we're hoping to > > get a

Re: [PATCH 1/2] Disable UV BAU by default

On Wed, Mar 23, 2016 at 06:20:26PM +0100, Thomas Gleixner wrote: > On Wed, 23 Mar 2016, Alex Thorlton wrote: > > This was actually what I initially wrote, but we decided to go with the > > on/off switch instead, because, in the UV4 time-frame, we're hoping to > > get a

Re: [PATCH 1/2] Disable UV BAU by default

On Wed, Mar 23, 2016 at 12:27:44PM +0100, Thomas Gleixner wrote: > On Mon, 21 Mar 2016, Alex Thorlton wrote: > > First of all, please use proper patch prefixes. > > x86/platform/uv: Ah - sorry about that! > And please fold the documentation change into the p

Re: [PATCH 1/2] Disable UV BAU by default

On Wed, Mar 23, 2016 at 12:27:44PM +0100, Thomas Gleixner wrote: > On Mon, 21 Mar 2016, Alex Thorlton wrote: > > First of all, please use proper patch prefixes. > > x86/platform/uv: Ah - sorry about that! > And please fold the documentation change into the p

[PATCH 1/2] Disable UV BAU by default

For several years, the common practice has been to boot UVs with the "nobau" parameter on the command line, to disable the BAU. We've decided that it makes more sense to just disable the BAU by default in the kernel, and provide the option to turn it on, if desired. Signed-off-by: Ale

[PATCH 1/2] Disable UV BAU by default

For several years, the common practice has been to boot UVs with the "nobau" parameter on the command line, to disable the BAU. We've decided that it makes more sense to just disable the BAU by default in the kernel, and provide the option to turn it on, if desired. Signed-off-by: Ale

[PATCH 2/2] Add documentation for the bau parameter

This commit updates kernel-parameters.txt with some information about the new "bau" parameter. Signed-off-by: Alex Thorltlon Cc: Jonathan Corbet Cc: Hedi Berriche Cc: linux-kernel@vger.kernel.org --- Documentation/kernel-parameters.txt | 8

[PATCH 2/2] Add documentation for the bau parameter

This commit updates kernel-parameters.txt with some information about the new "bau" parameter. Signed-off-by: Alex Thorltlon Cc: Jonathan Corbet Cc: Hedi Berriche Cc: linux-kernel@vger.kernel.org --- Documentation/kernel-parameters.txt | 8 1 file changed, 8 insertions(+) diff

[PATCH 0/2] Re-work UV BAU enable/disable logic, add documentation

Hey everyone, This is a fairly simple change to disable the UV BAU by default (see commit message for reasoning) and to add some documentation to kernel-parameters.txt to explain the new parameter. Let me know what you think! Alex Thorlton (2): Disable UV BAU by default Add documentation

[PATCH 0/2] Re-work UV BAU enable/disable logic, add documentation

Hey everyone, This is a fairly simple change to disable the UV BAU by default (see commit message for reasoning) and to add some documentation to kernel-parameters.txt to explain the new parameter. Let me know what you think! Alex Thorlton (2): Disable UV BAU by default Add documentation

Re: [PATCH] Remove EFI memmap quirk for UV2+

On Mon, Dec 14, 2015 at 09:41:58AM +0100, Ingo Molnar wrote: > * Alex Thorlton wrote: > Ok, this looks good to me and I'll apply it if it looks good to Matt as well. Cool! Thanks, Ingo. > Btw., can UV1 users fix this via a BIOS update? Unfortunately, no. This fix was put into

Re: [PATCH] Remove EFI memmap quirk for UV2+

On Mon, Dec 14, 2015 at 09:41:58AM +0100, Ingo Molnar wrote: > * Alex Thorlton <athorl...@sgi.com> wrote: > Ok, this looks good to me and I'll apply it if it looks good to Matt as well. Cool! Thanks, Ingo. > Btw., can UV1 users fix this via a BIOS update? Unfortunately, no. T

[PATCHv2] Remove EFI memmap quirk for UV

Hey guys, This is my second shot at a patch to remove this quirk. This version uses dmi_check_system to determine if we're on a UV that still needs the quirk, to avoid issues on older hardware. Let me know what everyone thinks! Signed-off-by: Alex Thorlton Cc: Thomas Gleixner Cc: Ingo Molnar

[PATCH] Remove EFI memmap quirk for UV2+

at we only apply the special case to UV1 hardware. Signed-off-by: Alex Thorlton Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: Matt Fleming Cc: Dimitri Sivanich Cc: Hedi Berriche Cc: Mike Travis Cc: Len Brown Cc: linux-...@vger.kernel.org ---

[PATCHv2] Remove EFI memmap quirk for UV

Hey guys, This is my second shot at a patch to remove this quirk. This version uses dmi_check_system to determine if we're on a UV that still needs the quirk, to avoid issues on older hardware. Let me know what everyone thinks! Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc:

[PATCH] Remove EFI memmap quirk for UV2+

at we only apply the special case to UV1 hardware. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: x...@kernel.org Cc: Matt Fleming <m...@c

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

On Wed, Nov 18, 2015 at 10:23:16AM +0100, Borislav Petkov wrote: > On Wed, Nov 18, 2015 at 09:00:47AM +0100, Ingo Molnar wrote: > > We should at least check the BIOS version via a DMI quirk and panic in some > > nicely > > informative 'upgrade your BIOS!' way to ease the transition ... > > Or

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

On Wed, Nov 18, 2015 at 10:23:16AM +0100, Borislav Petkov wrote: > On Wed, Nov 18, 2015 at 09:00:47AM +0100, Ingo Molnar wrote: > > We should at least check the BIOS version via a DMI quirk and panic in some > > nicely > > informative 'upgrade your BIOS!' way to ease the transition ... > > Or

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

On Tue, Nov 17, 2015 at 08:32:59PM +0100, Borislav Petkov wrote: > On Mon, Nov 16, 2015 at 11:59:40AM -0600, Alex Thorlton wrote: > > Commit a5d90c923bcf ("x86/efi: Quirk out SGI UV") added a quirk to > > efi_apply_memmap_quirks to force SGI UV systems to fall back

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

On Tue, Nov 17, 2015 at 09:52:08AM +, Matt Fleming wrote: > Awesome! Thanks Alex. > > Can I also close https://bugzilla.kernel.org/show_bug.cgi?id=75021 ? Yep! Thanks, Matt! - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

On Tue, Nov 17, 2015 at 09:52:08AM +, Matt Fleming wrote: > Awesome! Thanks Alex. > > Can I also close https://bugzilla.kernel.org/show_bug.cgi?id=75021 ? Yep! Thanks, Matt! - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH 1/2] Remove EFI memmap quirk for UV

On Tue, Nov 17, 2015 at 08:32:59PM +0100, Borislav Petkov wrote: > On Mon, Nov 16, 2015 at 11:59:40AM -0600, Alex Thorlton wrote: > > Commit a5d90c923bcf ("x86/efi: Quirk out SGI UV") added a quirk to > > efi_apply_memmap_quirks to force SGI UV systems to fall back

[PATCH 1/2] Remove EFI memmap quirk for UV

e function in question. Signed-off-by: Alex Thorlton Acked-by: Mike Travis Acked-by: Russ Anderson Cc: Matt Fleming Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Hedi Berriche Cc: Dimitri Sivanich Cc: x...@kernel.org Cc: linux-...@vger.kernel.org --- arch/x86/platf

[PATCH 2/2] Remove extra mapping code for UV MMRs

These MMRs get mapped in correctly using the new EFI memmap scheme on recent BIOSes, so we no longer need to set up these extra mappings for them. Signed-off-by: Alex Thorlton Acked-by: Mike Travis Acked-by: Russ Anderson Cc: Matt Fleming Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H.

[PATCH 2/2] Remove extra mapping code for UV MMRs

These MMRs get mapped in correctly using the new EFI memmap scheme on recent BIOSes, so we no longer need to set up these extra mappings for them. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Acked-by: Mike Travis <tra...@sgi.com> Acked-by: Russ Anderson <r...@sgi.com>

[PATCH 1/2] Remove EFI memmap quirk for UV

e function in question. Signed-off-by: Alex Thorlton <athorl...@sgi.com> Acked-by: Mike Travis <tra...@sgi.com> Acked-by: Russ Anderson <r...@sgi.com> Cc: Matt Fleming <matt.flem...@intel.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.co

Re: [BUG] Boot hangs at clocksource_done_booting on large configs

On Mon, Aug 31, 2015 at 11:12:12PM +0200, Thomas Gleixner wrote: > On Mon, 31 Aug 2015, Alex Thorlton wrote: > > I was able to hit this issue on 4.2-rc1 with our RTC disabled, to rule > > out any scaling issues related to multiple concurrent reads to our > > RTC's MMR. > &

Re: [BUG] Boot hangs at clocksource_done_booting on large configs

On Mon, Aug 31, 2015 at 11:12:12PM +0200, Thomas Gleixner wrote: > On Mon, 31 Aug 2015, Alex Thorlton wrote: > > I was able to hit this issue on 4.2-rc1 with our RTC disabled, to rule > > out any scaling issues related to multiple concurrent reads to our > > RTC's MMR. > &

Re: [BUG] Boot hangs at clocksource_done_booting on large configs

On Mon, Aug 31, 2015 at 10:32:50PM +0200, Peter Zijlstra wrote: > On Mon, Aug 31, 2015 at 01:04:33PM -0500, Alex Thorlton wrote: > q > > diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c > > index fd643d8..8502521 100644 > > --- a/kernel/stop_machine.c > &g

Re: [BUG] Boot hangs at clocksource_done_booting on large configs

On Mon, Aug 31, 2015 at 01:04:33PM -0500, Alex Thorlton wrote: > I can provide full logs if desired. Full log is here: http://oss.sgi.com/projects/athorlton/harp50-6144-nortc I'd use wget to download it. Probably don't want to try to open the 15M file in your browser :) Also, I've fi

[BUG] Boot hangs at clocksource_done_booting on large configs

Hey guys, We've been hitting issues with machines with 4096 or more logical cores hanging up at clocksource_done_booting, seemingly forever. The problem occurs somewhat intermittently, though it hits more consistently as you increase the core count. We've observed this problem on kernels

[BUG] Boot hangs at clocksource_done_booting on large configs

Hey guys, We've been hitting issues with machines with 4096 or more logical cores hanging up at clocksource_done_booting, seemingly forever. The problem occurs somewhat intermittently, though it hits more consistently as you increase the core count. We've observed this problem on kernels

Re: [BUG] Boot hangs at clocksource_done_booting on large configs

On Mon, Aug 31, 2015 at 01:04:33PM -0500, Alex Thorlton wrote: > I can provide full logs if desired. Full log is here: http://oss.sgi.com/projects/athorlton/harp50-6144-nortc I'd use wget to download it. Probably don't want to try to open the 15M file in your browser :) Also, I've fi

Re: [BUG] Boot hangs at clocksource_done_booting on large configs

On Mon, Aug 31, 2015 at 10:32:50PM +0200, Peter Zijlstra wrote: > On Mon, Aug 31, 2015 at 01:04:33PM -0500, Alex Thorlton wrote: > q > > diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c > > index fd643d8..8502521 100644 > > --- a/kernel/stop_machine.c > &g

Re: [BUG] mellanox IB driver fails to load on large config

On Mon, Jul 20, 2015 at 11:28:03AM -0500, Alex Thorlton wrote: > I've got some time on the large machine later today. I'll give this a > try then. I ran a boot with this patch applied: diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h index 83e80ab..c84aea0

Re: [BUG] mellanox IB driver fails to load on large config

On Thu, Jul 16, 2015 at 09:25:37AM +0300, Or Gerlitz wrote: > On 7/14/2015 11:28 PM, Alex Thorlton wrote: >> >> We see the same exact messages on 4.1-rc8. >> >> > > does this solves the problem? > > > diff --git a/include/linux/mlx4/device.h b/include/li

Re: [BUG] mellanox IB driver fails to load on large config

On Thu, Jul 16, 2015 at 09:25:37AM +0300, Or Gerlitz wrote: On 7/14/2015 11:28 PM, Alex Thorlton wrote: We see the same exact messages on 4.1-rc8. does this solves the problem? diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h index ad31e47..c8ae3b9 100644

Re: [BUG] mellanox IB driver fails to load on large config

On Mon, Jul 20, 2015 at 11:28:03AM -0500, Alex Thorlton wrote: I've got some time on the large machine later today. I'll give this a try then. I ran a boot with this patch applied: diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h index 83e80ab..c84aea0 100644

Re: [BUG] mellanox IB driver fails to load on large config

On Tue, Jul 14, 2015 at 11:06:26PM +0300, Or Gerlitz wrote: > On Tue, Jul 14, 2015 at 9:48 PM, Alex Thorlton wrote: > > On Tue, Jul 14, 2015 at 01:22:34PM -0500, andrew banman wrote: > >> On Sat, Jul 11, 2015 at 11:20:19PM +0300, Or Gerlitz wrote: > >> > On Fri, Ju

Re: [BUG] mellanox IB driver fails to load on large config

On Tue, Jul 14, 2015 at 01:22:34PM -0500, andrew banman wrote: > On Sat, Jul 11, 2015 at 11:20:19PM +0300, Or Gerlitz wrote: > > On Fri, Jul 10, 2015 at 10:15 PM, andrew banman wrote: > > > I'm seeing a large number of allocation errors originating from the > > > Mellanox IB > > > driver when

Re: [BUG] mellanox IB driver fails to load on large config

On Tue, Jul 14, 2015 at 11:06:26PM +0300, Or Gerlitz wrote: On Tue, Jul 14, 2015 at 9:48 PM, Alex Thorlton athorl...@sgi.com wrote: On Tue, Jul 14, 2015 at 01:22:34PM -0500, andrew banman wrote: On Sat, Jul 11, 2015 at 11:20:19PM +0300, Or Gerlitz wrote: On Fri, Jul 10, 2015 at 10:15 PM

Re: [BUG] mellanox IB driver fails to load on large config

On Tue, Jul 14, 2015 at 01:22:34PM -0500, andrew banman wrote: On Sat, Jul 11, 2015 at 11:20:19PM +0300, Or Gerlitz wrote: On Fri, Jul 10, 2015 at 10:15 PM, andrew banman aban...@sgi.com wrote: I'm seeing a large number of allocation errors originating from the Mellanox IB driver when

[tip:sched/urgent] sched: Fix KMALLOC_MAX_SIZE overflow during cpumask allocation

Commit-ID: b74e6278fd6db5848163ccdc6e9d8eb6efdee9bd Gitweb: http://git.kernel.org/tip/b74e6278fd6db5848163ccdc6e9d8eb6efdee9bd Author: Alex Thorlton AuthorDate: Thu, 18 Dec 2014 12:44:30 -0600 Committer: Ingo Molnar CommitDate: Tue, 23 Dec 2014 11:43:48 +0100 sched: Fix

[tip:sched/urgent] sched: Fix KMALLOC_MAX_SIZE overflow during cpumask allocation

Commit-ID: b74e6278fd6db5848163ccdc6e9d8eb6efdee9bd Gitweb: http://git.kernel.org/tip/b74e6278fd6db5848163ccdc6e9d8eb6efdee9bd Author: Alex Thorlton athorl...@sgi.com AuthorDate: Thu, 18 Dec 2014 12:44:30 -0600 Committer: Ingo Molnar mi...@kernel.org CommitDate: Tue, 23 Dec 2014 11:43:48

[PATCHv2] Fix KMALLOC_MAX_SIZE overflow during cpumask allocation

from which they'll most commonly be accessed, to minimize remote accesses on NUMA machines. v2 - Replace a missing #endif to fix some build issues on certain configs Any input is appreciated! - Alex Signed-off-by: Alex Thorlton Suggested-by: George Beshers Cc: George Beshers Cc: Russ Anderson

[PATCHv2] Fix KMALLOC_MAX_SIZE overflow during cpumask allocation

from which they'll most commonly be accessed, to minimize remote accesses on NUMA machines. v2 - Replace a missing #endif to fix some build issues on certain configs Any input is appreciated! - Alex Signed-off-by: Alex Thorlton athorl...@sgi.com Suggested-by: George Beshers gbesh...@sgi.com Cc

Re: [PATCH] Fix KMALLOC_MAX_SIZE overflow during cpumask allocation

On Mon, Dec 08, 2014 at 11:42:14AM +0100, Ingo Molnar wrote: > This patch fails to build with certain configs: > > kernel/sched/core.c:7130:33: error: incompatible types when assigning to type > ‘cpumask_var_t’ from type ‘void *’ Thanks for letting us know, Ingo. I believe George has something

Re: [BUG] kzalloc overflow in lpfc driver on 6k core system

On Sat, Dec 06, 2014 at 03:14:45PM -0500, James Smart wrote: > Myself and several others here at Emulex maintain the code. The > recommendations look fine. Feel free to post something if you beat > us to the work. Great! Thanks for letting me know, James. I will probaby have some time to look

Re: [BUG] kzalloc overflow in lpfc driver on 6k core system

On Sat, Dec 06, 2014 at 03:14:45PM -0500, James Smart wrote: Myself and several others here at Emulex maintain the code. The recommendations look fine. Feel free to post something if you beat us to the work. Great! Thanks for letting me know, James. I will probaby have some time to look at

Re: [PATCH] Fix KMALLOC_MAX_SIZE overflow during cpumask allocation

On Mon, Dec 08, 2014 at 11:42:14AM +0100, Ingo Molnar wrote: This patch fails to build with certain configs: kernel/sched/core.c:7130:33: error: incompatible types when assigning to type ‘cpumask_var_t’ from type ‘void *’ Thanks for letting us know, Ingo. I believe George has something in

Re: [BUG] Possible locking issues in stop_machine code on 6k core machine

On Thu, Dec 04, 2014 at 12:34:04AM +0100, Thomas Gleixner wrote: > first of all, could you please format your mail so it is actually > readable and can be replied to? My fault there - stupid mistake. > If you would provide real data instead of half baken assumptions > we might actually be able

Re: [BUG] Possible locking issues in stop_machine code on 6k core machine

On Thu, Dec 04, 2014 at 12:34:04AM +0100, Thomas Gleixner wrote: first of all, could you please format your mail so it is actually readable and can be replied to? My fault there - stupid mistake. If you would provide real data instead of half baken assumptions we might actually be able to

[BUG] Possible locking issues in stop_machine code on 6k core machine

Hey guys,

Re: [BUG] kzalloc overflow in lpfc driver on 6k core system

On Tue, Dec 02, 2014 at 10:39:40PM +, Elliott, Robert (Server Storage) wrote: > In similar code, mpt3sas and lockless hpsa just call get_cpu_mask() > inside the loop: > cpu = cpumask_first(cpu_online_mask); > for (i = 0; i < h->msix_vector; i++) { > rc =

<    1   2   3   4   5   6   >