Add additional support for CPU disable on SN platforms.
Correctly setup the smp_affinity mask for I/O error IRQs.
Restrict the use of the feature to Altix 4000 and 450 systems
running with a CPU disable capable PROM, and do not allow disabling
of CPU 0.
Signed-off-by: John Keller <[EM
Add additional support for CPU disable on SN platforms.
Correctly setup the smp_affinity mask for I/O error IRQs.
Restrict the use of the feature to Altix 4000 and 450 systems
running with a CPU disable capable PROM, and do not allow disabling
of CPU 0.
Signed-off-by: John Keller [EMAIL PROTECTED
Add additional support for CPU disable on SN platforms.
Correctly setup the smp_affinity mask for I/O error IRQs.
Restrict the use of the feature to Altix 4000 and 450 systems
running with a CPU disable capable PROM, and do not allow disabling
of CPU 0.
Signed-off-by: John Keller <[EM
Add additional support for CPU disable on SN platforms.
Correctly setup the smp_affinity mask for I/O error IRQs.
Restrict the use of the feature to Altix 4000 and 450 systems
running with a CPU disable capable PROM, and do not allow disabling
of CPU 0.
Signed-off-by: John Keller [EMAIL PROTECTED
Add additional support for CPU disable on SN platforms.
Correctly setup the smp_affinity mask for I/O error IRQs.
Restrict the use of the feature to Altix 4000 and 450 systems
running with a CPU disable capable PROM, and do not allow disabling
of CPU 0.
Signed-off-by: John Keller <[EM
Add additional support for CPU disable on SN platforms.
Correctly setup the smp_affinity mask for I/O error IRQs.
Restrict the use of the feature to Altix 4000 and 450 systems
running with a CPU disable capable PROM, and do not allow disabling
of CPU 0.
Signed-off-by: John Keller [EMAIL PROTECTED
>
> [adding Andi Kleen]
>
> John Keller wrote:
> > Place all the IOACPI NMI support code under CONFIG_ACPI
> > to clear up build errors with certain configs.
> >
> > Signed-off-by: John Keller <[EMAIL PROTECTED]>
> > ---
>
> Is there som
[adding Andi Kleen]
John Keller wrote:
Place all the IOACPI NMI support code under CONFIG_ACPI
to clear up build errors with certain configs.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
Is there some architectural reason that IO APIC NMI support should
require ACPI?
OK
Place all the IOACPI NMI support code under CONFIG_ACPI
to clear up build errors with certain configs.
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/io_apic.c | 77 +
1 file changed, 40 insertions(+), 37 deletions(-)
Index:
On SN systems, when setting the IORESOURCE_ROM_BIOS_COPY resource flag,
the resource length should be set to the actual size of the ROM image
so that a call to pci_map_rom() returns the correct size.
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
Resend #1 - correct format of block c
On SN systems, when setting the IORESOURCE_ROM_BIOS_COPY resource flag,
the resource length should be set to the actual size of the ROM image
so that a call to pci_map_rom() returns the correct size.
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
To avoid duplicate code, the imag
On SN systems, when setting the IORESOURCE_ROM_BIOS_COPY resource flag,
the resource length should be set to the actual size of the ROM image
so that a call to pci_map_rom() returns the correct size.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
To avoid duplicate code, the image size
On SN systems, when setting the IORESOURCE_ROM_BIOS_COPY resource flag,
the resource length should be set to the actual size of the ROM image
so that a call to pci_map_rom() returns the correct size.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
Resend #1 - correct format of block comment
Place all the IOACPI NMI support code under CONFIG_ACPI
to clear up build errors with certain configs.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
arch/x86_64/kernel/io_apic.c | 77 +
1 file changed, 40 insertions(+), 37 deletions(-)
Index: linux-2.6.22
>
> On Thu, 28 Jun 2007 13:09:21 -0700
> Randy Dunlap <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 28 Jun 2007 03:43:21 -0700 Andrew Morton wrote:
> >
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/
> >
> >
> > on x86_64, with CONFIG_PCI
On Thu, 28 Jun 2007 13:09:21 -0700
Randy Dunlap [EMAIL PROTECTED] wrote:
On Thu, 28 Jun 2007 03:43:21 -0700 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/
on x86_64, with CONFIG_PCI disabled, CONFIG_PM
>
> > In our specific case, a loadable driver will register to process
> > the NMI generated by a timer device on the IOAPIC pin. The driver
> > will need to unmask/mask the NMI interrupt at init/exit time.
> >
> > The timer NMI interrupt will be used to synchronize cluster nodes.
>
> We
>
> John Keller <[EMAIL PROTECTED]> writes:
>
> > Add support for IOAPIC NMI interrupts on x86_64.
> >
> > Changes include the following:
> >
> > - Obtain the NMI IOAPIC info via an ACPI NMI SRC structure that is
> > part of th
John Keller [EMAIL PROTECTED] writes:
Add support for IOAPIC NMI interrupts on x86_64.
Changes include the following:
- Obtain the NMI IOAPIC info via an ACPI NMI SRC structure that is
part of the MADT, and program the IOAPIC redirection register.
The NMI SRC struct
In our specific case, a loadable driver will register to process
the NMI generated by a timer device on the IOAPIC pin. The driver
will need to unmask/mask the NMI interrupt at init/exit time.
The timer NMI interrupt will be used to synchronize cluster nodes.
We normally don't
irq_desc[] and irq_2_pin[] entries for the NMI interrupt irq,
which will be used by the generic mask/unmask routines. This will
allow a driver to enable/disable the NMI interrupt via
enable/disable_irq().
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
arch/i386/kernel/acpi/
irq_desc[] and irq_2_pin[] entries for the NMI interrupt irq,
which will be used by the generic mask/unmask routines. This will
allow a driver to enable/disable the NMI interrupt via
enable/disable_irq().
Signed-off-by: John Keller [EMAIL PROTECTED]
---
arch/i386/kernel/acpi/boot.c
>
> On Tue, 8 May 2007 13:14:26 -0700
> "Luck, Tony" <[EMAIL PROTECTED]> wrote:
>
> > > It had a dopey little bug:
> > >
> > > -#define is_affinity_mask_valid() 1
> > > +#define is_affinity_mask_valid(val) 1
> >
> > That would fix warnings on non-ia64 systems (which is
> > a step in the right
On SN, only allow one bit to be set in the smp_affinty mask
when redirecting an interrupt. Currently setting multiple
bits is allowed, but only the first bit is used in
determining the CPU to redirect to. This has caused confusion
among some customers.
Signed-off-by: John Keller <[EMAIL PROTEC
On SN, only allow one bit to be set in the smp_affinty mask
when redirecting an interrupt. Currently setting multiple
bits is allowed, but only the first bit is used in
determining the CPU to redirect to. This has caused confusion
among some customers.
Signed-off-by: John Keller [EMAIL PROTECTED
On Tue, 8 May 2007 13:14:26 -0700
Luck, Tony [EMAIL PROTECTED] wrote:
It had a dopey little bug:
-#define is_affinity_mask_valid() 1
+#define is_affinity_mask_valid(val) 1
That would fix warnings on non-ia64 systems (which is
a step in the right direction). But on ia64 I
I'll rework as per your suggestions.
Thanks,
John
>
> On Thu, 03 May 2007 07:56:02 -0500
> John Keller <[EMAIL PROTECTED]> wrote:
>
> > On SN, only allow one bit to be set in the smp_affinty mask
> > when redirecting an interrupt. Currently setting multiple
On SN, only allow one bit to be set in the smp_affinty mask
when redirecting an interrupt. Currently setting multiple
bits is allowed, but only the first bit is used in
determining the CPU to redirect to. This has caused confusion
among some customers.
Signed-off-by: John Keller <[EMAIL PROTEC
On SN, only allow one bit to be set in the smp_affinty mask
when redirecting an interrupt. Currently setting multiple
bits is allowed, but only the first bit is used in
determining the CPU to redirect to. This has caused confusion
among some customers.
Signed-off-by: John Keller [EMAIL PROTECTED
I'll rework as per your suggestions.
Thanks,
John
On Thu, 03 May 2007 07:56:02 -0500
John Keller [EMAIL PROTECTED] wrote:
On SN, only allow one bit to be set in the smp_affinty mask
when redirecting an interrupt. Currently setting multiple
bits is allowed, but only the first bit
conversion was happening in sn_scan_pcdp(), but not in
setup_vga_console().
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
arch/ia64/sn/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6/arch/ia64/s
was happening in sn_scan_pcdp(), but not in
setup_vga_console().
Signed-off-by: John Keller [EMAIL PROTECTED]
---
arch/ia64/sn/kernel/setup.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6/arch/ia64/sn/kernel/setup.c
Looks good.
Feel free to add.
Acked-by: John Keller <[EMAIL PROTECTED]>
>
> In sn_io_slot_fixup(), the parent is re-set from the bus to
> io(port|mem)_resource because the address is changed in a way that it's not
> child of the bus any more.
>
> Howev
Looks good.
Feel free to add.
Acked-by: John Keller [EMAIL PROTECTED]
In sn_io_slot_fixup(), the parent is re-set from the bus to
io(port|mem)_resource because the address is changed in a way that it's not
child of the bus any more.
However, only the root is set but not the parent/child
still be required for a kexec/kdump boot.
John
>
> so will the 1st acpi_table_init() always fail -- even
> on future machines?
>
> -Len
>
> On Wednesday 28 February 2007 18:47, John Keller wrote:
> > To provide compatibilty with SN kernels that do and do not
>
still be required for a kexec/kdump boot.
John
so will the 1st acpi_table_init() always fail -- even
on future machines?
-Len
On Wednesday 28 February 2007 18:47, John Keller wrote:
To provide compatibilty with SN kernels that do and do not
have ACPI IO support, the SN PROM must
are not seen,
and the kernel will crash on boot. Because of issues with kexec support,
we are not able to create the tables prior to acpi_table_init().
As a result, we are making a second call to acpi_table_init() to
process the rebuilt DSDT and SSDTs.
Signed-off-by: John Keller <[EMAIL PROTEC
Add a missing #define for the platform_kernel_launch_event.
Without this fix, a call to platform_kernel_launch_event()
becomes a noop on generic kernels. SN systems require this
fix to successfully kdump/kexec from certain hardware errors.
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
Add a missing #define for the platform_kernel_launch_event.
Without this fix, a call to platform_kernel_launch_event()
becomes a noop on generic kernels. SN systems require this
fix to successfully kdump/kexec from certain hardware errors.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
Index
are not seen,
and the kernel will crash on boot. Because of issues with kexec support,
we are not able to create the tables prior to acpi_table_init().
As a result, we are making a second call to acpi_table_init() to
process the rebuilt DSDT and SSDTs.
Signed-off-by: John Keller [EMAIL PROTECTED
via
calls to acpi_get_devices().
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
arch/ia64/sn/kernel/io_acpi_init.c | 44 +--
1 file changed, 22 insertions(+), 22 deletions(-)
Index: release/arch/ia64/sn/kernel/io_acpi_
via
calls to acpi_get_devices().
Signed-off-by: John Keller [EMAIL PROTECTED]
---
arch/ia64/sn/kernel/io_acpi_init.c | 44 +--
1 file changed, 22 insertions(+), 22 deletions(-)
Index: release/arch/ia64/sn/kernel/io_acpi_init.c
acpi_boot_init() is making a bad check on the return
status from acpi_table_parse(). acpi_table_parse() now
returns zero on success, one on failure.
Signed-off-by: Aaron Young <[EMAIL PROTECTED]>
---
Index: release/arch/ia64/kernel/acpi.c
under any license (GPL or non-GPL) consistent
with the project.
John
>
> Thanks for the fix, John.
> Do you grant Intel permission to apply it to the upstream ACPICA tree (with
> its non-GPL license)?
>
> -Len
>
> On Thursday 15 February 2007
under any license (GPL or non-GPL) consistent
with the project.
John
Thanks for the fix, John.
Do you grant Intel permission to apply it to the upstream ACPICA tree (with
its non-GPL license)?
-Len
On Thursday 15 February 2007 15:08, John Keller wrote:
acpi_unload_table_id
acpi_boot_init() is making a bad check on the return
status from acpi_table_parse(). acpi_table_parse() now
returns zero on success, one on failure.
Signed-off-by: Aaron Young [EMAIL PROTECTED]
---
Index: release/arch/ia64/kernel/acpi.c
acpi_unload_table_id() is always returning an error status.
Also, once the matching table is found, don't bother looking
for another match.
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
Index: release/drivers/acpi/tables/tbx
acpi_unload_table_id() is always returning an error status.
Also, once the matching table is found, don't bother looking
for another match.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
Index: release/drivers/acpi/tables/tbxface.c
The SN Altix platform does not conform to the
IOSAPIC IRQ routing model. Add code in acpi_unregister_gsi()
to check if (acpi_irq_model == ACPI_IRQ_MODEL_PLATFORM) and
return.
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
Due to an oversight, this code was not added previously when
s
The SN Altix platform does not conform to the
IOSAPIC IRQ routing model. Add code in acpi_unregister_gsi()
to check if (acpi_irq_model == ACPI_IRQ_MODEL_PLATFORM) and
return.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
Due to an oversight, this code was not added previously when
similar
owner id.
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
drivers/acpi/utilities/utmisc.c |6 +++---
include/acpi/acconfig.h |4 ++--
include/acpi/aclocal.h |4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
Index: linux/drivers/acpi/utilities/ut
owner id.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
drivers/acpi/utilities/utmisc.c |6 +++---
include/acpi/acconfig.h |4 ++--
include/acpi/aclocal.h |4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
Index: linux/drivers/acpi/utilities/utmisc.c
of it in acpi_register_gsi()
to avoid the iosapic code path.
Signed-off-by: John Keller <[EMAIL PROTECTED]>
---
To avoid future regression/backward compatibilty issues
when _PRT support is added to our PROM, we'd like to
see this pushed into 2.6.20, if at all possible.
arch/ia64/kernel/acpi.c
of it in acpi_register_gsi()
to avoid the iosapic code path.
Signed-off-by: John Keller [EMAIL PROTECTED]
---
To avoid future regression/backward compatibilty issues
when _PRT support is added to our PROM, we'd like to
see this pushed into 2.6.20, if at all possible.
arch/ia64/kernel/acpi.c|3 +++
arch
This patch makes acpi_load_table() available
for use by removing it from the #ifdef ACPI_FUTURE_USAGE.
It also adds a new routine used to unload an ACPI table
of a given type and "id" - acpi_unload_table_id().
The implementation of this new routine was almost a direct
copy of existing
Support for dynamic loading and unloading of ACPI
SSDT tables upon slot hotplugs and unplugs.
On SN platforms, we now represent every
populated root bus slot with a single ACPI
SSDT table containing info for every
device and PPB attached to the slot. These SSDTs
are generated by the prom
Support for dynamic loading and unloading of ACPI
SSDT tables upon slot hotplugs and unplugs.
On SN platforms, we now represent every
populated root bus slot with a single ACPI
SSDT table containing info for every
device and PPB attached to the slot. These SSDTs
are generated by the prom
This patch makes acpi_load_table() available
for use by removing it from the #ifdef ACPI_FUTURE_USAGE.
It also adds a new routine used to unload an ACPI table
of a given type and id - acpi_unload_table_id().
The implementation of this new routine was almost a direct
copy of existing
58 matches
Mail list logo
