New: Infinite loop on bootup while handling DMAR

http://bugzilla.kernel.org/show_bug.cgi?id=14003

Summary: Infinite loop on bootup while handling DMAR

           Product: Drivers
           Version: 2.5
    Kernel Version: 2.6.31-rc6
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: PCI
        AssignedTo: [email protected]
        ReportedBy: [email protected]
        Regression: Yes

Booting 64bit 2.6.31-rc6 on a hp xw4600 results in an infinite loop of

DMAR:[DMA READ] Request device [ff:1f.7] fault addr fffffffffffff000 DMAR:[fault reason 255] Unknown

even with iommu=soft (2.6.30 could boot with iommu=soft, but would result in the same error with hardware iommu enabled).

2.6.30 reports this about the DMAR ACPI tables:

ACPI: DMAR 00000000defc247f 00158 (v01 COMPAQ BEARLX38 00000001 00000000)
DMAR:Host address width 36
DMAR:DRHD (flags: 0x00000000)base: 0x00000000fed90000 DMAR:DRHD (flags: 0x00000001)base: 0x00000000fed93000 DMAR:RMRR base: 0x00000000defd0000 end: 0x00000000defd0fff DMAR:RMRR base: 0x00000000defd1000 end: 0x00000000defd1fff DMAR:RMRR base: 0x00000000defd2000 end: 0x00000000defd2fff DMAR:RMRR base: 0x00000000defd3000 end: 0x00000000defd3fff DMAR:RMRR base: 0x00000000defd4000 end: 0x00000000defd4fff DMAR:RMRR base: 0x00000000defd5000 end: 0x00000000defd5fff DMAR:RMRR base: 0x00000000defd6000 end: 0x00000000defd6fff DMAR:RMRR base: 0x00000000defd7000 end: 0x00000000defd7fff Not all IO-APIC's listed under remapping hardware

Device ff:1f.7 doesn't actually exist, lspci -n says

00:00.0 0600: 8086:29e0
00:01.0 0604: 8086:29e1
00:1a.0 0c03: 8086:2937 (rev 02)
00:1a.1 0c03: 8086:2938 (rev 02)
00:1a.2 0c03: 8086:2939 (rev 02)
00:1a.7 0c03: 8086:293c (rev 02)
00:1b.0 0403: 8086:293e (rev 02)
00:1c.0 0604: 8086:2940 (rev 02)
00:1c.4 0604: 8086:2948 (rev 02)
00:1c.5 0604: 8086:294a (rev 02)
00:1d.0 0c03: 8086:2934 (rev 02)
00:1d.1 0c03: 8086:2935 (rev 02)
00:1d.2 0c03: 8086:2936 (rev 02)
00:1d.7 0c03: 8086:293a (rev 02)
00:1e.0 0604: 8086:244e (rev 92)
00:1f.0 0601: 8086:2916 (rev 02)
00:1f.2 0106: 8086:2922 (rev 02)
01:00.0 0300: 1002:7187
01:00.1 0380: 1002:71a7
10:0b.0 0c00: 11c1:5811 (rev 61)
3f:00.0 0200: 14e4:167b (rev 02)

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 3 lines · On Tue, 18 Aug 2009 14:54:22 GMT [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=14003

Summary: Infinite loop on bootup while handling DMAR

That's a box-killing post-2.6.30 regression.

Quoted 5 lines

Booting 64bit 2.6.31-rc6 on a hp xw4600 results in an infinite loop of

DMAR:[DMA READ] Request device [ff:1f.7] fault addr fffffffffffff000 DMAR:[fault reason 255] Unknown

Quoted 2 lines

http://bugzilla.kernel.org/show_bug.cgi?id=14003
Summary: Infinite loop on bootup while handling DMAR

That's a box-killing post-2.6.30 regression.

Quoted 3 lines · Andrew Morton

Quoted 2 lines

http://bugzilla.kernel.org/show_bug.cgi?id=14003
Summary: Infinite loop on bootup while handling DMAR

That's a box-killing post-2.6.30 regression.

It's a BIOS bug -- the user's BIOS is written by idiots who obviously shipped it without any QA whatsoever.

drivers/pci/dmar.c +5 -0

+		     dmi_get_system_info(DMI_BIOS_VENDOR),
+		     dmi_get_system_info(DMI_BIOS_VERSION),
+		     dmi_get_system_info(DMI_PRODUCT_VERSION));
+		goto err_unmap;
+	}

Printing a u64 with %ll will (still) generate a warning on four architectures.

drivers/pci/dmar.c int alloc_iommu(struct dmar_drhd_unit *drhd) · line 639

Quoted 5 lines · On Thu, 20 Aug 2009 09:01:58 +0100 David Woodhouse <[email protected]> wrote:

drivers/pci/dmar.c +5 -0

+	if (iommu->cap == (uint64_t)-1 && iommu->ecap == (uint64_t)-1) {
+		/* Promote an attitude of violence to a BIOS engineer today */
+		WARN(1, "Your BIOS is broken; DMAR reported at address %llx returns all ones!\n"
+		     "BIOS vendor: %s; Ver: %s; Product Version: %s\n",
+		     drhd->reg_base_addr,

Printing a u64 with %ll will (still) generate a warning on four architectures.

Quoted 2 lines · Andrew Morton

Printing a u64 with %ll will (still) generate a warning on four architectures.

Still that many? I thought we'd fixed them all already.

+       if (iommu->cap == (uint64_t)-1 && iommu->ecap == (uint64_t)-1) {
+               /* Promote an attitude of violence to a BIOS engineer today */
+               WARN(1, "Your BIOS is broken; DMAR reported at address %llx returns all ones!\n"

Think about changing this to a warning that "Your IOMMU appears to be disabled." All ones is, after all, the traditional hint that the device is turned off.

Quoted 3 lines · Ray Lee

Think about changing this to a warning that "Your IOMMU appears to be disabled." All ones is, after all, the traditional hint that the device is turned off.

Hints are all very well, but the BIOS provided an ACPI table explicitly telling us that there was an active IOMMU at this location.

Could that be to reserve address space that the "disabled" IOMMU might still be responding to?

Ie the BIOS hides the control registers so the OS won't talk to the device but the IOMMU might still attempt to lookup certain address ranges.

I'm more inclined to believe it's sloppiness on the part of the BIOS writers but thought this might be an alternative explanation.

Quoted 3 lines · Grant Grundler

I'm more inclined to believe it's sloppiness on the part of the BIOS writers but thought this might be an alternative explanation.

Nah, this is just the normal story: "We smoked too much crack and fried our brains, and we don't do any QA on the crap we write because that would leave fewer hours in the day for us to service our crack habit".

We _really_ need open source firmware.

Or at _least_ firmware written by competent engineers -- but I think we've all fairly much given up on that happening by now?