On Fri, Mar 17, 2017 at 10:21:58AM +0800, Aaron Lu wrote:
> On Thu, Mar 16, 2017 at 02:38:44PM -0500, Alex Thorlton wrote:
> > On Wed, Mar 15, 2017 at 04:59:59PM +0800, Aaron Lu wrote:
> > > v2 changes: Nothing major, only minor ones.
> > > - rebased on top of v4.11
On Wed, Mar 15, 2017 at 04:59:59PM +0800, Aaron Lu wrote:
> v2 changes: Nothing major, only minor ones.
> - rebased on top of v4.11-rc2-mmotm-2017-03-14-15-41;
> - use list_add_tail instead of list_add to add worker to tlb's worker
>list so that when doing flush, the first queued worker gets
callback.
Signed-off-by: Alex Thorlton
Suggested-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Cc: Russ Anderson
Cc: David Vrabel
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: Denys Vlasenko
Cc: Boris Ostrovsky
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org
tions/comments!
Alex Thorlton (2):
x86: Make E820_X_MAX unconditionally larger than E820MAX
xen/x86: Increase xen_e820_map to E820_X_MAX possible entries
arch/x86/include/asm/e820.h | 12
arch/x86/xen/setup.c| 6 +++---
2 files changed, 11 insertions(+), 7 dele
where the XENMEM_machine_memory_map hypercall can
produce an e820 map larger than 128 entries, even on systems where the
original e820 table was quite a bit smaller than that, depending on how
many IOAPICs are installed on the system.
Signed-off-by: Alex Thorlton
Suggested-by: Ingo Molnar
Cc: Rus
On Wed, Nov 30, 2016 at 07:21:48AM +0100, Ingo Molnar wrote:
>
> * Alex Thorlton wrote:
>
> > It's really not necessary to limit E820_X_MAX to 128 in the non-EFI
> > case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that
> > E820_X_MAX is
where the XENMEM_machine_memory_map hypercall can
produce an e820 map larger than 128 entries, even on systems where the
original e820 table was quite a bit smaller than that, depending on how
many IOAPICs are installed on the system.
Signed-off-by: Alex Thorlton
Suggested-by: Ingo Molnar
Cc: Rus
callback.
Signed-off-by: Alex Thorlton
Suggested-by: Boris Ostrovsky
Cc: Russ Anderson
Cc: David Vrabel
Cc: Ingo Molnar
Cc: Juergen Gross
Cc: Thomas Gleixner
Cc: "H. Peter Anvin"
Cc: Denys Vlasenko
Cc: Boris Ostrovsky
Cc: x...@kernel.org
Cc: xen-de...@lists.xenproject.org
---
ar
ciate any input that others can give!
- Alex
Alex Thorlton (2):
x86: Make E820_X_MAX unconditionally larger than E820MAX
xen/x86: Increase xen_e820_map to E820_X_MAX possible entries
arch/x86/include/asm/e820.h | 8 +++-
arch/x86/xen/setup.c| 6 +++---
2 files changed, 6 insert
e changed it to
> 1ULL << m_io.
>
> This code is over three years old so presumably the bug doesn't happen
> very frequently in real life or someone would have complained by now.
>
> Signed-off-by: Dan Carpenter
> Cc: Alex Thorlton
Acked-by: Alex Thorlton
- Alex
On Tue, Nov 15, 2016 at 10:55:49AM +0100, Juergen Gross wrote:
> I'd go with the new error code. What about E2BIG or ENOSPC?
>
> I think the hypervisor should fill in the number of entries required
> in this case.
>
> In case nobody objects I can post patches for this purpose (both Xen
> and Linu
That being said, there isn't exactly a "more
appropriate" macro/variable to use, so this may not really be an issue.
Any input on the patch, or the questions I've raised above is greatly
appreciated!
- Alex
Alex Thorlton (1):
xen/x86: Increase xen_e820_map to E820_X_MAX poss
Commit-ID: caef78b6cdeddf4ad364f95910bba6b43b8eb9bf
Gitweb: http://git.kernel.org/tip/caef78b6cdeddf4ad364f95910bba6b43b8eb9bf
Author: Alex Thorlton
AuthorDate: Wed, 19 Oct 2016 20:48:51 -0500
Committer: Ingo Molnar
CommitDate: Thu, 20 Oct 2016 08:47:58 +0200
x86/platform/UV: Fix
.flags. If it is set, we fall back to
using our old callback method, which uses efi_call directly on the __va
of our function pointer.
v2: Invert if-statement and add unlikely() hint.
Signed-off-by: Alex Thorlton
Cc: Mike Travis
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: Thomas Gleixner
C
On Wed, Oct 19, 2016 at 12:32:00PM +0100, Matt Fleming wrote:
> Could you please invert the conditional? I had to read it 3 times to
> make sure it was correct given the comment that precedes it. E.g. this
> is preferable,
>
> if (efi_enabled(EFI_OLD_MEMMAP))
> ret = efi_call((
.flags. If it is set, we fall back to
using our old callback method, which uses efi_call directly on the __va
of our function pointer.
Signed-off-by: Alex Thorlton
Cc: Mike Travis
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote:
> > > Why do you guys need the physical mapping all of a sudden?
> >
> > It's not that we need it all of the sudden, necessarily, it's just that
> > we've had to make other changes to make things work with the new,
> > (almost) completely
On Tue, Aug 16, 2016 at 07:50:10AM +0200, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:47:31PM -0500, Alex Thorlton wrote:
> > The only thing we're adding here is the physical mappings, to match
> > what is availble in the primary kernel.
>
> I can see what it do
On Mon, Aug 15, 2016 at 05:07:09PM +0200, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
> > (Cc'ing Boris and Dave)
> >
> > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> > > This is a simple change to add in t
Commit-ID: f72075c9eda8a43aeea2f9dbb8d187afd4a76f0b
Gitweb: http://git.kernel.org/tip/f72075c9eda8a43aeea2f9dbb8d187afd4a76f0b
Author: Alex Thorlton
AuthorDate: Thu, 11 Aug 2016 11:41:59 +0100
Committer: Ingo Molnar
CommitDate: Thu, 11 Aug 2016 13:55:36 +0200
x86/platform/uv: Skip UV
Maybe this time?
On Fri, Aug 05, 2016 at 06:59:35PM -0500, Alex Thorlton wrote:
> This is a simple change to add in the physical mappings as well as the
> virtual mappings in efi_map_region_fixed. The motivation here is to
> get access to EFI runtime code that is only available via the 1:1
> mappings
first __map_region
that Boris put in efi_map_region in commit d2f7cbe7b26a ("x86/efi:
Runtime services virtual mapping").
Signed-off-by: Alex Thorlton
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: Mike Travis
Cc: Matt Fleming
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H.
On Thu, Aug 04, 2016 at 10:25:32AM +0100, Matt Fleming wrote:
> On Mon, 01 Aug, at 09:34:10AM, Alex Thorlton wrote:
> >
> > Hmm... That's a good point. It certainly would be nice for us to have
> > those mappings in the kexec kernel, at least for the time being. If
On Mon, Aug 01, 2016 at 09:28:06AM -0500, Alex Thorlton wrote:
> So, it definitely needs to go in for v4.8, but it's kind of a toss-up
> for the older kernels. I'll discuss this with the other guys around
> here to see what they think, and get back to you a bit later, if th
On Mon, Aug 01, 2016 at 02:39:26PM +0100, Matt Fleming wrote:
> On Tue, 26 Jul, at 05:38:32PM, Alex Thorlton wrote:
> >
> > After investigating the problem here and figuring out the proper way to
> > get the noefi parameter working again, I noticed that there appears to
&
On Mon, Aug 01, 2016 at 02:49:57PM +0100, Matt Fleming wrote:
> On Tue, 26 Jul, at 05:38:33PM, Alex Thorlton wrote:
> > This problem has actually been in the UV code for a while, but we didn't
> > catch it until recently, because we had been relying on EFI_OLD_MEMMAP
> &g
hecking for efi_runtime_disabled in
uv_bios_init, we end up trying to do EFI runtime callbacks when we
shouldn't be. This patch just adds a check for efi_runtime_disabled in
uv_bios_init so that we don't map in uv_systab when runtime_disabled ==
true.
Signed-off-by: Alex Thorlton
Cc: Russ An
es of
the descriptors as well as the virtual addresses in
efi_map_region_fixed, but the more "correct" fix would be to update
our system table pointer to its new virtual address during
SetVirtualAddressMap. We intend to get that piece fixed up relatively
soon, but haven't quite gotte
Commit-ID: 21f866257c7027f8f49bfde83f559f9e58f9ee93
Gitweb: http://git.kernel.org/tip/21f866257c7027f8f49bfde83f559f9e58f9ee93
Author: Alex Thorlton
AuthorDate: Sat, 25 Jun 2016 08:20:29 +0100
Committer: Ingo Molnar
CommitDate: Mon, 27 Jun 2016 13:06:57 +0200
x86/efi: Update efi_thunk
Commit-ID: d1be84a232e359ca9456c63e72cb0082d68311b6
Gitweb: http://git.kernel.org/tip/d1be84a232e359ca9456c63e72cb0082d68311b6
Author: Alex Thorlton
AuthorDate: Sat, 25 Jun 2016 08:20:28 +0100
Committer: Ingo Molnar
CommitDate: Mon, 27 Jun 2016 13:06:56 +0200
x86/uv: Update
Commit-ID: 80e75596079f0a41f905836ad0ccaac68ba33612
Gitweb: http://git.kernel.org/tip/80e75596079f0a41f905836ad0ccaac68ba33612
Author: Alex Thorlton
AuthorDate: Sat, 25 Jun 2016 08:20:27 +0100
Committer: Ingo Molnar
CommitDate: Mon, 27 Jun 2016 13:06:56 +0200
efi: Convert
es to
efi.systab->runtime everywhere.
Note that I also broke up the code in the efi_call_virt_pointer macro a
bit in the process of moving it.
Signed-off-by: Alex Thorlton
Cc: Matt Fleming
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: Russell King
Cc: Catalin Marinas
Cc: Will Deacon
Cc:
ess
isn't mapped into the EFI page table. For now, we will use the physical
address of the function directly, since that is mapped into the EFI page
table. In the near future, we're going to get some code added in to
properly update our function pointer to its virtual address during
S
and
Cc: Roy Franz
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: x...@kernel.org
Alex Thorlton (3):
Convert efi_call_virt to efi_call_virt_pointer
Update uv_bios_call to use efi_call_virt_pointer
Update efi_thunk to use the the arch_efi_call_virt* macros
arch/arm
Currently, the efi_thunk macro has some semi-duplicated code in it that
can be replaced with the arch_efi_call_virt_setup/teardown macros. This
commit simply replaces the duplicated code with those macros.
Signed-off-by: Alex Thorlton
Suggested-by: Matt Fleming
Cc: Russ Anderson
Cc: Dimitri
On Thu, Jun 02, 2016 at 04:14:03PM -0500, Alex Thorlton wrote:
> On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote:
> > Unless I've missed it, I didn't see an explanation in the changelog of
> > why it's OK to switch from using __va(tab->function) to
On Thu, Jun 02, 2016 at 09:19:49PM +0100, Matt Fleming wrote:
> On Wed, 18 May, at 02:11:41PM, Alex Thorlton wrote:
> > +#define arch_efi_call_virt(p, f, ...)
> > \
> > +({
On Thu, Jun 02, 2016 at 08:45:47PM +0100, Matt Fleming wrote:
> Unless I've missed it, I didn't see an explanation in the changelog of
> why it's OK to switch from using __va(tab->function) to tab->function
> directly, which presumably is a physical address.
>
> Was that intended?
It was intended
On Thu, Jun 02, 2016 at 04:41:14PM +0100, Matt Fleming wrote:
> Oops, you're missing updates to the 32-bit version and ARM/arm64,
> which results in this,
>
> drivers/firmware/efi/runtime-wrappers.c: In function ‘virt_efi_get_time’:
> arch/x86/include/asm/efi.h:46:4: error: ‘efi_efi’ undeclared (f
On Wed, May 18, 2016 at 02:11:38PM -0500, Alex Thorlton wrote:
> Let me know what everybody thinks!
I realized right as I sent these that I should've included prefixes on
the individual patches. I have a feeling we'll need a v2 anyways, so
I'll clean that up then.
- Alex
ur machines booting, running properly, and able to execute our
callbacks with 6+ arguments.
Signed-off-by: Alex Thorlton
Cc: Matt Fleming
Cc: Borislav Petkov
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Mike Travis
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: x...@kernel
to re-think things a bit.
Signed-off-by: Alex Thorlton
Cc: Matt Fleming
Cc: Borislav Petkov
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Mike Travis
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
---
arch/x86/inclu
;H. Peter Anvin"
Cc: Mike Travis
Cc: Russ Anderson
Cc: Dimitri Sivanich
Cc: x...@kernel.org
Cc: linux-...@vger.kernel.org
Alex Thorlton (3):
Convert efi_call_virt to efi_call_virt_generic
Update uv_bios_call to use efi_call_virt_generic
Update efi_thunk to use efi_call_virt_generic
arch/x86/
es to
efi.systab->runtime everywhere.
Note that I also broke up the code in the efi_call_virt_generic macro a
bit in the process of moving it.
Signed-off-by: Alex Thorlton
Cc: Matt Fleming
Cc: Borislav Petkov
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Mike
On Tue, May 17, 2016 at 01:11:22PM +0100, Matt Fleming wrote:
> On Mon, 16 May, at 05:58:40PM, Alex Thorlton wrote:
> >
> > I was simply re-using the efi_call implementation. Boris suggested that
> > I re-write this using the efi_call_virt macro, so I just went with that
On Thu, May 12, 2016 at 10:17:39AM +0200, Ingo Molnar wrote:
> > Fine by me, although having a newline after arch_efi_call_virt_setup()
> > but not before arch_efi_call_virt_teardown() seems rather arbitrary
>
> It's an oversight! :-)
>
> #define efi_call_virt(f, args...)
On Thu, May 12, 2016 at 01:06:00PM +0100, Matt Fleming wrote:
> (Adding author of arch_efi_call code)
>
> On Wed, 11 May, at 02:55:44PM, Alex Thorlton wrote:
> > We need a slightly different macro than the standard efi_call_virt,
> > since those macros all assume that th
On Mon, May 16, 2016 at 03:23:51PM -0500, Alex Thorlton wrote:
> Everything discussed above makes sense to me, and the patch looks sane.
> I will apply and test it today and let you know how it works.
I applied this to the latest -tip kernel and tested on both real
hardware and in our sim
On Mon, May 16, 2016 at 01:05:45PM -0700, Linus Torvalds wrote:
> On Mon, May 16, 2016 at 7:46 AM, Ingo Molnar wrote:
> >
> > Please pull the latest efi-urgent-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> > efi-urgent-for-linus
> >
> ># HEAD:
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
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 my
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
hought I would 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-of
ore than 6 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
---
a
ing
Cc: Borislav Petkov
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 |
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
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 quirk
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
'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 Thor
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
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...) \
> > +({ \
> > +
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 ver
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
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 look
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
> > efi_
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
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
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 requ
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: unabl
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:
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
ifferent 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"
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
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 patch
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
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 --git
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
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 in
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 M
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
---
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 si
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
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 majord.
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
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.
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.
&g
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
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,
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
startin
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..c84a
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
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
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 boo
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
e the node 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
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
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
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
Hey guys,
1 - 100 of 251 matches
Mail list logo
