linux-kernel - Re: GA-MA69VM-S2 requires pci=nocrs with 2.6.35.4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201009131716.18197.bjorn.helgaas@hp.com>
Date:	Mon, 13 Sep 2010 17:16:15 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	"Simon Arlott" <simon@...e.lp0.eu>
Cc:	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	linux-pci@...r.kernel.org, Jordan Crouse <jordan.crouse@....com>
Subject: Re: GA-MA69VM-S2 requires pci=nocrs with 2.6.35.4

On Thursday, September 09, 2010 06:16:33 am Simon Arlott wrote:
> With a Gigabyte GA-MA69VM-S2 690V motherboard, it stalls in
> qurk_usb_early_handoff unless pci=nocrs is used:

Huh.  It looks like the HPET appears as a PCI device, in addition to
being described in the HPET table (and possibly in the ACPI namespace):

[    0.000000] ACPI: HPET id: 0x10b9a201 base: 0xfed00000
[    0.454232] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.461348] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.468004] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.474004] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.481004] pci_root PNP0A03:00: host bridge window [mem 0x000c0000-0x000dffff]
[    0.489004] pci_root PNP0A03:00: host bridge window [mem 0x80000000-0xfebfffff]
[    1.034049] pci 0000:00:14.0: no compatible bridge window for [mem 0xfed00000-0xfed003ff]
[    1.651998] pci 0000:00:14.0: BAR 1: assigned [mem 0x80000000-0x800003ff]

Since the 00:14.0 BAR looks invalid (it's outside all the host bridge
windows), we moved it to 0x80000000, and that probably broke the HPET
driver, which still thinks it's at 0xfed00000.

I've heard about this problem, but I haven't ever looked into it in
detail.  The best way to handle this would be to figure out why Windows
doesn't have this problem, since it also moves PCI devices in this
situation.

Simon, if you have a way to boot Windows, the output of Everest (free
trial at http://www.lavalys.com/) would be a great help.

I can see from the stalled.txt log that we did call sb600_disable_hpet_bar(),
and it *looks* like that should have disabled BAR 1.  But apparently it
didn't.  Would you mind collecting another log with the patch below?

Bjorn


diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 6dd8955..f793efd 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -510,6 +510,7 @@ static void sb600_disable_hpet_bar(struct pci_dev *dev)
 	 */
 
 	pci_read_config_byte(dev, 0x08, &val);
+	dev_info(&dev->dev, "read %#02x\n", val);
 
 	if (val < 0x2F) {
 		outb(0x55, 0xCD6);
@@ -517,7 +518,9 @@ static void sb600_disable_hpet_bar(struct pci_dev *dev)
 
 		/* Set bit 7 in PM register 0x55 */
 		outb(0x55, 0xCD6);
-		outb(val | 0x80, 0xCD7);
+		outb(val | 0x7f, 0xCD7);
+		dev_info(&dev->dev, "disabled BAR 1 (%pR)\n",
+			 &dev->resource[1]);
 	}
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_ATI, 0x4385, sb600_disable_hpet_bar);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/