Commit-ID: 243d657eaf540db882f73497060da5a4f7d86a90
Gitweb: http://git.kernel.org/tip/243d657eaf540db882f73497060da5a4f7d86a90
Author: Ashok Raj
AuthorDate: Thu, 4 Jun 2015 18:55:24 +0200
Committer: Ingo Molnar
CommitDate: Sun, 7 Jun 2015 15:33:15 +0200
x86/mce: Handle Local MCE
Commit-ID: bc12edb8739be10fae9f86691a3708d36d00b4f8
Gitweb: http://git.kernel.org/tip/bc12edb8739be10fae9f86691a3708d36d00b4f8
Author: Ashok Raj
AuthorDate: Thu, 4 Jun 2015 18:55:22 +0200
Committer: Ingo Molnar
CommitDate: Sun, 7 Jun 2015 15:33:13 +0200
x86/mce: Add Local MCE
the fault.
For more details see Vol3, Chapter 15, Machine Check Architecture.
Modified to incorporate feedback from Boris on V1 patches.
Ashok Raj (3):
x86, mce: Add LMCE definitions.
x86, mce: Add infrastructure required to support LMCE
x86, mce: Handling LMCE events
Documentation/x86/x
s and documentation on Local MCE.
Signed-off-by: Ashok Raj
---
Documentation/x86/x86_64/boot-options.txt | 3 ++
arch/x86/include/asm/mce.h| 5 +++
arch/x86/kernel/cpu/mcheck/mce.c | 3 ++
arch/x86/kernel/cpu/mcheck/mce_intel.c| 59 +++
4 files ch
to
perform rendezvous with other logical processors unlike earlier processors
that would broadcast machine check errors.
See http://www.intel.com/sdm Volume 3, Chapter 15 for more information
on MSR's and documentation on Local MCE.
Signed-off-by: Ashok Raj
---
arch/x86/kernel/cpu/mcheck/
Add required definitions to support Local Machine Check Exceptions.
See http://www.intel.com/sdm Volume 3, System Programming Guide, chapter 15
for more information on MSR's and documentation on Local MCE.
Signed-off-by: Ashok Raj
---
arch/x86/include/asm/mce.h| 5 +
arc
s and documentation on Local MCE.
Signed-off-by: Ashok Raj
---
Documentation/x86/x86_64/boot-options.txt | 3 ++
arch/x86/include/asm/mce.h| 5 +++
arch/x86/kernel/cpu/mcheck/mce.c | 3 ++
arch/x86/kernel/cpu/mcheck/mce_intel.c| 75 +++
4
, Machine Check Architecture.
Ashok Raj (3):
x86, mce: Add LMCE definitions.
x86, mce: Add infrastructure required to support LMCE
x86, mce: Handling LMCE events
Documentation/x86/x86_64/boot-options.txt | 3 ++
arch/x86/include/asm/mce.h| 10
arch/x86/include/uapi/asm/msr
to
perform rendezvous with other logical processors unlike earlier processors
that would broadcast machine check errors.
See http://www.intel.com/sdm Volume 3, Chapter 15 for more information
on MSR's and documentation on Local MCE.
Signed-off-by: Ashok Raj
---
arch/x86/kernel/cpu/mcheck/
Add required definitions to support Local Machine Check Exceptions.
See http://www.intel.com/sdm Volume 3, System Programming Guide, chapter 15
for more information on MSR's and documentation on Local MCE.
Signed-off-by: Ashok Raj
---
arch/x86/include/asm/mce.h| 5 +
arc
On Tue, Jun 12, 2007 at 12:25:57AM +0200, Andi Kleen wrote:
>
> > Please advice.
>
> I think the short term only safe option would be to fully preallocate an
> aperture.
> If it is too small you can try GFP_ATOMIC but it would be just
> a unreliable fallback. For safety you could perhaps have so
On Mon, Jun 11, 2007 at 02:14:49PM -0700, Andrew Morton wrote:
> >
> > Again, if dma_map_{single|sg} API's fails due to
> > failure to allocate memory, the only thing that can
> > be done is to panic as this is what few of the other
> > IOMMU implementation is doing today.
>
> If the only opti
On Wed, Apr 25, 2007 at 12:03:57AM +0200, Andi Kleen wrote:
> On Tuesday 24 April 2007 23:50:26 David Miller wrote:
> > From: Ashok Raj <[EMAIL PROTECTED]>
> > Date: Tue, 24 Apr 2007 14:38:35 -0700
> >
> > > Its not clear if we have a very generic device br
On Tue, Apr 24, 2007 at 02:23:51PM -0700, David Miller wrote:
> From: Andi Kleen <[EMAIL PROTECTED]>
> Date: Tue, 24 Apr 2007 23:12:54 +0200
>
> > We already have a couple of other IOMMU architectures who essentially have
> > the same
> > problem. Have you checked how they solve this?
>
> Sparc6
On Tue, Apr 24, 2007 at 11:17:55PM +0200, Markus Rechberger wrote:
> >+We also allocate gaurd pages with each mapping, so we can attempt to catch
> >+any overflow that might happen.
> >+
>
> guess you probably mean guard tables here...
>
So there is a good chance i can be "The Governor of Califo
On Tue, Apr 24, 2007 at 09:27:08PM +0200, Andi Kleen wrote:
> On Tuesday 24 April 2007 08:03:02 Ashok Raj wrote:
> >
> > +#ifdef CONFIG_DMAR
> > +#ifdef CONFIG_SMP
> > +static void dmar_msi_set_affinity(unsigned int irq, cpumask_t mask)
>
>
> Why does it nee
On Tue, Apr 24, 2007 at 09:28:11PM +0200, Andi Kleen wrote:
> On Tuesday 24 April 2007 08:03:03 Ashok Raj wrote:
> > PCI specs permit zero length reads (ZLR) even if the mapping for that
> > region
> > is write only. Support for this feature is indicated by the presence of a
On Tue, Apr 24, 2007 at 09:31:09PM +0200, Andi Kleen wrote:
> On Tuesday 24 April 2007 08:03:06 Ashok Raj wrote:
> > Floppy disk drivers dont work well with DMA remapping.
>
> What is the problem? You can't allocate mappings <16MB?
No.. these drivers dont call DMA ma
On Tue, Apr 24, 2007 at 09:33:15PM +0200, Andi Kleen wrote:
> On Tuesday 24 April 2007 08:03:07 Ashok Raj wrote:
> > Some devices may not support entire 64bit DMA. In a situation where such
> > devices are co-located in a shared domain, we need to ensure there is some
> > a
On Tue, Apr 24, 2007 at 08:50:48PM +0200, Andi Kleen wrote:
>
> > +
> > +LIST_HEAD(dmar_drhd_units);
> > +LIST_HEAD(dmar_rmrr_units);
>
> Comment describing what lock protects those lists?
> In fact there seems to be no locking. What about hotplug?
>
There is no support to handle an IOMMU hotpl
-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/Documentation/kernel-parameters.txt
===
--- linux-2.6.21-rc5.orig/Documentation/kernel-parameters.txt 2007-
Document Intel IOMMU driver boot option.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/Documentation/Intel-IOMMU.txt
===
--- /dev/null 1970
ole memory for gfx devices, that is physical address equals to
virtual address.In this way, gfx will use physical address for DMA, this
is primarily for add-in card GFX device.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: 2.6.21-
hand, this will provide more compatibility, but we will lose
oppertunity to identify broken device drivers that dont use dma api's
and fix them Depending on who you talk to.. some like it.. some just
hate it! and would like to fix the broken ones instead.
Cheers,
Ashok Raj
--
-
To unsubs
provides a workaround for some drivers that request
a write-only mapping when they really should request a read-write.
(We ran into one such case in eepro100.c in handling rx_ring_dma)
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL
This patch contains basic ACPI parsing and enumeration support.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/arch/x86_64/Kconfig
===
--- linux-2.6.21-r
-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/Documentation/kernel-parameters.txt
===
--- linux-2.6.21-rc5.orig/Documentation/kernel-parameters.txt 2007-
Floppy disk drivers dont work well with DMA remapping. Its possible to
extend the current use for x86_64, but the gain is very little. If someone
feels compelled to clean this up, its up for grabs. Since these use 16M, we
just provide a unity map for the ISA bridge device.
Signed-off-by: Ashok
This patch contains basic ACPI parsing and enumeration support.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/arch/x86_64/Kconfig
===
--- linux-2.6.21-r
d.
Cheers,
Ashok Raj
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Document Intel IOMMU driver boot option.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/Documentation/Intel-IOMMU.txt
===
--- /dev/null 1970
ole memory for gfx devices, that is physical address equals to
virtual address.In this way, gfx will use physical address for DMA, this
is primarily for add-in card GFX device.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: 2.6.21-
devices under a p2p share the same
domain in a DMAR.
We just cache the type of device, if its a native PCIe device
or not for later use.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
-
Index
provides a workaround for some drivers that request
a write-only mapping when they really should request a read-write.
(We ran into one such case in eepro100.c in handling rx_ring_dma)
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL
devices under a p2p share the same
domain in a DMAR.
We just cache the type of device, if its a native PCIe device
or not for later use.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
-
Index
Floppy disk drivers dont work well with DMA remapping. Its possible to
extend the current use for x86_64, but the gain is very little. If someone
feels compelled to clean this up, its up for grabs. Since these use 16M, we
just provide a unity map for the ISA bridge device.
Signed-off-by: Ashok
On Tue, Apr 10, 2007 at 04:34:48AM -0400, Jeff Garzik wrote:
> Shaohua Li wrote:
> >DMA remapping just uses ACPI table to tell which dma remapping engine a
> >pci device is controlled by at boot time. At run time, DMA remapping
> >hasn't any interactive with ACPI.
>
> The Linux kernel _really_ wan
On Tue, Apr 10, 2007 at 09:49:55AM +0200, Andi Kleen wrote:
> On Monday 09 April 2007 23:55:52 Ashok Raj wrote:
>
> > Please help review and provide feedback.
>
> High level question: how did you solve the "user X server needs IOMMU bypass"
> problem?
There is no
On Mon, Apr 09, 2007 at 11:39:19PM -0400, Len Brown wrote:
> On Monday 09 April 2007 17:55, Ashok Raj wrote:
> > This patch contains basic ACPI parsing and enumeration support.
>
> AFAICS, ACPI supplies the envelope which delivers the table,
> and ACPI has some convenience str
This patch contains basic ACPI parsing and enumeration support.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/arch/x86_64/Kconfig
===
--- linux-2.6.21-r
Floppy disk drivers dont work well with DMA remapping. Its possible to
extend the current use for x86_64, but the gain is very little. If someone
feels compelled to clean this up, its up for grabs. Since these use 16M, we
just provide a unity map for the ISA bridge device.
Signed-off-by: Ashok
ole memory for gfx devices, that is physical address equals to
virtual address.In this way, gfx will use physical address for DMA, this
is primarily for add-in card GFX device.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-
Document Intel IOMMU driver boot option.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/Documentation/Intel-IOMMU.txt
===
--- /dev/null 1970
-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
Index: linux-2.6.21-rc5/Documentation/kernel-parameters.txt
===
--- linux-2.6.21-rc5.orig/Documentation/kernel-parameters.txt 2007-
es to Documentation area for startup options and some basics.
7. Workaround to provide unity map for ISA bridge device to enable floppy disk.
8. Ability to preserve some mappings for devices not able to address entire
range.
Please help review and provide feedback.
Cheers,
Ashok Raj & Shaohu
devices under a p2p share the same
domain in a DMAR.
We just cache the type of device, if its a native PCIe device
or not for later use.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL PROTECTED]>
-
Index:
provides a workaround for some drivers that request
a write-only mapping when they really should request a read-write.
(We ran into one such case in eepro100.c in handling rx_ring_dma)
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Signed-off-by: Shaohua Li <[EMAIL
On Fri, Sep 09, 2005 at 01:41:58PM -0700, Christopher Beppler wrote:
>
>[1.] One line summary of the problem:
>If I deactivate a CPU with /sys/devices/system/cpux and try to
>reactivate it, then the CPU doesn't start and the kernel prints out an
>oops.
>
Could you try this on 2.6
h hotplug) would make
IPI performance worse, since it would do one cpu at a time, and requires 2
writes per cpu for each IPI v.s just 2 for a flat mode mask version of the API.
--
Cheers,
Ashok Raj
- Open Source Technology Center
-
To unsubscribe from this list: send the line "unsubscribe lin
we dont end up reworking some trivial patches for a long time.
If you feel that way, i deeply apologize, and repeat, thats not my intend.
>
--
Cheers,
Ashok Raj
- Open Source Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Tue, Sep 06, 2005 at 01:16:28AM +0200, Andi Kleen wrote:
> On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote:
> >
> > From: Ashok Raj <[EMAIL PROTECTED]>
> >
> > Newly introduced physflat_* shares way too much with cluster with only a
On Tue, Sep 06, 2005 at 01:18:08AM +0200, Andi Kleen wrote:
> On Sat, Sep 03, 2005 at 02:33:30PM -0700, [EMAIL PROTECTED] wrote:
> >
> > From: Ashok Raj <[EMAIL PROTECTED]>
> >
> > It is not required to choose the physflat mode when CPU hotplug is enabled
&
Hi Andi
On Mon, Sep 05, 2005 at 06:48:21AM +0200, Andi Kleen wrote:
> On Sat, Sep 03, 2005 at 02:33:26PM -0700, [EMAIL PROTECTED] wrote:
> >
> > From: Ashok Raj <[EMAIL PROTECTED]>
> >
> > No need to enforce_max_cpus when hotplug code is enabled. This
find that the CPU
is now present and functional as reported by _STA, then the CPU is onlinable.
So if _STA can work favorably in your case you can use it to override the
disabled setting at boot time which would be prefectly fine.
>
--
Cheers,
Ashok Raj
- Open Source Technology Center
-
To un
On Thu, Sep 01, 2005 at 10:45:10AM +0200, Andi Kleen wrote:
> Hallo Natalie,
>
> On Wednesday 31 August 2005 14:13, [EMAIL PROTECTED] wrote:
> > Current IA32 CPU hotplug code doesn't allow bringing up processors that
> > were not present in the boot configuration. To make existing hot plug
> > fac
h_online_cpu(j)
> seq_printf(p, "%10u ", kstat_cpu(j).irqs[i]);
> #endif
> seq_printf(p, " %14s", irq_desc[i].handler->typename);
> @@ -276,12 +276,12 @@ skip:
> spin_unlock_irqrestore(&irq_desc[i].lock, flags);
> } e
ic7xxx_osm.c
> @@ -2331,8 +2331,6 @@ ahc_platform_dump_card_state(struct ahc_
> {
> }
>
> -static void ahc_linux_exit(void);
> -
> static void ahc_linux_set_width(struct scsi_target *starget, int width)
> {
> struct Scsi_Host *shost = dev_to_shost(starget->dev.pare
rio was the driver tried to probe, found nothing, and tries
to de-reg resulting in the BUG().
I will try to get the recompile and entire dmesg log in the meantime.
>
> James
>
>
--
Cheers,
Ashok Raj
- Open Source Technology Center
-
To unsubscribe from this list: send the line &quo
On Mon, Aug 08, 2005 at 07:11:26PM +0200, Andi Kleen wrote:
> On Mon, Aug 08, 2005 at 09:48:19AM -0700, Ashok Raj wrote:
> > Folks,
> >
> > Iam getting this on the recent 2.6.12-rc5-mm1 kernel built with defconfig.
> >
> > Cheers,
> > Ashok Raj
> >
Folks,
Iam getting this on the recent 2.6.12-rc5-mm1 kernel built with defconfig.
Cheers,
Ashok Raj
--- [cut here ] - [please bite here ] -
Kernel BUG at "include/linux/list.h":165
invalid operand: [1] SMP
CPU 2
Modules linked in:
Pid: 1, comm: swapper N
ill needs the num_online_cpus()s check.
>
> -Andi
Modified patch attached.
Andrew: the filename in your -mm queue is below, with the attached
patch.
x86_64dont-do-broadcast-ipis-when-hotplug-is-enabled-in-flat-mode.patch
--
Cheers,
Ashok Raj
- Open Source Technology Center
Note: Rece
s still needs the num_online_cpus()s check.
Opps missed that... Thanks for spotting it.
I will send an updated one to Andrew.
--
Cheers,
Ashok Raj
- Open Source Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROT
On Thu, Aug 04, 2005 at 12:43:02PM +0200, Andi Kleen wrote:
> On Mon, Aug 01, 2005 at 01:20:21PM -0700, Ashok Raj wrote:
> > Need to ensure we dont get prempted when we clear ourself from mask when
> > using
> > clustered mode genapic code.
>
> It's not needed
On Thu, Aug 04, 2005 at 12:41:10PM +0200, Andi Kleen wrote:
> On Mon, Aug 01, 2005 at 01:20:20PM -0700, Ashok Raj wrote:
> > No need to enforce_max_cpus when hotplug code is enabled. This
> > nukes out cpu_present_map and cpu_possible_map making it impossible to add
> > n
Delivery mode should be APIC_DM_FIXED when using physical mode.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
arch/x86_64/kernel/genapic_flat.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.13-rc4-mm
On Mon, Aug 01, 2005 at 01:20:18PM -0700, Ashok Raj wrote:
> Auto selection of bigsmp patch removed this check from a shared common file
> in arch/i386/kernel/acpi/boot.c. We still need to call this to determine
> the right genapic code for x86_64.
>
Thanks venki,
missed the che
lat mode.
Andi: Do you think this is acceptable?
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/genapic.c |9 +
1 files changed, 1 insertion(+), 8 deletions(-)
Index: linux-2.6.13-rc4-mm1/ar
support (for no-broadcast) is required.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
arch/x86_64/kernel/genapic.c | 52 +
arch/x86_64/kernel/genapic_cluster.c
Auto selection of bigsmp patch removed this check from a shared common file
in arch/i386/kernel/acpi/boot.c. We still need to call this to determine
the right genapic code for x86_64.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
---
No need to enforce_max_cpus when hotplug code is enabled. This
nukes out cpu_present_map and cpu_possible_map making it impossible to add
new cpus in the system.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
arch/x86_64/kernel/smpboot.c
ts in send IPI to a cpu that is offline which can trip when the
cpu is in the process of being kicked alive.
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/genapic_flat.c |8
1 files changed, 8 insertion
next update.
--
Cheers,
Ashok Raj
- Open Source Technology Center
This provides a working default config file for Intel systems.
Tested on harwich (4p + ht systems), if more are required either add
to this config, or create new defconfig's as required.
Signed-off-by: Ashok Raj &l
s,
>card->hw.alloc_ramsize);
>
>-
>To unsubscribe from this list: send the line "unsubscribe
>linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at [1]http://vger.kernel.org/majordomo-info.html
>
On Mon, Apr 04, 2005 at 03:46:20PM -0700, Nathan Lynch wrote:
>
>Hi Nigel!
>
>On Tue, Apr 05, 2005 at 08:14:25AM +1000, Nigel Cunningham wrote:
>>
>> On Tue, 2005-04-05 at 01:33, Nathan Lynch wrote:
>> > > Yes, exactly. Someone who understand do_exit please help clean
>
>
Hi Michael
have you thought about how this infrastructure would play well with
existing CPU hotplug code for ia64?
Once you return to user mode via the iret, is it possible that user mode
thread could get switched due to a pending cpu quiese attempt to remove
a cpu? (Current cpu removal code wou
On Mon, Mar 14, 2005 at 03:59:23PM -0800, Andrew Morton wrote:
> Ashok Raj <[EMAIL PROTECTED]> wrote:
> >
>
> "ia64" is preferred, please. Nobody knows what an IPF is.
Right!. Sorry about that.
>
>
> Is it not possible for ia64's ->set_affini
r the cross post to lia64 ]
--
Cheers,
Ashok Raj
- Open Source Technology Center
---
fix_ia64_smp_affinity - Make GENERIC_HARDIRQ work for IPF and CPU Hotplug
Signed-off-by: Ashok Raj <[EMAIL PROTECTED]>
Made GENERIC_HARDIRQ mechanism work for IPF and CPU hotplug. When write to
/proc/irq
101 - 177 of 177 matches
Mail list logo
