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 ]---
[+cc Joerg, David, iommu list]
On Tue, Jul 9, 2013 at 2:24 PM, Guenter Roeck <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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 <[email protected]> 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 [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> * Guenter Roeck ([email protected]) 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 <[email protected]> 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
* Guenter Roeck ([email protected]) 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 <[email protected]> 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
* Guenter Roeck ([email protected]) wrote:
> On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > * Guenter Roeck ([email protected]) 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 <[email protected]> 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
On Tue, Jul 09, 2013 at 05:05:11PM -0700, Chris Wright wrote:
> * Guenter Roeck ([email protected]) wrote:
> > On Tue, Jul 09, 2013 at 04:22:52PM -0700, Chris Wright wrote:
> > > * Guenter Roeck ([email protected]) 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 <[email protected]> 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
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
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
* Guenter Roeck ([email protected]) 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
On Thu, Jul 11, 2013 at 12:00:54PM -0700, Chris Wright wrote:
> * Guenter Roeck ([email protected]) 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
* Guenter Roeck ([email protected]) wrote:
> On Thu, Jul 11, 2013 at 12:00:54PM -0700, Chris Wright wrote:
> > * Guenter Roeck ([email protected]) 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 ................
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 <[email protected]> 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