Skip to contentSkip to conversation

x86: Fix boot on Twinhead H12Y

PATCH In review Alan Cox 4 participants 6 messages May 15, 2012 – May 17, 2012

Subsystems (2)
lore
Share & tools
lore

Alan Cox

author
#0 lore raw

PATCH 1/1 x86: Fix boot on Twinhead H12Y

From: Alan Cox <[email protected]>

Despite lots of investigation into why this is needed we don't know or have an elegant cure. The only answer found on this laptop is to mark a problem region as used so that Linux doesn't put anything there.

Currently all the users add reserve= command lines and anyone not knowing this needs to find the magic page that documents it. Automate it instead.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=10231
---

 arch/x86/pci/fixup.c |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)
arch/x86/pci/fixup.c +19 -0
index d0e6e40..40b3eb8 100644
@@ -519,3 +519,22 @@ static void sb600_disable_hpet_bar(struct pci_dev *dev)
 	}
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_ATI, 0x4385, sb600_disable_hpet_bar);
+
+/*
+ * Twinhead H12Y needs us to block out a region otherwise we map devices
+ * there and any access kills the box.
+ * See: https://bugzilla.kernel.org/show_bug.cgi?id=10231
+ *
+ * Match off the LPC and svid/sdid (older kernels lose the bridge subvendor)
+ */
+
+static void __devinit twinhead_reserve_killing_zone(struct pci_dev *dev)
+{
+        if (dev->subsystem_vendor == 0x14FF && dev->subsystem_device ==
+                                        0xA003) {
+                pr_info("Reserving memory on Twinhead H12Y\n");
+                request_mem_region(0xFFB00000, 0x100000, "twinhead");
+        }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x27B9,
+                                twinhead_reserve_killing_zone);
#1 lore raw
Quoted 3 lines · Alan Cox

Despite lots of investigation into why this is needed we don't know or have an elegant cure. The only answer found on this laptop is to mark a problem region as used so that Linux doesn't put anything there.

trivia:

arch/x86/pci/fixup.c

Quoted 1 line
arch/x86/pci/fixup.c +0 -0

[]

arch/x86/pci/fixup.c static void sb600_disable_hpet_bar(struct pci_dev *dev)

Quoted 1 line
arch/x86/pci/fixup.c +0 -0
@@ -519,3 +519,22 @@ static void sb600_disable_hpet_bar(struct pci_dev *dev)

[]

arch/x86/pci/fixup.c static void sb600_disable_hpet_bar(struct pci_dev *dev) · line 534

Quoted 4 lines
arch/x86/pci/fixup.c +4 -0
+static void __devinit twinhead_reserve_killing_zone(struct pci_dev *dev)
+{
+        if (dev->subsystem_vendor == 0x14FF && dev->subsystem_device ==
+                                        0xA003) {

Doesn't this look ugly to you?
Doesn't

	if (dev->subsystem_vendor == 0x14FF &&
	    dev->subsystem_device == 0xA003) {

at least read more easily?

author
#2 lore raw
Quoted 19 lines · On Tue, 15 May 2012 09:52:07 -0700 Joe Perches <[email protected]> wrote:
Quoted 3 lines · Alan Cox

Despite lots of investigation into why this is needed we don't know or have an elegant cure. The only answer found on this laptop is to mark a problem region as used so that Linux doesn't put anything there.

trivia:

arch/x86/pci/fixup.c

Quoted 1 line
arch/x86/pci/fixup.c +0 -0

[]

arch/x86/pci/fixup.c static void sb600_disable_hpet_bar(struct pci_dev *dev)

Quoted 1 line
arch/x86/pci/fixup.c +0 -0
@@ -519,3 +519,22 @@ static void sb600_disable_hpet_bar(struct pci_dev *dev)

[]

arch/x86/pci/fixup.c static void sb600_disable_hpet_bar(struct pci_dev *dev) · line 534

Quoted 4 lines
arch/x86/pci/fixup.c +4 -0
+static void __devinit twinhead_reserve_killing_zone(struct pci_dev *dev)
+{
+        if (dev->subsystem_vendor == 0x14FF && dev->subsystem_device ==
+                                        0xA003) {

Doesn't this look ugly to you?
Doesn't

Quoted 4 lines
	if (dev->subsystem_vendor == 0x14FF &&
	    dev->subsystem_device == 0xA003) {

at least read more easily?

Well I'd further indent the second half so your eyes drop across reading left to right, but to be honest I'd have put it on one line but for the 80columnists.

If thats the only problem anyone has with it then I'm fine in adding a tab or two.

#3 lore raw
In reply to Alan Cox
Commit-ID:  80b3e557371205566a71e569fbfcce5b11f92dbe
Gitweb:     http://git.kernel.org/tip/80b3e557371205566a71e569fbfcce5b11f92dbe
Author:     Alan Cox <[email protected]>
AuthorDate: Tue, 15 May 2012 18:44:15 +0100
Committer:  Ingo Molnar <[email protected]>
CommitDate: Thu, 17 May 2012 20:04:00 +0200

x86: Fix boot on Twinhead H12Y

Despite lots of investigation into why this is needed we don't know or have an elegant cure. The only answer found on this laptop is to mark a problem region as used so that Linux doesn't put anything there.

Currently all the users add reserve= command lines and anyone not knowing this needs to find the magic page that documents it. Automate it instead.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=10231

---
 arch/x86/pci/fixup.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)
arch/x86/pci/fixup.c +17 -0
index d0e6e40..5dd467b 100644
@@ -519,3 +519,20 @@ static void sb600_disable_hpet_bar(struct pci_dev *dev)
 	}
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_ATI, 0x4385, sb600_disable_hpet_bar);
+
+/*
+ * Twinhead H12Y needs us to block out a region otherwise we map devices
+ * there and any access kills the box.
+ *
+ *   See: https://bugzilla.kernel.org/show_bug.cgi?id=10231
+ *
+ * Match off the LPC and svid/sdid (older kernels lose the bridge subvendor)
+ */
+static void __devinit twinhead_reserve_killing_zone(struct pci_dev *dev)
+{
+        if (dev->subsystem_vendor == 0x14FF && dev->subsystem_device == 0xA003) {
+                pr_info("Reserving memory on Twinhead H12Y\n");
+                request_mem_region(0xFFB00000, 0x100000, "twinhead");
+        }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x27B9, twinhead_reserve_killing_zone);
#4 lore raw
Quoted 42 lines · tip-bot for Alan Cox
Commit-ID:  80b3e557371205566a71e569fbfcce5b11f92dbe
Gitweb:     http://git.kernel.org/tip/80b3e557371205566a71e569fbfcce5b11f92dbe
Author:     Alan Cox <[email protected]>
AuthorDate: Tue, 15 May 2012 18:44:15 +0100
Committer:  Ingo Molnar <[email protected]>
CommitDate: Thu, 17 May 2012 20:04:00 +0200

x86: Fix boot on Twinhead H12Y

Despite lots of investigation into why this is needed we don't know or have an elegant cure. The only answer found on this laptop is to mark a problem region as used so that Linux doesn't put anything there.

Currently all the users add reserve= command lines and anyone not knowing this needs to find the magic page that documents it. Automate it instead.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=10231

---
 arch/x86/pci/fixup.c |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)
arch/x86/pci/fixup.c +7 -0
index d0e6e40..5dd467b 100644
@@ -519,3 +519,20 @@ static void sb600_disable_hpet_bar(struct pci_dev *dev)
 	}
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_ATI, 0x4385, sb600_disable_hpet_bar);
+
+/*
+ * Twinhead H12Y needs us to block out a region otherwise we map devices
+ * there and any access kills the box.
+ *
+ *   See: https://bugzilla.kernel.org/show_bug.cgi?id=10231
+ *

arch/x86/pci/fixup.c static void sb600_disable_hpet_bar(struct pci_dev *dev) · line 538

Quoted 10 lines
arch/x86/pci/fixup.c +10 -0
+ * Match off the LPC and svid/sdid (older kernels lose the bridge subvendor)
+ */
+static void __devinit twinhead_reserve_killing_zone(struct pci_dev *dev)
+{
+        if (dev->subsystem_vendor == 0x14FF && dev->subsystem_device == 0xA003) {
+                pr_info("Reserving memory on Twinhead H12Y\n");
+                request_mem_region(0xFFB00000, 0x100000, "twinhead");
+        }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x27B9, twinhead_reserve_killing_zone);

It seems to me that a DMI match might be more appropriate, since it pretty much sounds like the BIOS fails to reserve a region it is using?

-hpa

author
#5 lore raw
Quoted 4 lines

+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x27B9, twinhead_reserve_killing_zone);

It seems to me that a DMI match might be more appropriate, since it pretty much sounds like the BIOS fails to reserve a region it is using?

The PCI idents are unique to the system as well ?