linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Misc fixes for 2.6.27
@ 2008-09-01 20:14 David Woodhouse
  2008-09-01 22:32 ` Andi Kleen
  0 siblings, 1 reply; 17+ messages in thread
From: David Woodhouse @ 2008-09-01 20:14 UTC (permalink / raw)
  To: torvalds; +Cc: linux-kernel

Linus, please pull from
	git://git.infradead.org/users/dwmw2/random-2.6.git

It contains the following fixes for 2.6.27:

Adrian Bunk (1):
      dabusb_fpga_download(): fix a memory leak

David Woodhouse (3):
      intel-iommu.c: Blacklist Intel DG33BU motherboard.
      Fix modules_install on RO nfs-exported trees.
      Remove '#include <stddef.h>' from mm/page_isolation.c

Zev Weiss (1):
      [MTD] mtdchar.c: Fix regression in MEMGETREGIONINFO ioctl()

 drivers/media/video/dabusb.c |    1 +
 drivers/mtd/mtdchar.c        |   16 ++++++++++------
 drivers/pci/intel-iommu.c    |   23 +++++++++++++++++++++++
 firmware/Makefile            |   16 ++++++++++++++--
 mm/page_isolation.c          |    1 -
 5 files changed, 48 insertions(+), 9 deletions(-)

Full patch follows...

diff --git a/drivers/media/video/dabusb.c b/drivers/media/video/dabusb.c
index 48f4b92..79faedf 100644
--- a/drivers/media/video/dabusb.c
+++ b/drivers/media/video/dabusb.c
@@ -403,6 +403,7 @@ static int dabusb_fpga_download (pdabusb_t s, const char *fname)
 	ret = request_firmware(&fw, "dabusb/bitstream.bin", &s->usbdev->dev);
 	if (ret) {
 		err("Failed to load \"dabusb/bitstream.bin\": %d\n", ret);
+		kfree(b);
 		return ret;
 	}
 
diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
index d2f3318..e00d424 100644
--- a/drivers/mtd/mtdchar.c
+++ b/drivers/mtd/mtdchar.c
@@ -410,16 +410,20 @@ static int mtd_ioctl(struct inode *inode, struct file *file,
 
 	case MEMGETREGIONINFO:
 	{
-		struct region_info_user ur;
+		uint32_t ur_idx;
+		struct mtd_erase_region_info *kr;
+		struct region_info_user *ur = (struct region_info_user *) argp;
 
-		if (copy_from_user(&ur, argp, sizeof(struct region_info_user)))
+		if (get_user(ur_idx, &(ur->regionindex)))
 			return -EFAULT;
 
-		if (ur.regionindex >= mtd->numeraseregions)
-			return -EINVAL;
-		if (copy_to_user(argp, &(mtd->eraseregions[ur.regionindex]),
-				sizeof(struct mtd_erase_region_info)))
+		kr = &(mtd->eraseregions[ur_idx]);
+
+		if (put_user(kr->offset, &(ur->offset))
+		    || put_user(kr->erasesize, &(ur->erasesize))
+		    || put_user(kr->numblocks, &(ur->numblocks)))
 			return -EFAULT;
+
 		break;
 	}
 
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 8d0e60a..c3edcdc 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -2348,11 +2348,34 @@ static void __init iommu_exit_mempool(void)
 
 }
 
+static int blacklist_iommu(const struct dmi_system_id *id)
+{
+	printk(KERN_INFO "%s detected; disabling IOMMU\n",
+	       id->ident);
+	dmar_disabled = 1;
+	return 0;
+}
+
+static struct dmi_system_id __initdata intel_iommu_dmi_table[] = {
+	{	/* Some DG33BU BIOS revisions advertised non-existent VT-d */
+		.callback = blacklist_iommu,
+		.ident = "Intel DG33BU",
+		{	DMI_MATCH(DMI_BOARD_VENDOR, "Intel Corporation"),
+			DMI_MATCH(DMI_BOARD_NAME, "DG33BU"),
+		}
+	},
+	{ }
+};
+
+
 void __init detect_intel_iommu(void)
 {
 	if (swiotlb || no_iommu || iommu_detected || dmar_disabled)
 		return;
 	if (early_dmar_detect()) {
+		dmi_check_system(intel_iommu_dmi_table);
+		if (dmar_disabled)
+			return;
 		iommu_detected = 1;
 	}
 }
diff --git a/firmware/Makefile b/firmware/Makefile
index 9fe8604..da75a6f 100644
--- a/firmware/Makefile
+++ b/firmware/Makefile
@@ -146,15 +146,27 @@ $(patsubst %,$(obj)/%.gen.o, $(fw-external-y)): $(obj)/%.gen.o: $(fwdir)/%
 $(obj)/%: $(obj)/%.ihex | $(objtree)/$(obj)/$$(dir %)
 	$(call cmd,ihex)
 
+# Don't depend on ihex2fw if we're installing and it already exists.
+# Putting it after | in the dependencies doesn't seem sufficient when
+# we're installing after a cross-compile, because ihex2fw has dependencies
+# on stuff like /usr/lib/gcc/ppc64-redhat-linux/4.3.0/include/stddef.h and 
+# thus wants to be rebuilt. Which it can't be, if the prebuilt kernel tree
+# is exported read-only for someone to run 'make install'.
+ifeq ($(INSTALL):$(wildcard $(obj)/ihex2fw),install:$(obj)/ihex2fw)
+ihex2fw_dep :=
+else
+ihex2fw_dep := $(obj)/ihex2fw
+endif
+
 # .HEX is also Intel HEX, but where the offset and length in each record
 # is actually meaningful, because the firmware has to be loaded in a certain
 # order rather than as a single binary blob. Thus, we convert them into our
 # more compact binary representation of ihex records (<linux/ihex.h>)
-$(obj)/%.fw: $(obj)/%.HEX $(obj)/ihex2fw | $(objtree)/$(obj)/$$(dir %)
+$(obj)/%.fw: $(obj)/%.HEX $(ihex2fw_dep) | $(objtree)/$(obj)/$$(dir %)
 	$(call cmd,ihex2fw)
 
 # .H16 is our own modified form of Intel HEX, with 16-bit length for records.
-$(obj)/%.fw: $(obj)/%.H16 $(obj)/ihex2fw | $(objtree)/$(obj)/$$(dir %)
+$(obj)/%.fw: $(obj)/%.H16 $(ihex2fw_dep) | $(objtree)/$(obj)/$$(dir %)
 	$(call cmd,h16tofw)
 
 $(firmware-dirs):
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index 3444b58..c69f84f 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -2,7 +2,6 @@
  * linux/mm/page_isolation.c
  */
 
-#include <stddef.h>
 #include <linux/mm.h>
 #include <linux/page-isolation.h>
 #include <linux/pageblock-flags.h>


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: Misc fixes for 2.6.27
  2008-09-01 20:14 Misc fixes for 2.6.27 David Woodhouse
@ 2008-09-01 22:32 ` Andi Kleen
  2008-09-01 22:35   ` Arjan van de Ven
  0 siblings, 1 reply; 17+ messages in thread
From: Andi Kleen @ 2008-09-01 22:32 UTC (permalink / raw)
  To: David Woodhouse; +Cc: torvalds, linux-kernel

David Woodhouse <dwmw2@infradead.org> writes:
> +
> +static struct dmi_system_id __initdata intel_iommu_dmi_table[] = {
> +	{	/* Some DG33BU BIOS revisions advertised non-existent VT-d */

Are you sure it's non existent? A G33 chipset should have it in
hardware I thought.

I'm not sure this is really the right way to handle this anyways.
If there's ever a working BIOS it will be blacklisted too. And
normally BIOS bugs don't come in one board alone, but in a range
of them and then adding more and more identifiers is quite painful.

Better would be to add some generic sanity checks that catches
the issues these BIOS revisions are having.

> +		.callback = blacklist_iommu,
> +		.ident = "Intel DG33BU",
> +		{	DMI_MATCH(DMI_BOARD_VENDOR, "Intel Corporation"),
> +			DMI_MATCH(DMI_BOARD_NAME, "DG33BU"),
> +		}
> +	},

-Andi

-- 
ak@linux.intel.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Misc fixes for 2.6.27
  2008-09-01 22:32 ` Andi Kleen
@ 2008-09-01 22:35   ` Arjan van de Ven
  2008-09-01 23:01     ` Andi Kleen
  0 siblings, 1 reply; 17+ messages in thread
From: Arjan van de Ven @ 2008-09-01 22:35 UTC (permalink / raw)
  To: Andi Kleen; +Cc: David Woodhouse, torvalds, linux-kernel

On Tue, 02 Sep 2008 00:32:16 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> David Woodhouse <dwmw2@infradead.org> writes:
> > +
> > +static struct dmi_system_id __initdata intel_iommu_dmi_table[] = {
> > +	{	/* Some DG33BU BIOS revisions advertised
> > non-existent VT-d */
> 
> Are you sure it's non existent? A G33 chipset should have it in
> hardware I thought.

nope they don't/
later ones and some other models do though, but not the G33
> 
> I'm not sure this is really the right way to handle this anyways.
> If there's ever a working BIOS it will be blacklisted too. And
> normally BIOS bugs don't come in one board alone, but in a range
> of them and then adding more and more identifiers is quite painful.

the bios bug here is that it accidentally DID advertise the capability,
even though it's not there.



-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Misc fixes for 2.6.27
  2008-09-01 22:35   ` Arjan van de Ven
@ 2008-09-01 23:01     ` Andi Kleen
  2008-09-01 23:16       ` Arjan van de Ven
  0 siblings, 1 reply; 17+ messages in thread
From: Andi Kleen @ 2008-09-01 23:01 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: David Woodhouse, torvalds, linux-kernel

Arjan van de Ven <arjan@infradead.org> writes:

> On Tue, 02 Sep 2008 00:32:16 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
>
>> David Woodhouse <dwmw2@infradead.org> writes:
>> > +
>> > +static struct dmi_system_id __initdata intel_iommu_dmi_table[] = {
>> > +	{	/* Some DG33BU BIOS revisions advertised
>> > non-existent VT-d */
>> 
>> Are you sure it's non existent? A G33 chipset should have it in
>> hardware I thought.
>
> nope they don't/
> later ones and some other models do though, but not the G33

I see. But presumably that chipset will be in other motherboards
too and that BIOS bug might be also wider spread. So it would be still 
better to key off an PCI-ID or similar.

-Andi

-- 
ak@linux.intel.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Misc fixes for 2.6.27
  2008-09-01 23:01     ` Andi Kleen
@ 2008-09-01 23:16       ` Arjan van de Ven
  2008-09-02  6:19         ` Andi Kleen
  0 siblings, 1 reply; 17+ messages in thread
From: Arjan van de Ven @ 2008-09-01 23:16 UTC (permalink / raw)
  To: Andi Kleen; +Cc: David Woodhouse, torvalds, linux-kernel

On Tue, 02 Sep 2008 01:01:19 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> Arjan van de Ven <arjan@infradead.org> writes:
> 
> > On Tue, 02 Sep 2008 00:32:16 +0200
> > Andi Kleen <andi@firstfloor.org> wrote:
> >
> >> David Woodhouse <dwmw2@infradead.org> writes:
> >> > +
> >> > +static struct dmi_system_id __initdata intel_iommu_dmi_table[]
> >> > = {
> >> > +	{	/* Some DG33BU BIOS revisions advertised
> >> > non-existent VT-d */
> >> 
> >> Are you sure it's non existent? A G33 chipset should have it in
> >> hardware I thought.
> >
> > nope they don't/
> > later ones and some other models do though, but not the G33
> 
> I see. But presumably that chipset will be in other motherboards
> too and that BIOS bug might be also wider spread. So it would be
> still better to key off an PCI-ID or similar.
> 

it would be nice, no doubt, unfortunately this code runs (and needs to
run) before the PCI subsystem is initialized...

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Misc fixes for 2.6.27
  2008-09-01 23:16       ` Arjan van de Ven
@ 2008-09-02  6:19         ` Andi Kleen
  2008-09-02  8:23           ` David Woodhouse
  2008-09-03 10:53           ` Blacklist DMAR on Intel G31/G33 chipsets David Woodhouse
  0 siblings, 2 replies; 17+ messages in thread
From: Andi Kleen @ 2008-09-02  6:19 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Andi Kleen, David Woodhouse, torvalds, linux-kernel

On Mon, Sep 01, 2008 at 04:16:39PM -0700, Arjan van de Ven wrote:
> On Tue, 02 Sep 2008 01:01:19 +0200
> Andi Kleen <andi@firstfloor.org> wrote:
> 
> > Arjan van de Ven <arjan@infradead.org> writes:
> > 
> > > On Tue, 02 Sep 2008 00:32:16 +0200
> > > Andi Kleen <andi@firstfloor.org> wrote:
> > >
> > >> David Woodhouse <dwmw2@infradead.org> writes:
> > >> > +
> > >> > +static struct dmi_system_id __initdata intel_iommu_dmi_table[]
> > >> > = {
> > >> > +	{	/* Some DG33BU BIOS revisions advertised
> > >> > non-existent VT-d */
> > >> 
> > >> Are you sure it's non existent? A G33 chipset should have it in
> > >> hardware I thought.
> > >
> > > nope they don't/
> > > later ones and some other models do though, but not the G33
> > 
> > I see. But presumably that chipset will be in other motherboards
> > too and that BIOS bug might be also wider spread. So it would be
> > still better to key off an PCI-ID or similar.
> > 
> 
> it would be nice, no doubt, unfortunately this code runs (and needs to
> run) before the PCI subsystem is initialized...

early quirks handles these cases. Check out early-quirks.c

-Andi

-- 
ak@linux.intel.com

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Misc fixes for 2.6.27
  2008-09-02  6:19         ` Andi Kleen
@ 2008-09-02  8:23           ` David Woodhouse
  2008-09-03 10:53           ` Blacklist DMAR on Intel G31/G33 chipsets David Woodhouse
  1 sibling, 0 replies; 17+ messages in thread
From: David Woodhouse @ 2008-09-02  8:23 UTC (permalink / raw)
  To: Andi Kleen; +Cc: Arjan van de Ven, torvalds, linux-kernel

On Tue, 2008-09-02 at 08:19 +0200, Andi Kleen wrote:
> On Mon, Sep 01, 2008 at 04:16:39PM -0700, Arjan van de Ven wrote:
> > On Tue, 02 Sep 2008 01:01:19 +0200
> > Andi Kleen <andi@firstfloor.org> wrote:
> > 
> > > Arjan van de Ven <arjan@infradead.org> writes:
> > > 
> > > > On Tue, 02 Sep 2008 00:32:16 +0200
> > > > Andi Kleen <andi@firstfloor.org> wrote:
> > > >
> > > >> David Woodhouse <dwmw2@infradead.org> writes:
> > > >> > +
> > > >> > +static struct dmi_system_id __initdata intel_iommu_dmi_table[]
> > > >> > = {
> > > >> > +	{	/* Some DG33BU BIOS revisions advertised
> > > >> > non-existent VT-d */
> > > >> 
> > > >> Are you sure it's non existent? A G33 chipset should have it in
> > > >> hardware I thought.
> > > >
> > > > nope they don't/
> > > > later ones and some other models do though, but not the G33
> > > 
> > > I see. But presumably that chipset will be in other motherboards
> > > too and that BIOS bug might be also wider spread. So it would be
> > > still better to key off an PCI-ID or similar.

It's certainly possible that the same BIOS bug could show up elsewhere.
I was expecting that we could add new motherboards to the DMI table if
that happens.

> > it would be nice, no doubt, unfortunately this code runs (and needs to
> > run) before the PCI subsystem is initialized...
> 
> early quirks handles these cases. Check out early-quirks.c

That might work, I suppose -- although the iommu probe happens early, it
looks like the early-quirks are handled even earlier. Unfortunately the
last attempt at flashing a BIOS on my DG33BU has turned it into a brick
and even the recovery procedure doesn't work, so I can't test any more
-- I'm more inclined to stick with what I'd tested, but if you feel
strongly and someone can test this version, then perhaps we could go
with that instead...

I made it check for this:
00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev 02)

Are we sure that device never going to appear on a board which really
_does_ have an IOMMU? And we should probably get it into pci_ids.h too.


diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 4353cf5..f51f61b 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -95,6 +95,20 @@ static void __init nvidia_bugs(int num, int slot, int func)
 
 }
 
+#ifdef CONFIG_DMAR
+static void __init intel_g33_dmar(int num, int slot, int func)
+{
+	struct acpi_table_header *dmar_tbl;
+	acpi_status = status;
+
+	status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
+	if (ACPI_SUCCESS(status)) {
+		printk(KERN_INFO "BIOS BUG: DMAR advertised on Intel G31/G33 chipset -- ignoring\n");
+		dmar_disabled = 1;
+	}
+}
+#endif
+
 #define QFLAG_APPLY_ONCE 	0x1
 #define QFLAG_APPLIED		0x2
 #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -114,6 +128,10 @@ static struct chipset early_qrk[] __initdata = {
 	  PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
 	{ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB,
 	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config },
+#ifdef CONFIG_DMAR
+	{ PCI_VENDOR_ID_INTEL, 0x29c0,
+	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, intel_g33_dmar },
+#endif
 	{}
 };
 


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-02  6:19         ` Andi Kleen
  2008-09-02  8:23           ` David Woodhouse
@ 2008-09-03 10:53           ` David Woodhouse
  2008-09-03 12:09             ` Andi Kleen
  2008-09-04  8:54             ` [PATCH] " David Woodhouse
  1 sibling, 2 replies; 17+ messages in thread
From: David Woodhouse @ 2008-09-03 10:53 UTC (permalink / raw)
  To: linux-kernel; +Cc: andi, arjan

Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
when they don't. Avoid the resulting crashes when it doesn't work as
expected.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
Using early-quirks this time, at Andi's suggestion. I haven't been able 
to test this version though, since I killed my board when trying to reflash 
the BIOS too many times. Arjan, did you say we have a pile of these?

 arch/x86/kernel/early-quirks.c |   18 ++++++++++++++++++
 1 files changed, 18 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 4353cf5..f51f61b 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -95,6 +95,20 @@ static void __init nvidia_bugs(int num, int slot, int func)
 
 }
 
+#ifdef CONFIG_DMAR
+static void __init intel_g33_dmar(int num, int slot, int func)
+{
+	struct acpi_table_header *dmar_tbl;
+	acpi_status = status;
+
+	status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
+	if (ACPI_SUCCESS(status)) {
+		printk(KERN_INFO "BIOS BUG: DMAR advertised on Intel G31/G33 chipset -- ignoring\n");
+		dmar_disabled = 1;
+	}
+}
+#endif
+
 #define QFLAG_APPLY_ONCE 	0x1
 #define QFLAG_APPLIED		0x2
 #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -114,6 +128,10 @@ static struct chipset early_qrk[] __initdata = {
 	  PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
 	{ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB,
 	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config },
+#ifdef CONFIG_DMAR
+	{ PCI_VENDOR_ID_INTEL, 0x29c0,
+	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, intel_g33_dmar },
+#endif
 	{}
 };
 
-- 
1.5.5.1
-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-03 10:53           ` Blacklist DMAR on Intel G31/G33 chipsets David Woodhouse
@ 2008-09-03 12:09             ` Andi Kleen
  2008-09-03 12:22               ` David Woodhouse
  2008-09-04  8:54             ` [PATCH] " David Woodhouse
  1 sibling, 1 reply; 17+ messages in thread
From: Andi Kleen @ 2008-09-03 12:09 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-kernel, andi, arjan

> @@ -114,6 +128,10 @@ static struct chipset early_qrk[] __initdata = {
>  	  PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
>  	{ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB,
>  	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config },
> +#ifdef CONFIG_DMAR
> +	{ PCI_VENDOR_ID_INTEL, 0x29c0,
> +	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, intel_g33_dmar },
> +#endif

Are you sure 0x29c0 is only used on the G31/G33?

-Andi


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-03 12:09             ` Andi Kleen
@ 2008-09-03 12:22               ` David Woodhouse
  0 siblings, 0 replies; 17+ messages in thread
From: David Woodhouse @ 2008-09-03 12:22 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, arjan, Sankaran, Rajesh, Bork, Jon

On Wed, 2008-09-03 at 14:09 +0200, Andi Kleen wrote:
> > @@ -114,6 +128,10 @@ static struct chipset early_qrk[] __initdata = {
> >  	  PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
> >  	{ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB,
> >  	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config },
> > +#ifdef CONFIG_DMAR
> > +	{ PCI_VENDOR_ID_INTEL, 0x29c0,
> > +	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, intel_g33_dmar },
> > +#endif
> 
> Are you sure 0x29c0 is only used on the G31/G33?

And P35 and P31, but nothing with an IOMMU, I believe. The G35 is
8086:2980.

But still I'd be slightly happier using a DMI match on the only
_motherboard_ we've seen so far with this BIOS bug. We can easily add
new motherboards if it does show up elsewhere.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




^ permalink raw reply	[flat|nested] 17+ messages in thread

* [PATCH] Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-03 10:53           ` Blacklist DMAR on Intel G31/G33 chipsets David Woodhouse
  2008-09-03 12:09             ` Andi Kleen
@ 2008-09-04  8:54             ` David Woodhouse
  2008-09-05 18:34               ` Ingo Molnar
  1 sibling, 1 reply; 17+ messages in thread
From: David Woodhouse @ 2008-09-04  8:54 UTC (permalink / raw)
  To: linux-kernel; +Cc: andi, arjan, sfr

Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
when they don't. Avoid the resulting crashes when it doesn't work as
expected.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---

This time, I build-tested it with CONFIG_DMAR actually enabled. Sorry.
I'd still be grateful if someone could test it on a DG33BU with the old
BIOS though, since I've killed mine. I tested the DMI version, but not
this one.

 arch/x86/kernel/early-quirks.c |   18 ++++++++++++++++++
 drivers/pci/intel-iommu.c      |    2 +-
 include/asm-x86/iommu.h        |    1 +
 3 files changed, 20 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/early-quirks.c b/arch/x86/kernel/early-quirks.c
index 4353cf5..24bb5fa 100644
--- a/arch/x86/kernel/early-quirks.c
+++ b/arch/x86/kernel/early-quirks.c
@@ -95,6 +95,20 @@ static void __init nvidia_bugs(int num, int slot, int func)
 
 }
 
+#ifdef CONFIG_DMAR
+static void __init intel_g33_dmar(int num, int slot, int func)
+{
+	struct acpi_table_header *dmar_tbl;
+	acpi_status status;
+
+	status = acpi_get_table(ACPI_SIG_DMAR, 0, &dmar_tbl);
+	if (ACPI_SUCCESS(status)) {
+		printk(KERN_INFO "BIOS BUG: DMAR advertised on Intel G31/G33 chipset -- ignoring\n");
+		dmar_disabled = 1;
+	}
+}
+#endif
+
 #define QFLAG_APPLY_ONCE 	0x1
 #define QFLAG_APPLIED		0x2
 #define QFLAG_DONE		(QFLAG_APPLY_ONCE|QFLAG_APPLIED)
@@ -114,6 +128,10 @@ static struct chipset early_qrk[] __initdata = {
 	  PCI_CLASS_BRIDGE_PCI, PCI_ANY_ID, QFLAG_APPLY_ONCE, via_bugs },
 	{ PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB,
 	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, fix_hypertransport_config },
+#ifdef CONFIG_DMAR
+	{ PCI_VENDOR_ID_INTEL, 0x29c0,
+	  PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, intel_g33_dmar },
+#endif
 	{}
 };
 
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 8d0e60a..eaba6ec 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -80,7 +80,7 @@ static long list_size;
 
 static void domain_remove_dev_info(struct dmar_domain *domain);
 
-static int dmar_disabled;
+int dmar_disabled;
 static int __initdata dmar_map_gfx = 1;
 static int dmar_forcedac;
 static int intel_iommu_strict;
diff --git a/include/asm-x86/iommu.h b/include/asm-x86/iommu.h
index 5f888cc..621a1af 100644
--- a/include/asm-x86/iommu.h
+++ b/include/asm-x86/iommu.h
@@ -6,6 +6,7 @@ extern void no_iommu_init(void);
 extern struct dma_mapping_ops nommu_dma_ops;
 extern int force_iommu, no_iommu;
 extern int iommu_detected;
+extern int dmar_disabled;
 
 extern unsigned long iommu_num_pages(unsigned long addr, unsigned long len);
 
-- 
1.5.5.1
-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH] Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-04  8:54             ` [PATCH] " David Woodhouse
@ 2008-09-05 18:34               ` Ingo Molnar
  2008-09-05 18:47                 ` David Woodhouse
  2008-09-07 15:35                 ` [2.6.27 PATCH] " David Woodhouse
  0 siblings, 2 replies; 17+ messages in thread
From: Ingo Molnar @ 2008-09-05 18:34 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-kernel, andi, arjan, torvalds, sfr, Jesse Barnes


* David Woodhouse <dwmw2@infradead.org> wrote:

> Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
> when they don't. Avoid the resulting crashes when it doesn't work as
> expected.
> 
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> ---
> 
> This time, I build-tested it with CONFIG_DMAR actually enabled. Sorry. 
> I'd still be grateful if someone could test it on a DG33BU with the 
> old BIOS though, since I've killed mine. I tested the DMI version, but 
> not this one.

ok - fixing this makes sense. I have two worries about this patch.

Firstly, the quirk is keyed off an ACPI capability which is quite bad if 
someone boots with ACPI off. (which is still quite possible) The DMAR is 
PCI enumerated so there's nothing inherently ACPI about this. A DMI 
quirk (which will work even if ACPI is disabled) looks more robust.

Secondly, keying off the PCI ID and assuming a BIOS bug based on the 
presence of an ACPI table can indeed get incoherent results as you 
suspect. It's better to single out the specific BIOS as long as the DMI 
info is specific enough. Even if that PCI ID is never supposed to be 
combined with VT-d (because, obviously, VT-d needs a different chipset), 
it's just a sloppy concept in general.

The fact that you've already tested the DMI version and cannot test the 
new version is one more reason to favor the first patch.

Could you please resend the initial DMI version of the 
drivers/pci/intel-iommu.c commit stand-alone, not embedded in a 'misc' 
pull request, and with Jesse Cc:-ed as well? Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-05 18:34               ` Ingo Molnar
@ 2008-09-05 18:47                 ` David Woodhouse
  2008-09-06 15:49                   ` Ingo Molnar
  2008-09-07 15:35                 ` [2.6.27 PATCH] " David Woodhouse
  1 sibling, 1 reply; 17+ messages in thread
From: David Woodhouse @ 2008-09-05 18:47 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, andi, arjan, torvalds, sfr, Jesse Barnes

On Fri, 2008-09-05 at 20:34 +0200, Ingo Molnar wrote:
> * David Woodhouse <dwmw2@infradead.org> wrote:
> 
> > Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
> > when they don't. Avoid the resulting crashes when it doesn't work as
> > expected.
> > 
> > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> > ---
> > 
> > This time, I build-tested it with CONFIG_DMAR actually enabled. Sorry. 
> > I'd still be grateful if someone could test it on a DG33BU with the 
> > old BIOS though, since I've killed mine. I tested the DMI version, but 
> > not this one.
> 
> ok - fixing this makes sense. I have two worries about this patch.
> 
> Firstly, the quirk is keyed off an ACPI capability which is quite bad if 
> someone boots with ACPI off. (which is still quite possible) The DMAR is 
> PCI enumerated so there's nothing inherently ACPI about this. A DMI 
> quirk (which will work even if ACPI is disabled) looks more robust.

No, the intel-iommu code is isn't PCI-enumerated -- it all depends on
that ACPI table, unfortunately. That's why we're have this problem in
the first place and why I'm left with a dead board; apparently they
still drag crack-smoking hobos in off the street to write BIOSes, and
we're trusting more and more of our system to this crap every day.

I'm perfectly happy to go back to my original DMI-based version though.
Here it is...

Subject: Blacklist DMAR on Intel G31/G33 chipsets
    
Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
when they don't. Avoid the resulting crashes when it doesn't work as
expected.
    
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>


diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 8d0e60a..c3edcdc 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -2348,11 +2348,34 @@ static void __init iommu_exit_mempool(void)
 
 }
 
+static int blacklist_iommu(const struct dmi_system_id *id)
+{
+	printk(KERN_INFO "%s detected; disabling IOMMU\n",
+	       id->ident);
+	dmar_disabled = 1;
+	return 0;
+}
+
+static struct dmi_system_id __initdata intel_iommu_dmi_table[] = {
+	{	/* Some DG33BU BIOS revisions advertised non-existent VT-d */
+		.callback = blacklist_iommu,
+		.ident = "Intel DG33BU",
+		{	DMI_MATCH(DMI_BOARD_VENDOR, "Intel Corporation"),
+			DMI_MATCH(DMI_BOARD_NAME, "DG33BU"),
+		}
+	},
+	{ }
+};
+
+
 void __init detect_intel_iommu(void)
 {
 	if (swiotlb || no_iommu || iommu_detected || dmar_disabled)
 		return;
 	if (early_dmar_detect()) {
+		dmi_check_system(intel_iommu_dmi_table);
+		if (dmar_disabled)
+			return;
 		iommu_detected = 1;
 	}
 }


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH] Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-05 18:47                 ` David Woodhouse
@ 2008-09-06 15:49                   ` Ingo Molnar
  2008-09-07  8:20                     ` David Woodhouse
  0 siblings, 1 reply; 17+ messages in thread
From: Ingo Molnar @ 2008-09-06 15:49 UTC (permalink / raw)
  To: David Woodhouse; +Cc: linux-kernel, andi, arjan, torvalds, sfr, Jesse Barnes


* David Woodhouse <dwmw2@infradead.org> wrote:

> On Fri, 2008-09-05 at 20:34 +0200, Ingo Molnar wrote:
> > * David Woodhouse <dwmw2@infradead.org> wrote:
> > 
> > > Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
> > > when they don't. Avoid the resulting crashes when it doesn't work as
> > > expected.
> > > 
> > > Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> > > ---
> > > 
> > > This time, I build-tested it with CONFIG_DMAR actually enabled. Sorry. 
> > > I'd still be grateful if someone could test it on a DG33BU with the 
> > > old BIOS though, since I've killed mine. I tested the DMI version, but 
> > > not this one.
> > 
> > ok - fixing this makes sense. I have two worries about this patch.
> > 
> > Firstly, the quirk is keyed off an ACPI capability which is quite bad if 
> > someone boots with ACPI off. (which is still quite possible) The DMAR is 
> > PCI enumerated so there's nothing inherently ACPI about this. A DMI 
> > quirk (which will work even if ACPI is disabled) looks more robust.
> 
> No, the intel-iommu code is isn't PCI-enumerated -- it all depends on 
> that ACPI table, unfortunately. [...]

ah, you are right ... and i thought i could trust grep -i acpi 
drivers/pci/intel-iommu.c coming up empty ;-)

Jesse's call obviously, but the DMI thing local to intel-iommu.c still 
looks better to me in all regards. I'm no fan of DMI in general - it 
just doesnt scale - but here a crappy BIOS gets punished with a DMI 
quirk and that's OK.

	Ingo

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH] Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-06 15:49                   ` Ingo Molnar
@ 2008-09-07  8:20                     ` David Woodhouse
  0 siblings, 0 replies; 17+ messages in thread
From: David Woodhouse @ 2008-09-07  8:20 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: linux-kernel, andi, arjan, torvalds, sfr, Jesse Barnes

On Sat, 2008-09-06 at 17:49 +0200, Ingo Molnar wrote:
> Jesse's call obviously, but the DMI thing local to intel-iommu.c still 
> looks better to me in all regards. I'm no fan of DMI in general - it 
> just doesnt scale - but here a crappy BIOS gets punished with a DMI 
> quirk and that's OK.

The DMI was my first choice too -- I was only trying to do it with PCI
to keep Andi happy.

There is a non-zero possibility that the same BIOS bug gets copied to
other boards, I suppose -- but it's not exactly hard to add another
board to the table if we find that to be the case.

Shall I resubmit the original version to Linus again for 2.6.27, then?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




^ permalink raw reply	[flat|nested] 17+ messages in thread

* [2.6.27 PATCH] Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-05 18:34               ` Ingo Molnar
  2008-09-05 18:47                 ` David Woodhouse
@ 2008-09-07 15:35                 ` David Woodhouse
  2008-09-09 18:39                   ` Jesse Barnes
  1 sibling, 1 reply; 17+ messages in thread
From: David Woodhouse @ 2008-09-07 15:35 UTC (permalink / raw)
  To: torvalds
  Cc: linux-kernel, andi, arjan, torvalds, sfr, Jesse Barnes, Ingo Molnar

Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
when they don't. Avoid the resulting crashes when it doesn't work as
expected.

Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: Ingo Molnar <mingo@elte.hu>

diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 8d0e60a..c3edcdc 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -2348,11 +2348,34 @@ static void __init iommu_exit_mempool(void)
 
 }
 
+static int blacklist_iommu(const struct dmi_system_id *id)
+{
+	printk(KERN_INFO "%s detected; disabling IOMMU\n",
+	       id->ident);
+	dmar_disabled = 1;
+	return 0;
+}
+
+static struct dmi_system_id __initdata intel_iommu_dmi_table[] = {
+	{	/* Some DG33BU BIOS revisions advertised non-existent VT-d */
+		.callback = blacklist_iommu,
+		.ident = "Intel DG33BU",
+		{	DMI_MATCH(DMI_BOARD_VENDOR, "Intel Corporation"),
+			DMI_MATCH(DMI_BOARD_NAME, "DG33BU"),
+		}
+	},
+	{ }
+};
+
+
 void __init detect_intel_iommu(void)
 {
 	if (swiotlb || no_iommu || iommu_detected || dmar_disabled)
 		return;
 	if (early_dmar_detect()) {
+		dmi_check_system(intel_iommu_dmi_table);
+		if (dmar_disabled)
+			return;
 		iommu_detected = 1;
 	}
 }


-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation




^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [2.6.27 PATCH] Blacklist DMAR on Intel G31/G33 chipsets
  2008-09-07 15:35                 ` [2.6.27 PATCH] " David Woodhouse
@ 2008-09-09 18:39                   ` Jesse Barnes
  0 siblings, 0 replies; 17+ messages in thread
From: Jesse Barnes @ 2008-09-09 18:39 UTC (permalink / raw)
  To: David Woodhouse; +Cc: torvalds, linux-kernel, andi, arjan, sfr, Ingo Molnar

On Sunday, September 07, 2008 8:35 am David Woodhouse wrote:
> Some BIOSes (the Intel DG33BU, for example) wrongly claim to have DMAR
> when they don't. Avoid the resulting crashes when it doesn't work as
> expected.

Applied.  I'll include it in my next 2.6.27 pull request after fixing up my 
trees.

Thanks,
Jesse

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2008-09-09 18:39 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-01 20:14 Misc fixes for 2.6.27 David Woodhouse
2008-09-01 22:32 ` Andi Kleen
2008-09-01 22:35   ` Arjan van de Ven
2008-09-01 23:01     ` Andi Kleen
2008-09-01 23:16       ` Arjan van de Ven
2008-09-02  6:19         ` Andi Kleen
2008-09-02  8:23           ` David Woodhouse
2008-09-03 10:53           ` Blacklist DMAR on Intel G31/G33 chipsets David Woodhouse
2008-09-03 12:09             ` Andi Kleen
2008-09-03 12:22               ` David Woodhouse
2008-09-04  8:54             ` [PATCH] " David Woodhouse
2008-09-05 18:34               ` Ingo Molnar
2008-09-05 18:47                 ` David Woodhouse
2008-09-06 15:49                   ` Ingo Molnar
2008-09-07  8:20                     ` David Woodhouse
2008-09-07 15:35                 ` [2.6.27 PATCH] " David Woodhouse
2008-09-09 18:39                   ` Jesse Barnes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).