Why is my syslog telling me that my bios is broken?

Question

I found this in my syslog file, what can I do to fix it? Or is it even worth fixing?

Everything seems to be working correctly. Running 3.12.9-031209-generic.

WARNING: CPU: 0 PID: 0 at /home/apw/COD/linux/drivers/iommu/dmar.c:488 warn_invalid_dmar+0x8f/0xa0()
Your BIOS is broken; DMAR reported at address 0!
BIOS vendor: American Megatrends Inc.; Ver: F5; Product Version: To be filled by O.E.M.
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.9-031209-generic #201401251255
Hardware name: Gigabyte Technology Co., Ltd. Z87MX-D3H/Z87MX-D3H-CF, BIOS F5 08/02/2013
00000000000001e8 ffffffff81c01d98 ffffffff817433c6 00000000000017e0
ffffffff81c01de8 ffffffff81c01dd8 ffffffff810678ac ffffffff81c01e28
ffffffff81fd201c ffffffff81fd2058 ffffffff81dda2e0 ffff88022f5aad00
Call Trace:
[<ffffffff817433c6>] dump_stack+0x46/0x58
[<ffffffff810678ac>] warn_slowpath_common+0x8c/0xc0
[<ffffffff8106793f>] warn_slowpath_fmt_taint+0x3f/0x50
[<ffffffff8172dfbb>] ? acpi_os_map_memory+0x27/0x150
[<ffffffff816124af>] warn_invalid_dmar+0x8f/0xa0
[<ffffffff81d84944>] check_zero_address+0x57/0xf7
[<ffffffff81d849fb>] detect_intel_iommu+0x17/0xb8
[<ffffffff81d3a0db>] pci_iommu_alloc+0x44/0x6e
[<ffffffff81d49a5c>] mem_init+0x11/0xa2
[<ffffffff81d2fcfa>] start_kernel+0x1de/0x41e
[<ffffffff81d2f9ae>] ? do_early_param+0x87/0x87
[<ffffffff81d2f120>] ? early_idt_handlers+0x120/0x120
[<ffffffff81d2f5e8>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d2f6f2>] x86_64_start_kernel+0x108/0x117
---[ end trace 11d0aeb7d970f0a3 ]---

Solution

Best source I found that explains this if from Redhat. It is not specific to Ubuntu but related to the kernel (we all share) and your hardware giving back wrong information to the kernel.

Exchange Redhat for Ubuntu in the text copied from the link and mind the 3 bullet points (maybe you can use that to circumvent this):

---

Systems fail to boot, USB is not functional, network adapter fails to work (or possibly other symptoms) due to imperfect handling of BIOSes with broken IOMMU handling

• Bugzilla: #524808 and Bugzilla: #533952

Some manufacturers ship systems with a BIOS whose handling of IOMMU hardware is incorrect. The BIOS is supposed to tell the operating system where in memory to find the IOMMU hardware, but some BIOSes do not do so correctly, providing a garbage location or a location which is valid but is not actually where the device is located. The kernel attempts to handle these cases, but some were still not fully handled in the Fedora 12 release kernel. If you have a system affected by this problem, the most common symptom is that the USB subsystem will fail to work (no USB peripherals will work), but other symptoms have included systems that completely fail to boot, and non-functional network adapters.

There are some systems currently known to be potentially affected by this issue. For all of those except the HP xw4600 Workstation and the Dell Precision M6400, all of the following conditions must be true before you hit the bug:

• You must be using the 32-bit edition of Fedora 12
• You must have no memory beyond the 4GB address area (practically speaking, this means you must have around 2.5GB of physical RAM or less)
• Virtualization features (VT-d) must be disabled in the BIOS

If any of the above is not the case, you should not encounter this issue. If you think you may be suffering from this issue, look for a kernel log message including something similar to:

Your BIOS is broken; DMAR reported at address fed10000 returns all ones!

or:

Your BIOS is broken; DMAR reported at address zero!

Please note that if you are using a system with such a broken BIOS, the kernel message will always appear, even if the kernel in fact handles your case correctly, or you have successfully worked around the issue. So don't worry that you still see the message once you have worked around the problem.

There are several ways to work around this issue. In most cases (see above), installing the 64-bit edition of Fedora 12 would be enough. If your BIOS has an option for it, enabling virtualization features in the BIOS should also work around this problem. Finally, you can work around this issue by appending the kernel parameter iommu=soft to your boot configuration.

An updated kernel package has been released to address this issue. Update your system as usual to receive this update, if you do not yet already have it. Obviously, if you are affected by the problem, you will need to use one of the above workarounds to first bring your system to a state from which you can install a fixed kernel.