810dfba 100644
> > --- a/arch/x86/include/asm/uv/bios.h
> > +++ b/arch/x86/include/asm/uv/bios.h
> > @@ -5,6 +5,7 @@
> > /*
> > * UV BIOS layer definitions.
> > *
> > + * (C) Copyright 2020 Hewlett Packard Enterprise Development LP
> > * Co
ad_uefi.c | 85 +
> 22 files changed, 746 insertions(+), 237 deletions(-)
> rename drivers/firmware/efi/{arm-init.c => efi-init.c} (99%)
> create mode 100644 drivers/firmware/efi/mokvar-table.c
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
t; drivers/firmware/efi/cper.c | 18 --
> include/linux/cper.h| 24 ++--
> 3 files changed, 53 insertions(+), 6 deletions(-)
>
> --
> 2.26.2
>
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
ith quick testing on a 32 socket, 1536 CPU, 12 TB memory
Cascade Lake system and a 8 socket, 144 CPU, 3 TB memory
Cooper Lake system without any obvious regression.
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
Travis is working on a patch
to remove old SGI UV1 code. Dimitri Sivanich is working on a
sgi_rtc cleanup patch. We are looking at additional cleanup
that should have been done previously.
Steve Wahl will be involved on an ongoing basis, so
you will see more from us.
Thanks.
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
o);
> > - if (cpumask)
> > - smp_call_function_many(cpumask, flush_tlb_func_remote,
> > - (void *)info, 1);
> > - return;
> > - }
> > -
> > /*
> > * If no page tables were freed, we can skip sending IPIs to
> > * CPUs in lazy TLB mode. They will flush the CPU themselves
> > --
> > 2.17.1
> >
> >
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
requisites for that change.
>
> Also, if your colleagues reviewed your patches, now would be the time
> to ask them to give their Reviewed-by as well.
Reviewed-by: Russ Anderson
Thanks.
> --
> Ard.
>
>
>
> > ---
> >
> > Calls into UV BIOS were not being
csrow0 ->
> ../../../devices/system/edac/mc/mc0/csrow0
> lrwxrwxrwx. 1 root root 0 Sep 26 11:08 dimm0 ->
> ../../../devices/system/edac/mc/mc0/dimm0
> lrwxrwxrwx. 1 root root 0 Sep 26 11:08 dimm3 ->
> ../../../devices/system/edac/mc/mc0/dimm3
> lrwxrwxrwx. 1 root root 0 Sep
sockets?
> Normally, the number "1" in the above string "Skylake Socekt#1 IMC#1"
> should be 7 (that was 15/2), but it was 1 here.
Yes, that is from a 32 socket system.
Thanks.
--
Russ Anderson, SuperDome Flex Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com
platforms,
both old and new mapping, with new mapping being the default.
Thanks.
--
Russ Anderson, Hawks 2 Linux Kernel Group Manager
HPE - Hewlett Packard Enterprise (formerly SGI) r...@hpe.com (r...@sgi.com)
> >>> - if (apic_set_affinity(data, mask, &dest))
> >>> - return -1;
> >>> -
> >>> - mmr_value = 0;
> >>> - entry = (struct uv_IO_APIC_route_entry *)&mmr_value;
> >>> -
> >>> - entry->vector
On Tue, Mar 04, 2014 at 05:02:17PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Getting this thing to work with the new mapping scheme would need more
> work.
Thanks Boris. Allows SGI UV to boot (without the extra bootline).
Acked-by: Russ Anderson
> Signed-o
On Fri, Feb 21, 2014 at 12:13:13AM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 17:59 -0600, Russ Anderson wrote:
> > On Thu, Feb 20, 2014 at 11:09:42PM +, Matthew Garrett wrote:
> > > On Thu, 2014-02-20 at 16:45 -0600, Russ Anderson wrote:
> > > >
>
s. :-)
I don't want to join the fight, either.
I have not looked at your code changes but the description
looks like the right direction.
> > From: linux-acpi-ow...@vger.kernel.org
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Russ Anderson
> > Sent: Friday,
On Thu, Feb 20, 2014 at 11:09:42PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 16:45 -0600, Russ Anderson wrote:
> > On Thu, Feb 20, 2014 at 10:26:45PM +, Matthew Garrett wrote:
>
> > > Because I'm trying to ensure that the default behaviour of th
;?
> Set the default to Y in order to encourage distributions and
> users to configure kernels to avoid awkward surprises.
What are the "awkward surprises"?
Thanks,
--
Russ Anderson, Kernel and Performance Software Team Manager
SGI - Silicon Graphics Inc r...@sgi.com
-
On Thu, Feb 20, 2014 at 10:26:45PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 16:06 -0600, Russ Anderson wrote:
> > On Thu, Feb 20, 2014 at 09:39:23PM +, Matthew Garrett wrote:
> > > On Thu, 2014-02-20 at 15:28 -0600, Russ Anderson wrote:
> > >
>
On Thu, Feb 20, 2014 at 09:39:23PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 15:28 -0600, Russ Anderson wrote:
>
> > For some customers _any_ amount is significant, especially
> > on large clustered systems where the amount is multiplied
> > by tens or hundre
On Thu, Feb 20, 2014 at 08:46:04PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
>
> > There are any number of reasons why a BMC may not respond.
> > BMCs are notorious for being flakey, with different types
> > of BMCs that ma
On Thu, Feb 20, 2014 at 09:00:48PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 14:59 -0600, Russ Anderson wrote:
> > On Thu, Feb 20, 2014 at 08:46:04PM +, Matthew Garrett wrote:
> > > On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
> > >
> &g
On Thu, Feb 20, 2014 at 08:46:04PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 14:40 -0600, Russ Anderson wrote:
>
> > This is also a problem for systems with functional BMCs. Our
> > large cluster systems do all IPMI traffic (monitoring) through
> > a system c
On Thu, Feb 20, 2014 at 08:16:22PM +, Matthew Garrett wrote:
> On Thu, 2014-02-20 at 14:14 -0600, Russ Anderson wrote:
>
> > The distro that added this change created all sorts of support
> > problems. Problems include kipmi0 spinning at 100% of cpu
> > (creating a p
Provides a driver for System Interfaces (KCS, SMIC, BT).
>Currently, only KCS and SMIC are supported. If
> --
> 1.8.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.o
's. Physical/virtual shouldn't matter all that much
> because we map the region *both* as a 1:1 map and in virtual space too.
>
> Can SGI please give us a reliable way to do that during boot?
I'm not sure what you are asking for. We had a reliable way to
boot before the recen
it a
> limitation of the firmware?
That was a non-upstream regression in the distro kernel. The
3.13 community kernel was boots fine. The current problem is a
regression introduced in this merge window which needs to be fixed.
--
Russ Anderson, Kernel and Performance Software Team Manager
hat you know of) have x86 hardware with
> more than 4096 CPUs?
Yes. We have a system in the lab with 254 12-core IVB sockets for
a total of 3048 cores. With HT is it 6096 cpus.
> If so, I can actually make a bump to the MAXSMP count a separate patch.
>
> josh
--
Russ Anderson, OS RAS/Pa
6 wasn't working very well and you had to select MAXSMP
> > deliberately and keep all the pieces.
> >
> > But today it's all pretty robust so I see no reason why not to allow up to
> > 4096 CPUs.
>
> Adding Russ from SGI as they are one of the consume
Commit-ID: dd3c9c4b603c664fedc12facf180db0f1794aafe
Gitweb: http://git.kernel.org/tip/dd3c9c4b603c664fedc12facf180db0f1794aafe
Author: Russ Anderson
AuthorDate: Mon, 14 Oct 2013 11:17:34 -0500
Committer: Ingo Molnar
CommitDate: Tue, 15 Oct 2013 08:44:46 +0200
x86: Update UV3 hub
The UV3 hub revision ID is different than expected. The first
revision was supposed to start at 1 but instead will start at 0.
Signed-off-by: Russ Anderson
---
arch/x86/kernel/apic/x2apic_uv_x.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux/arch/x86/kernel/apic
On Mon, Aug 26, 2013 at 02:49:59PM -0700, Andrew Morton wrote:
> On Fri, 23 Aug 2013 11:23:17 -0500 Russ Anderson wrote:
>
> > "cat /sys/devices/system/memory/memory*/removable" crashed the system.
> >
> > The problem is that show_mem_remov
-rw-r--r-- 1 root root 21330 Aug 23 21:23 ssdt.dat
-rw-r--r-- 1 root root 92 Aug 23 21:23 uefi1.dat
-rw-r--r-- 1 root root 298 Aug 23 21:23 uefi.dat
-rw-r--r-- 1 root root 124 Aug 23 21:23 xsdt.dat
---
--
Russ Anderson, OS RAS/Partit
0 0105C (v01 SGI2 UVX 0002 MSFT 0001)
ACPI: SPCR 7e6c2000 00050 (v01 )
ACPI: DMAR 7d6d3000 0013C (v01 INTEL TIANO0001 MSFT 0113)
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r.
Signed-off-by: Russ Anderson
The failing output:
---
harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
0
1
1
1
1
1
1
1
1
1
1
1
1
1
[ 372.78] BUG: unable to handle kernel paging request at ea00c320
[ 3
nr + i))
> continue;
Yes, I will make that change and resubmit the patch.
Thanks.
> Thanks,
> Yasuaki Ishimatsu
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the lin
On Thu, Aug 22, 2013 at 09:10:45PM -0700, Greg Kroah-Hartman wrote:
> On Thu, Aug 22, 2013 at 09:38:38PM -0500, Russ Anderson wrote:
> > "cat /sys/devices/system/memory/memory*/removable" crashed the system.
>
> On what kernels? linux-next or Linus's tree, or 3.1
I suspect other usages of sections_per_block will also
need to be fixed.
Signed-off-by: Russ Anderson
The failing output:
---
harp5-sys:~ # cat /sys/devices/system/memory/memory*/removable
0
1
1
1
1
1
1
1
1
1
1
1
1
1
[ 372.78] BUG:
2.23%)
UV2: 255 nodes 16TB:1141.02 1138.12 -2.90 (0.25%)
UV2: 64 nodes 2TB: 128.15 126.53 -1.62 (1.26%)
UV2: 32 nodes 2TB: 121.87 121.07 -0.80 (0.66%)
Time in seconds.
Acked-by: Russ Anderson
> > ...
>
On Fri, Aug 16, 2013 at 12:15:21PM -0700, Yinghai Lu wrote:
> On Fri, Aug 16, 2013 at 12:01 PM, Russ Anderson wrote:
> > On Thu, Aug 15, 2013 at 01:43:48PM -0700, Andrew Morton wrote:
> >> On Wed, 14 Aug 2013 22:46:29 -0700 Yinghai Lu wrote:
> >>
> >> >
t;
> > Looks nice. I wonder how much difference it makes.
>
> Russ said he would test on his 256 nodes system, but looks he never
> got chance.
I reserved time tonight on a couple big systems to measure
the performance difference.
Thanks,
--
Russ Anderson, OS RAS/Partitioning Proj
dummy_size, dummy);
> +
> + if (status == EFI_SUCCESS) {
> + /*
> + * This should have failed, so if it didn't make sure
> + * that we delete it...
> + */
On Thu, Jun 06, 2013 at 04:00:39PM +0100, Matt Fleming wrote:
> On Thu, 06 Jun, at 09:48:46AM, Russ Anderson wrote:
> > This looks like it will try to allocate more than the remaining size.
> > Is that intended?
>
> Yes, the intention is to trigger garbage collection.
OK, if
BLE_RUNTIME_ACCESS,
> + dummy_size, dummy);
> +
> + if (status == EFI_SUCCESS) {
> + /*
> + * This should have failed, so if it didn't make sure
> + * that we delete
*/
> + efi.set_variable(efi_name, &guid, attributes, 0,
> + dummy);
> + }
>
> - if (!storage_size || size > remaining_size ||
> - (max_size && size > max_size))
> - retu
On Sat, Jun 01, 2013 at 01:03:11AM +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 05:57:31PM -0500, Russ Anderson wrote:
> > On Fri, May 31, 2013 at 05:28:16PM +0100, Matthew Garrett wrote:
> > > If nvram becaomes full, some
&
On Fri, May 31, 2013 at 05:28:16PM +0100, Matthew Garrett wrote:
> On Fri, May 31, 2013 at 10:43:49AM -0500, Russ Anderson wrote:
>
> > When did writing EFI variables to nvram become necessary to boot on
> > UEFI? And if it is necessary, why is it that only linux boot loaders
In any case, Samsung clearly
> haven't fixed this problem on a pile of machines that have already
> shipped.
Which means the previous patch(es) that caused the bricking should
get pulled, too.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc
On Thu, May 30, 2013 at 10:32:09PM +, Matthew Garrett wrote:
> On Thu, 2013-05-30 at 17:28 -0500, Russ Anderson wrote:
> > On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> > > On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
> > >
> &g
On Fri, May 31, 2013 at 12:30:43AM +0200, Jiri Kosina wrote:
> On Thu, 30 May 2013, Russ Anderson wrote:
>
> > > > That's a great idea. This patch moves the QueryVariableInfo()
> > > > call from bootime to runtime, in efi_late_init(). The attached
> > &
On Thu, May 30, 2013 at 10:21:53PM +, Matthew Garrett wrote:
> On Thu, 2013-05-30 at 17:17 -0500, Russ Anderson wrote:
>
> > That's a great idea. This patch moves the QueryVariableInfo()
> > call from bootime to runtime, in efi_late_init(). The attached
> > patc
On Thu, May 30, 2013 at 10:16:12AM +0800, joeyli wrote:
> 於 四，2013-05-30 於 00:53 +0200，Jiri Kosina 提到：
> > On Wed, 29 May 2013, Russ Anderson wrote:
> >
> > > > Yes, but this call is clearly happening way before ExitBootServices()
> > > > --
> >
On Thu, May 30, 2013 at 12:22:13AM +0200, Jiri Kosina wrote:
> On Wed, 29 May 2013, Russ Anderson wrote:
>
> > > What appears to be happening is that your the EFI runtime services code
> > > is calling into the EFI boot services code, which is definitely a bug in
> >
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
> On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
> >efi: mem127: type=4, attr=0xf,
> > range=[0x6bb22000-0x7ca9c000) (271MB)
>
> EFI_BOOT_SERVICES_CODE
>
> >efi: mem133: t
On Fri, May 24, 2013 at 08:45:44AM +0100, Matt Fleming wrote:
> On Thu, 23 May, at 05:23:21PM, Russ Anderson wrote:
> > Interesting data point. The failure is on a rhel7/grub2 root.
> > The identical kernel on a rhel6/grub root boots. So maybe
> > grub2 brings out th
On Mon, May 27, 2013 at 12:27:12PM +0800, joeyli wrote:
> Hi Dave,
>
> 於 五，2013-05-24 於 17:05 -0400，Dave Jones 提到：
> > On Fri, May 24, 2013 at 12:02:15PM -0500, Russ Anderson wrote:
> > > On Fri, May 24, 2013 at 11:11:11AM -0500, Robin Holt wrote:
> > > > Ru
On Fri, May 24, 2013 at 08:11:01PM +, Matthew Garrett wrote:
> On Fri, 2013-05-24 at 15:05 -0500, Russ Anderson wrote:
>
> > One other data point is if the query_variable_info call is hacked to
> > remove one of the EFI flags (ie comment out EFI_VARIABLE_BOOTSERVI
On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
> On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
> >efi: mem127: type=4, attr=0xf,
> > range=[0x6bb22000-0x7ca9c000) (271MB)
>
> EFI_BOOT_SERVICES_CODE
>
> >efi: mem133: t
lementation. That still makes it a kernel bug.
I'm still digging to better understand the root problem.
> Robin
>
> On Fri, May 24, 2013 at 08:43:31AM +0100, Matt Fleming wrote:
> > On Thu, 23 May, at 03:32:34PM, Russ Anderson wrote:
> > >efi: mem12
On Thu, May 23, 2013 at 12:58:01PM +0100, Matt Fleming wrote:
> On Wed, 22 May, at 11:27:47AM, Russ Anderson wrote:
> > [6.062157] EFI Variables Facility v0.08 2004-May-17
> > [6.067731] BUG: unable to handle kernel paging request at
> > 7ca95b10
On Thu, May 23, 2013 at 12:58:01PM +0100, Matt Fleming wrote:
> On Wed, 22 May, at 11:27:47AM, Russ Anderson wrote:
> > [6.062157] EFI Variables Facility v0.08 2004-May-17
> > [6.067731] BUG: unable to handle kernel paging request at
> > 7ca95b10
785] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0009
---
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.com
--
To unsubscribe from this list: send the line "unsubscr
On Tue, May 21, 2013 at 02:17:17PM -0700, Andrew Morton wrote:
> On Fri, 3 May 2013 17:35:44 -0500 Russ Anderson wrote:
>
> > The routine disable_nonboot_cpus() shuts down cpus sequentially
> > using for_each_online_cpu(cpu) to call cpu_down() one cpu at
> > a
but one cpu from 16 minutes down to 4 minutes.
Signed-off-by: Russ Anderson
To: Andrew Morton
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Robin Holt
Cc: Russ Anderson
---
kernel/cpu.c | 104 ++-
1 file changed, 61 inserti
On Thu, Apr 11, 2013 at 08:15:27PM +0530, Srivatsa S. Bhat wrote:
> On 04/11/2013 07:53 PM, Russ Anderson wrote:
> > On Thu, Apr 11, 2013 at 06:15:18PM +0530, Srivatsa S. Bhat wrote:
> >>
> >> One more thing we have to note is that, there are 4 notifiers fo
sser CPUs are online on each iteration (and hence it reduces the
> synchronization overhead of the stop-machine phase).
>
> The only downside to this whole idea of running the notifiers of a given
> priority in parallel, is error handling - if a notifier fails, it would be
> troubles
On Wed, Apr 10, 2013 at 06:59:34PM +0200, Ingo Molnar wrote:
> * Russ Anderson wrote:
>
> > Yes, I have a test patch that replaces for_each_online_cpu(cpu) with a cpu
> > bitmask in disable_nonboot_cpus(). The lower level routines already take a
> > bitmask. It allow
On Wed, Apr 10, 2013 at 10:29:12AM -0500, Russ Anderson wrote:
> On Wed, Apr 10, 2013 at 08:10:05AM -0700, Linus Torvalds wrote:
> >
> > Yeah, we've had issues with ACPI in the past, so I do think we should
> > always reboot using the BP. Even if it almost certainl
cant change with ramifications on
other code.
I will post a patch shortly with the cpu bitmask change. Changing
__cpu_notify() will take more discussion.
> Linus
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc r...@sgi.c
gt; > selected by the x86 arch. I don't know which other arch's would also
> > benefit, if any.
> >
> > Signed-off-by: Robin Holt
> > To: Andrew Morton
> > Cc: Russ Anderson
> > Cc: Thomas Gleixner
> > Cc: Ingo Molnar
> > Cc: "H. Peter
(quote)
> > A 4 TB (single rack) UV1 system takes 512 seconds to get through
> > the zone code. This performance optimization reduces the time
> > by 189 seconds, a 36% improvement.
> >
> > A 2 TB (single rack) UV2 system goes from 212.7 seconds to 99.8 seconds,
> >
e previous pfn, so check that
range first. If it is in the same range, return that nid.
If not, scan the list as before.
A 4 TB (single rack) UV1 system takes 512 seconds to get through
the zone code. This performance optimization reduces the time
by 189 seconds, a 36% improvement.
A 2 TB
time
by 189 seconds, a 36% improvement.
A 2 TB (single rack) UV2 system goes from 212.7 seconds to 99.8 seconds,
a 112.9 second (53%) reduction.
Signed-off-by: Russ Anderson
---
mm/page_alloc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
Index: linux/mm/page_alloc.c
RIP [] free_one_page+0x382/0x430
RSP
---[ end trace a7919e7f17c0a725 ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Signed-off-by: Russ Anderson
Reported-by: George Beshers
Acked-by: Hedi Berriche
---
include/linux/mmzone.h |2 +-
1 file changed, 1 inserti
it with a fix.
I agree.
> The following patch is a hot fix by returning to the initial behavior
> by removing the lock when getting the driver.
The patch fixes the problem. Verified on a system with 1024 cpus.
Thanks.
> Signed-off-by: Daniel Lezcano
Reported-by: Russ Anderson
Acked-b
> > - spin_lock(&cpuidle_driver_lock);
> > - drv = __cpuidle_get_cpu_driver(dev->cpu);
> > - spin_unlock(&cpuidle_driver_lock);
> > -
> > - return drv;
> > + return __cpuidle_get_cpu_driver(dev->cpu);
> > }
> > EXPORT_SYMBOL_GPL(
: G O 3.7.0.rja-sgi+ #38
RIP: 0010:[] [] _raw_spin_lock+0x25/0x30
[...]
Call Trace:
[] cpuidle_get_cpu_driver+0x1c/0x30
[] cpuidle_idle_call+0x7d/0x1b0
[] cpu_idle+0xdd/0x130
[] start_secondary+0xc6/0xcc
----
--
Russ Anderson
On Tue, Nov 20, 2012 at 07:28:56AM +0300, Dan Carpenter wrote:
> On Mon, Nov 19, 2012 at 06:48:34PM -0600, Russ Anderson wrote:
> > On Sat, Nov 17, 2012 at 06:16:11PM +0300, Dan Carpenter wrote:
> > > This is a static checker fix. The problem is that we store the bits
> >
On Tue, Nov 20, 2012 at 11:10:55AM +, Alan Cox wrote:
> On Tue, 20 Nov 2012 07:28:56 +0300 Dan Carpenter
> wrote:
> > On Mon, Nov 19, 2012 at 06:48:34PM -0600, Russ Anderson wrote:
> > > On Sat, Nov 17, 2012 at 06:16:11PM +0300, Dan Carpenter wrote:
> > > > T
ECTOR_SHFT) >> 12) |
> APIC_DM_INIT;
> uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
>
> val = (1UL << UVH_IPI_INT_SEND_SHFT) |
> - (phys_apicid << UVH_IPI_INT_APIC_ID_SHFT) |
> + ((unsigned long)phys_apicid << UVH_IPI_INT_
ecessary (and misleading).
I think the intended behavior is for chip->disable() to
disable the interrupt in the chipset. If, for some reason,
the interrupt cannot be disabled in the hardware, the IRQ_DISABLED
would prevent the interrupt handler from being called.
--
Russ Anderson, OS RAS/Partit
ned-off-by: Russ Anderson ([EMAIL PROTECTED])
---
kernel/irq/handle.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
Index: linus/kernel/irq/handl
y' (at offset
0x1e0) and 'slab_early_init'
WARNING: drivers/built-in.o - Section mismatch: reference to
.init.text:sn_sal_console_setup from .data.rel between 'sal_console' (at offset
0x1c78) and 'ioc4_serial_submodule'
WARNING: drivers/built-in.o - Section mismatch: re
Jes Sorensen wrote:
>
> Russ/Dean/Robin - could one of you provide some feedback to this one
> please.
Dean's on vacation for a couple days and will test it when he gets back.
--
Russ Anderson, OS RAS/Partitioning Project Lead
SGI - Silicon Graphics Inc [EMAIL P
Matthias Fouquet-Lapar wrote:
> Keith Owens wrote:
> > Russ Anderson <[EMAIL PROTECTED]> wrote:
> > >The MCA recovery driver saves the addresses of memory errors
> > >in an array. The array has 32 entries. The effect is
> > >that after 32 recoveries, th
83 matches
Mail list logo
