login
Search
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 = ...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 -Andi -- ak@linux.intel.com --
On Tue, 02 Sep 2008 00:32:16 +0200 nope they don't/ 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 --
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 --
On Tue, 02 Sep 2008 01:01:19 +0200 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 --
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 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 ...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
--
Are you sure 0x29c0 is only used on the G31/G33? -Andi --
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 --
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 ...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 --
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
--
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 --
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 --
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
--
Applied. I'll include it in my next 2.6.27 pull request after fixing up my trees. Thanks, Jesse --
