linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
@ 2013-07-09 20:24 Guenter Roeck
  2013-07-09 21:05 ` Bjorn Helgaas
  0 siblings, 1 reply; 13+ messages in thread
From: Guenter Roeck @ 2013-07-09 20:24 UTC (permalink / raw)
  To: linux-kernel

I started seeing this problem after updating the BIOS trying fix another issue,
though I may have missed it earlier.

I understand this is a BIOS bug. Would be great if someone can pass this on
to Intel BIOS engineers.

CPU is i7-4770K.

Guenter

---

[    0.000000] WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar+0x86/0xa0()
[    0.000000] Your BIOS is broken; DMAR reported at address 0!
[    0.000000] BIOS vendor: Intel Corp.; Ver: RLH8710H.86A.0320.2013.0606.1802; Product Version:
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0+ #1
[    0.000000] Hardware name:                  /DH87RL, BIOS RLH8710H.86A.0320.2013.0606.1802 06/06/2013
[    0.000000]  000000000000000b ffffffff81c01e20 ffffffff81671cfc ffffffff81c01e68
[    0.000000]  ffffffff81c01e58 ffffffff81043370 ffffffff81f6800c ffffffff81cbb520
[    0.000000]  0000000000000000 ffff88061fdaad40 00000000c73cc018 ffffffff81c01eb8
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff81671cfc>] dump_stack+0x45/0x56
[    0.000000]  [<ffffffff81043370>] warn_slowpath_common+0x70/0xa0
[    0.000000]  [<ffffffff81043404>] warn_slowpath_fmt_taint+0x44/0x50
[    0.000000]  [<ffffffff81d162eb>] ? early_ioremap+0x13/0x15
[    0.000000]  [<ffffffff81d0d6a6>] ? __acpi_map_table+0x13/0x1a
[    0.000000]  [<ffffffff81548bf6>] warn_invalid_dmar+0x86/0xa0
[    0.000000]  [<ffffffff81d4b994>] check_zero_address+0x57/0xf7
[    0.000000]  [<ffffffff81d4ba49>] detect_intel_iommu+0x15/0xb6
[    0.000000]  [<ffffffff81d07d28>] pci_iommu_alloc+0x49/0x70
[    0.000000]  [<ffffffff81d15de4>] mem_init+0x17/0x9c
[    0.000000]  [<ffffffff81d01c54>] start_kernel+0x1c5/0x3e2
[    0.000000]  [<ffffffff81d01898>] ? repair_env_string+0x5e/0x5e
[    0.000000]  [<ffffffff81d015a3>] x86_64_start_reservations+0x2a/0x2c
[    0.000000]  [<ffffffff81d0169b>] x86_64_start_kernel+0xf6/0xf9
[    0.000000] ---[ end trace a7e3512e2fa85eaf ]---

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-09 20:24 WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard Guenter Roeck
@ 2013-07-09 21:05 ` Bjorn Helgaas
  2013-07-09 22:31   ` Guenter Roeck
  0 siblings, 1 reply; 13+ messages in thread
From: Bjorn Helgaas @ 2013-07-09 21:05 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: linux-kernel@vger.kernel.org, Joerg Roedel,
	open list:INTEL IOMMU (VT-d), David Woodhouse

[+cc Joerg, David, iommu list]

On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> I started seeing this problem after updating the BIOS trying fix another issue,
> though I may have missed it earlier.
>
> I understand this is a BIOS bug. Would be great if someone can pass this on
> to Intel BIOS engineers.

Maybe.  It'd be nice if Linux handled it better, though.

> CPU is i7-4770K.
>
> Guenter
>
> ---
>
> [    0.000000] WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar+0x86/0xa0()
> [    0.000000] Your BIOS is broken; DMAR reported at address 0!
> [    0.000000] BIOS vendor: Intel Corp.; Ver: RLH8710H.86A.0320.2013.0606.1802; Product Version:
> [    0.000000] Modules linked in:
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0+ #1
> [    0.000000] Hardware name:                  /DH87RL, BIOS RLH8710H.86A.0320.2013.0606.1802 06/06/2013
> [    0.000000]  000000000000000b ffffffff81c01e20 ffffffff81671cfc ffffffff81c01e68
> [    0.000000]  ffffffff81c01e58 ffffffff81043370 ffffffff81f6800c ffffffff81cbb520
> [    0.000000]  0000000000000000 ffff88061fdaad40 00000000c73cc018 ffffffff81c01eb8
> [    0.000000] Call Trace:
> [    0.000000]  [<ffffffff81671cfc>] dump_stack+0x45/0x56
> [    0.000000]  [<ffffffff81043370>] warn_slowpath_common+0x70/0xa0
> [    0.000000]  [<ffffffff81043404>] warn_slowpath_fmt_taint+0x44/0x50
> [    0.000000]  [<ffffffff81d162eb>] ? early_ioremap+0x13/0x15
> [    0.000000]  [<ffffffff81d0d6a6>] ? __acpi_map_table+0x13/0x1a
> [    0.000000]  [<ffffffff81548bf6>] warn_invalid_dmar+0x86/0xa0
> [    0.000000]  [<ffffffff81d4b994>] check_zero_address+0x57/0xf7
> [    0.000000]  [<ffffffff81d4ba49>] detect_intel_iommu+0x15/0xb6
> [    0.000000]  [<ffffffff81d07d28>] pci_iommu_alloc+0x49/0x70
> [    0.000000]  [<ffffffff81d15de4>] mem_init+0x17/0x9c
> [    0.000000]  [<ffffffff81d01c54>] start_kernel+0x1c5/0x3e2
> [    0.000000]  [<ffffffff81d01898>] ? repair_env_string+0x5e/0x5e
> [    0.000000]  [<ffffffff81d015a3>] x86_64_start_reservations+0x2a/0x2c
> [    0.000000]  [<ffffffff81d0169b>] x86_64_start_kernel+0xf6/0xf9
> [    0.000000] ---[ end trace a7e3512e2fa85eaf ]---
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-09 21:05 ` Bjorn Helgaas
@ 2013-07-09 22:31   ` Guenter Roeck
  2013-07-09 23:22     ` Chris Wright
  2013-08-14  9:36     ` Joerg Roedel
  0 siblings, 2 replies; 13+ messages in thread
From: Guenter Roeck @ 2013-07-09 22:31 UTC (permalink / raw)
  To: Bjorn Helgaas
  Cc: linux-kernel@vger.kernel.org, Joerg Roedel,
	open list:INTEL IOMMU (VT-d), David Woodhouse

On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> [+cc Joerg, David, iommu list]
> 
> On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > I started seeing this problem after updating the BIOS trying fix another issue,
> > though I may have missed it earlier.
> >
> > I understand this is a BIOS bug. Would be great if someone can pass this on
> > to Intel BIOS engineers.
> 
> Maybe.  It'd be nice if Linux handled it better, though.
> 
If anyone has an idea how to do that, I'll be happy to write a patch.

Guenter

> > CPU is i7-4770K.
> >
> > Guenter
> >
> > ---
> >
> > [    0.000000] WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar+0x86/0xa0()
> > [    0.000000] Your BIOS is broken; DMAR reported at address 0!
> > [    0.000000] BIOS vendor: Intel Corp.; Ver: RLH8710H.86A.0320.2013.0606.1802; Product Version:
> > [    0.000000] Modules linked in:
> > [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0+ #1
> > [    0.000000] Hardware name:                  /DH87RL, BIOS RLH8710H.86A.0320.2013.0606.1802 06/06/2013
> > [    0.000000]  000000000000000b ffffffff81c01e20 ffffffff81671cfc ffffffff81c01e68
> > [    0.000000]  ffffffff81c01e58 ffffffff81043370 ffffffff81f6800c ffffffff81cbb520
> > [    0.000000]  0000000000000000 ffff88061fdaad40 00000000c73cc018 ffffffff81c01eb8
> > [    0.000000] Call Trace:
> > [    0.000000]  [<ffffffff81671cfc>] dump_stack+0x45/0x56
> > [    0.000000]  [<ffffffff81043370>] warn_slowpath_common+0x70/0xa0
> > [    0.000000]  [<ffffffff81043404>] warn_slowpath_fmt_taint+0x44/0x50
> > [    0.000000]  [<ffffffff81d162eb>] ? early_ioremap+0x13/0x15
> > [    0.000000]  [<ffffffff81d0d6a6>] ? __acpi_map_table+0x13/0x1a
> > [    0.000000]  [<ffffffff81548bf6>] warn_invalid_dmar+0x86/0xa0
> > [    0.000000]  [<ffffffff81d4b994>] check_zero_address+0x57/0xf7
> > [    0.000000]  [<ffffffff81d4ba49>] detect_intel_iommu+0x15/0xb6
> > [    0.000000]  [<ffffffff81d07d28>] pci_iommu_alloc+0x49/0x70
> > [    0.000000]  [<ffffffff81d15de4>] mem_init+0x17/0x9c
> > [    0.000000]  [<ffffffff81d01c54>] start_kernel+0x1c5/0x3e2
> > [    0.000000]  [<ffffffff81d01898>] ? repair_env_string+0x5e/0x5e
> > [    0.000000]  [<ffffffff81d015a3>] x86_64_start_reservations+0x2a/0x2c
> > [    0.000000]  [<ffffffff81d0169b>] x86_64_start_kernel+0xf6/0xf9
> > [    0.000000] ---[ end trace a7e3512e2fa85eaf ]---
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-09 22:31   ` Guenter Roeck
@ 2013-07-09 23:22     ` Chris Wright
  2013-07-09 23:43       ` Guenter Roeck
  2013-08-14  9:36     ` Joerg Roedel
  1 sibling, 1 reply; 13+ messages in thread
From: Chris Wright @ 2013-07-09 23:22 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Bjorn Helgaas, David Woodhouse, linux-kernel@vger.kernel.org,
	open list:INTEL IOMMU (VT-d)

* Guenter Roeck (linux@roeck-us.net) wrote:
> On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> > [+cc Joerg, David, iommu list]
> > 
> > On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > > I started seeing this problem after updating the BIOS trying fix another issue,
> > > though I may have missed it earlier.
> > >
> > > I understand this is a BIOS bug. Would be great if someone can pass this on
> > > to Intel BIOS engineers.
> > 
> > Maybe.  It'd be nice if Linux handled it better, though.
> > 
> If anyone has an idea how to do that, I'll be happy to write a patch.

I'm not sure there's much you can do.  The BIOS is saying there's a DMAR
unit, and then saying the registers are at addr 0x0.  The kernel is
simply warning you about the invalid DMAR table entry.

One thing I've seen is the BIOS zeroing the base register address when
VT-d is disabled in BIOS.  So, Guenter, a "fix" may be simply enabling
VT-d in the BIOS.

thanks,
-chris

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-09 23:22     ` Chris Wright
@ 2013-07-09 23:43       ` Guenter Roeck
  2013-07-10  0:05         ` Chris Wright
  2013-07-11 19:00         ` Chris Wright
  0 siblings, 2 replies; 13+ messages in thread
From: Guenter Roeck @ 2013-07-09 23:43 UTC (permalink / raw)
  To: Chris Wright
  Cc: Bjorn Helgaas, David Woodhouse, linux-kernel@vger.kernel.org,
	open list:INTEL IOMMU (VT-d)

On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> * Guenter Roeck (linux@roeck-us.net) wrote:
> > On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> > > [+cc Joerg, David, iommu list]
> > > 
> > > On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > > > I started seeing this problem after updating the BIOS trying fix another issue,
> > > > though I may have missed it earlier.
> > > >
> > > > I understand this is a BIOS bug. Would be great if someone can pass this on
> > > > to Intel BIOS engineers.
> > > 
> > > Maybe.  It'd be nice if Linux handled it better, though.
> > > 
> > If anyone has an idea how to do that, I'll be happy to write a patch.
> 
> I'm not sure there's much you can do.  The BIOS is saying there's a DMAR
> unit, and then saying the registers are at addr 0x0.  The kernel is
> simply warning you about the invalid DMAR table entry.
> 
> One thing I've seen is the BIOS zeroing the base register address when
> VT-d is disabled in BIOS.  So, Guenter, a "fix" may be simply enabling
> VT-d in the BIOS.
> 
Ah, yes, I think I may have that disabled. I'll check it tonight.

Does that really warrant a traceback, or would a warning message be more
appropriate (possibly telling the user to enable VT-d) ?

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-09 23:43       ` Guenter Roeck
@ 2013-07-10  0:05         ` Chris Wright
  2013-07-10  0:18           ` Guenter Roeck
  2013-07-11 19:00         ` Chris Wright
  1 sibling, 1 reply; 13+ messages in thread
From: Chris Wright @ 2013-07-10  0:05 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Chris Wright, Bjorn Helgaas, open list:INTEL IOMMU (VT-d),
	David Woodhouse, linux-kernel@vger.kernel.org

* Guenter Roeck (linux@roeck-us.net) wrote:
> On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > * Guenter Roeck (linux@roeck-us.net) wrote:
> > > On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> > > > [+cc Joerg, David, iommu list]
> > > > 
> > > > On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > I started seeing this problem after updating the BIOS trying fix another issue,
> > > > > though I may have missed it earlier.
> > > > >
> > > > > I understand this is a BIOS bug. Would be great if someone can pass this on
> > > > > to Intel BIOS engineers.
> > > > 
> > > > Maybe.  It'd be nice if Linux handled it better, though.
> > > > 
> > > If anyone has an idea how to do that, I'll be happy to write a patch.
> > 
> > I'm not sure there's much you can do.  The BIOS is saying there's a DMAR
> > unit, and then saying the registers are at addr 0x0.  The kernel is
> > simply warning you about the invalid DMAR table entry.
> > 
> > One thing I've seen is the BIOS zeroing the base register address when
> > VT-d is disabled in BIOS.  So, Guenter, a "fix" may be simply enabling
> > VT-d in the BIOS.
>
> Ah, yes, I think I may have that disabled. I'll check it tonight.
> 
> Does that really warrant a traceback, or would a warning message be more
> appropriate (possibly telling the user to enable VT-d) ?

Bottom line, the BIOS is providing what we're seeing as invalid tables.
If it's a BIOS attempt to disable VT-d is hard to glean from invalid
tables, and not all BIOS give interface to enable/disable VT-d.

It is a warning message, BTW.  Guess I'd be inclined to leave as it is.

thanks,
-chris

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-10  0:05         ` Chris Wright
@ 2013-07-10  0:18           ` Guenter Roeck
  2013-07-10  0:53             ` David Woodhouse
  0 siblings, 1 reply; 13+ messages in thread
From: Guenter Roeck @ 2013-07-10  0:18 UTC (permalink / raw)
  To: Chris Wright
  Cc: Bjorn Helgaas, open list:INTEL IOMMU (VT-d), David Woodhouse,
	linux-kernel@vger.kernel.org

On Tue, Jul 09, 2013 at 05:05:11PM -0700, Chris Wright wrote:
> * Guenter Roeck (linux@roeck-us.net) wrote:
> > On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > > * Guenter Roeck (linux@roeck-us.net) wrote:
> > > > On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> > > > > [+cc Joerg, David, iommu list]
> > > > > 
> > > > > On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > > I started seeing this problem after updating the BIOS trying fix another issue,
> > > > > > though I may have missed it earlier.
> > > > > >
> > > > > > I understand this is a BIOS bug. Would be great if someone can pass this on
> > > > > > to Intel BIOS engineers.
> > > > > 
> > > > > Maybe.  It'd be nice if Linux handled it better, though.
> > > > > 
> > > > If anyone has an idea how to do that, I'll be happy to write a patch.
> > > 
> > > I'm not sure there's much you can do.  The BIOS is saying there's a DMAR
> > > unit, and then saying the registers are at addr 0x0.  The kernel is
> > > simply warning you about the invalid DMAR table entry.
> > > 
> > > One thing I've seen is the BIOS zeroing the base register address when
> > > VT-d is disabled in BIOS.  So, Guenter, a "fix" may be simply enabling
> > > VT-d in the BIOS.
> >
> > Ah, yes, I think I may have that disabled. I'll check it tonight.
> > 
> > Does that really warrant a traceback, or would a warning message be more
> > appropriate (possibly telling the user to enable VT-d) ?
> 
> Bottom line, the BIOS is providing what we're seeing as invalid tables.
> If it's a BIOS attempt to disable VT-d is hard to glean from invalid
> tables, and not all BIOS give interface to enable/disable VT-d.
> 
> It is a warning message, BTW.  Guess I'd be inclined to leave as it is.
> 
I meant warning as in pr_warn or dev_warn, not WARNING as in traceback.
Keep in mind that a casual user doesn't expect to see a traceback and will tend
to get alarmed. Several bugs have been filed against this "issue" in various
distributions, which is not surprising given the alarmist message.
What is the point of that ?

Guenter

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-10  0:18           ` Guenter Roeck
@ 2013-07-10  0:53             ` David Woodhouse
  2013-07-10  3:55               ` Guenter Roeck
  0 siblings, 1 reply; 13+ messages in thread
From: David Woodhouse @ 2013-07-10  0:53 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Chris Wright, Bjorn Helgaas, open list:INTEL IOMMU (VT-d),
	linux-kernel@vger.kernel.org

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On Tue, 2013-07-09 at 17:18 -0700, Guenter Roeck wrote:
> 
> I meant warning as in pr_warn or dev_warn, not WARNING as in traceback.
> Keep in mind that a casual user doesn't expect to see a traceback and will tend
> to get alarmed. Several bugs have been filed against this "issue" in various
> distributions, which is not surprising given the alarmist message.
> What is the point of that ?

It is warning you that your hardware is broken. Take it back to the
place from which you purchased it, and ask for your money back if it
isn't fixed.

(Slightly) more seriously, this level of warning *does* get things
fixed, and when kerneloops was running it made it very easy to track
this kind of issue and apply pressure where it was needed to improve
quality.

Any user who has taken the trouble to file bugs has *also* taken it up
with their firmware vendor, I hope?

-- 
dwmw2


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-10  0:53             ` David Woodhouse
@ 2013-07-10  3:55               ` Guenter Roeck
  0 siblings, 0 replies; 13+ messages in thread
From: Guenter Roeck @ 2013-07-10  3:55 UTC (permalink / raw)
  To: David Woodhouse
  Cc: Chris Wright, Bjorn Helgaas, open list:INTEL IOMMU (VT-d),
	linux-kernel@vger.kernel.org

On Wed, Jul 10, 2013 at 01:53:15AM +0100, David Woodhouse wrote:
> On Tue, 2013-07-09 at 17:18 -0700, Guenter Roeck wrote:
> > 
> > I meant warning as in pr_warn or dev_warn, not WARNING as in traceback.
> > Keep in mind that a casual user doesn't expect to see a traceback and will tend
> > to get alarmed. Several bugs have been filed against this "issue" in various
> > distributions, which is not surprising given the alarmist message.
> > What is the point of that ?
> 
> It is warning you that your hardware is broken. Take it back to the
> place from which you purchased it, and ask for your money back if it
> isn't fixed.
> 
> (Slightly) more seriously, this level of warning *does* get things
> fixed, and when kerneloops was running it made it very easy to track
> this kind of issue and apply pressure where it was needed to improve
> quality.
> 
> Any user who has taken the trouble to file bugs has *also* taken it up
> with their firmware vendor, I hope?
> 
No idea ... but have you ever tried that as a private entity ?

If there is a secret list of people to contact at vendor X to get things
like this one fixed, please let me know ;).

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-09 23:43       ` Guenter Roeck
  2013-07-10  0:05         ` Chris Wright
@ 2013-07-11 19:00         ` Chris Wright
  2013-07-11 20:59           ` Guenter Roeck
  1 sibling, 1 reply; 13+ messages in thread
From: Chris Wright @ 2013-07-11 19:00 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Chris Wright, Bjorn Helgaas, David Woodhouse,
	linux-kernel@vger.kernel.org, open list:INTEL IOMMU (VT-d)

* Guenter Roeck (linux@roeck-us.net) wrote:
> On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > One thing I've seen is the BIOS zeroing the base register address when
> > VT-d is disabled in BIOS.  So, Guenter, a "fix" may be simply enabling
> > VT-d in the BIOS.
> > 
> Ah, yes, I think I may have that disabled. I'll check it tonight.

Did you find out if BIOS change fixed this?

thanks,
-chris

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-11 19:00         ` Chris Wright
@ 2013-07-11 20:59           ` Guenter Roeck
  2013-07-11 22:31             ` Chris Wright
  0 siblings, 1 reply; 13+ messages in thread
From: Guenter Roeck @ 2013-07-11 20:59 UTC (permalink / raw)
  To: Chris Wright
  Cc: Bjorn Helgaas, David Woodhouse, linux-kernel@vger.kernel.org,
	open list:INTEL IOMMU (VT-d)

On Thu, Jul 11, 2013 at 12:00:54PM -0700, Chris Wright wrote:
> * Guenter Roeck (linux@roeck-us.net) wrote:
> > On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > > One thing I've seen is the BIOS zeroing the base register address when
> > > VT-d is disabled in BIOS.  So, Guenter, a "fix" may be simply enabling
> > > VT-d in the BIOS.
> > > 
> > Ah, yes, I think I may have that disabled. I'll check it tonight.
> 
> Did you find out if BIOS change fixed this?
> 
No, it didn't. Enabling or disabling virtualization in the BIOS did not make
a difference. It looks like there is a bad DMAR table entry (with address 0)
in the ACPI data. In case you are interested how it looks like:

DMAR @ 0xcb3f3f90
  0000: 44 4d 41 52 90 00 00 00 01 d5 49 4e 54 45 4c 20  DMAR......INTEL
  0010: 44 48 38 37 52 4c 20 20 40 01 00 00 49 4e 54 4c  DH87RL  @...INTL
  0020: 01 00 00 00 26 00 00 00 00 00 00 00 00 00 00 00  ....&...........
  0030: 00 00 10 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  0040: 01 00 30 00 00 00 00 00 00 b0 eb cb 00 00 00 00  ..0.............
  0050: ff 9f ec cb 00 00 00 00 01 08 00 00 00 00 1d 00  ................
  0060: 01 08 00 00 00 00 1a 00 01 08 00 00 00 00 14 00  ................
  0070: 01 00 20 00 00 00 00 00 00 00 00 d7 00 00 00 00  .. .............
  0080: ff ff 1f df 00 00 00 00 01 08 00 00 00 00 02 00  ................

Turns out the i7-4770K doesn't support VT-d, so my current understanding
is that there should be no DMAR table in the first place.

Guenter

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-11 20:59           ` Guenter Roeck
@ 2013-07-11 22:31             ` Chris Wright
  0 siblings, 0 replies; 13+ messages in thread
From: Chris Wright @ 2013-07-11 22:31 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Chris Wright, Bjorn Helgaas, David Woodhouse,
	linux-kernel@vger.kernel.org, open list:INTEL IOMMU (VT-d)

* Guenter Roeck (linux@roeck-us.net) wrote:
> On Thu, Jul 11, 2013 at 12:00:54PM -0700, Chris Wright wrote:
> > * Guenter Roeck (linux@roeck-us.net) wrote:
> > > On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > > > One thing I've seen is the BIOS zeroing the base register address when
> > > > VT-d is disabled in BIOS.  So, Guenter, a "fix" may be simply enabling
> > > > VT-d in the BIOS.
> > > > 
> > > Ah, yes, I think I may have that disabled. I'll check it tonight.
> > 
> > Did you find out if BIOS change fixed this?
> > 
> No, it didn't. Enabling or disabling virtualization in the BIOS did not make
> a difference. It looks like there is a bad DMAR table entry (with address 0)
> in the ACPI data. In case you are interested how it looks like:
> 
> DMAR @ 0xcb3f3f90
>   0000: 44 4d 41 52 90 00 00 00 01 d5 49 4e 54 45 4c 20  DMAR......INTEL
>   0010: 44 48 38 37 52 4c 20 20 40 01 00 00 49 4e 54 4c  DH87RL  @...INTL
>   0020: 01 00 00 00 26 00 00 00 00 00 00 00 00 00 00 00  ....&...........
>   0030: 00 00 10 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
>   0040: 01 00 30 00 00 00 00 00 00 b0 eb cb 00 00 00 00  ..0.............
>   0050: ff 9f ec cb 00 00 00 00 01 08 00 00 00 00 1d 00  ................
>   0060: 01 08 00 00 00 00 1a 00 01 08 00 00 00 00 14 00  ................
>   0070: 01 00 20 00 00 00 00 00 00 00 00 d7 00 00 00 00  .. .............
>   0080: ff ff 1f df 00 00 00 00 01 08 00 00 00 00 02 00  ................
> 
> Turns out the i7-4770K doesn't support VT-d, so my current understanding
> is that there should be no DMAR table in the first place.

OK, thanks for follow-up.  You can see why the warnings are there now.
This is your decoded DMAR table...has valid looking RMRR regions, and
mostly valid looking DRHD (minus the invalid base address).


/*
 * Intel ACPI Component Architecture
 * AML Disassembler version 20100528
 *
 * Disassembly of /tmp/dmar, Thu Jul 11 15:24:28 2013
 *
 * ACPI Data Table [DMAR]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h 0000  4]                    Signature : "DMAR"    /* DMA Remapping table */
[004h 0004  4]                 Table Length : 00000090
[008h 0008  1]                     Revision : 01
[009h 0009  1]                     Checksum : D5
[00Ah 0010  6]                       Oem ID : "INTEL "
[010h 0016  8]                 Oem Table ID : "DH87RL  "
[018h 0024  4]                 Oem Revision : 00000140
[01Ch 0028  4]              Asl Compiler ID : "INTL"
[020h 0032  4]        Asl Compiler Revision : 00000001

[024h 0036  1]           Host Address Width : 26
[025h 0037  1]                        Flags : 00

[030h 0048  2]                Subtable Type : 0000 <Hardware Unit Definition>
[032h 0050  2]                       Length : 0010
[034h 0052  1]                        Flags : 01
[035h 0053  1]                     Reserved : 00
[036h 0054  2]           PCI Segment Number : 0000
[038h 0056  8]        Register Base Address : 0000000000000000

[040h 0064  2]                Subtable Type : 0001 <Reserved Memory Region>
[042h 0066  2]                       Length : 0030
[044h 0068  2]                     Reserved : 0000
[046h 0070  2]           PCI Segment Number : 0000
[048h 0072  8]                 Base Address : 00000000CBEBB000
[050h 0080  8]          End Address (limit) : 00000000CBEC9FFF

[058h 0088  1]      Device Scope Entry Type : 01
[059h 0089  1]                 Entry Length : 08
[05Ah 0090  2]                     Reserved : 0000
[05Ch 0092  1]               Enumeration ID : 00
[05Dh 0093  1]               PCI Bus Number : 00
[05Eh 0094  2]                     PCI Path : [1D, 00]

[060h 0096  1]      Device Scope Entry Type : 01
[061h 0097  1]                 Entry Length : 08
[062h 0098  2]                     Reserved : 0000
[064h 0100  1]               Enumeration ID : 00
[065h 0101  1]               PCI Bus Number : 00
[066h 0102  2]                     PCI Path : [1A, 00]

[068h 0104  1]      Device Scope Entry Type : 01
[069h 0105  1]                 Entry Length : 08
[06Ah 0106  2]                     Reserved : 0000
[06Ch 0108  1]               Enumeration ID : 00
[06Dh 0109  1]               PCI Bus Number : 00
[06Eh 0110  2]                     PCI Path : [14, 00]

[070h 0112  2]                Subtable Type : 0001 <Reserved Memory Region>
[072h 0114  2]                       Length : 0020
[074h 0116  2]                     Reserved : 0000
[076h 0118  2]           PCI Segment Number : 0000
[078h 0120  8]                 Base Address : 00000000D7000000
[080h 0128  8]          End Address (limit) : 00000000DF1FFFFF

[088h 0136  1]      Device Scope Entry Type : 01
[089h 0137  1]                 Entry Length : 08
[08Ah 0138  2]                     Reserved : 0000
[08Ch 0140  1]               Enumeration ID : 00
[08Dh 0141  1]               PCI Bus Number : 00
[08Eh 0142  2]                     PCI Path : [02, 00]

Raw Table Data

  0000: 44 4D 41 52 90 00 00 00 01 D5 49 4E 54 45 4C 20  DMAR......INTEL 
  0010: 44 48 38 37 52 4C 20 20 40 01 00 00 49 4E 54 4C  DH87RL  @...INTL
  0020: 01 00 00 00 26 00 00 00 00 00 00 00 00 00 00 00  ....&...........
  0030: 00 00 10 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
  0040: 01 00 30 00 00 00 00 00 00 B0 EB CB 00 00 00 00  ..0.............
  0050: FF 9F EC CB 00 00 00 00 01 08 00 00 00 00 1D 00  ................
  0060: 01 08 00 00 00 00 1A 00 01 08 00 00 00 00 14 00  ................
  0070: 01 00 20 00 00 00 00 00 00 00 00 D7 00 00 00 00  .. .............
  0080: FF FF 1F DF 00 00 00 00 01 08 00 00 00 00 02 00  ................

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard
  2013-07-09 22:31   ` Guenter Roeck
  2013-07-09 23:22     ` Chris Wright
@ 2013-08-14  9:36     ` Joerg Roedel
  1 sibling, 0 replies; 13+ messages in thread
From: Joerg Roedel @ 2013-08-14  9:36 UTC (permalink / raw)
  To: Guenter Roeck
  Cc: Bjorn Helgaas, linux-kernel@vger.kernel.org,
	open list:INTEL IOMMU (VT-d), David Woodhouse

On Tue, Jul 09, 2013 at 03:31:06PM -0700, Guenter Roeck wrote:
> On Tue, Jul 09, 2013 at 03:05:39PM -0600, Bjorn Helgaas wrote:
> > [+cc Joerg, David, iommu list]
> > 
> > On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck <linux@roeck-us.net> wrote:
> > > I started seeing this problem after updating the BIOS trying fix another issue,
> > > though I may have missed it earlier.
> > >
> > > I understand this is a BIOS bug. Would be great if someone can pass this on
> > > to Intel BIOS engineers.
> > 
> > Maybe.  It'd be nice if Linux handled it better, though.
> > 
> If anyone has an idea how to do that, I'll be happy to write a patch.

I doubt that we can do anything meaningful here. The BIOS is broken in a
way so that we can't use the IOMMU in Linux. We can patch away the
WARN_ON and make it a sumple FW_BUG message, but the noise a WARN_ON
makes maybe help getting this issue fixed.

But I may be convinced otherwise, if people think this WARN_ON is not
worth it.


	Joerg



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2013-08-14  9:36 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-09 20:24 WARNING: at drivers/iommu/dmar.c:484 warn_invalid_dmar with Intel Motherboard Guenter Roeck
2013-07-09 21:05 ` Bjorn Helgaas
2013-07-09 22:31   ` Guenter Roeck
2013-07-09 23:22     ` Chris Wright
2013-07-09 23:43       ` Guenter Roeck
2013-07-10  0:05         ` Chris Wright
2013-07-10  0:18           ` Guenter Roeck
2013-07-10  0:53             ` David Woodhouse
2013-07-10  3:55               ` Guenter Roeck
2013-07-11 19:00         ` Chris Wright
2013-07-11 20:59           ` Guenter Roeck
2013-07-11 22:31             ` Chris Wright
2013-08-14  9:36     ` Joerg Roedel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).