>>> On 23.08.11 at 05:52, "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx> wrote:
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxxxx]
>> Sent: Monday, August 22, 2011 10:20 PM
>>
>> I think we discussed (off-list) quite extensively that this should not be
> keyed to
>> the PCI device IDs. It ought to hang off the BIOS and/or board manufacturer.
> I
>> actually have a patch that does just so, but am waiting for possibly more
> fine
>> grained identification information from you (Intel).
>>
>> Also, are you certain this problem exists only with this single ICH variant?
> So far, we only observed it on ICH10 based chipset. Did you see another
> platform have the problems?
No, I haven't observed it on other platforms but
- the problematic bits exist in earlier ICH versions too, and
- there are ICH10 based systems that aren't showing any such bad
behavior.
>> > + {}
>> > +};
>> > +
>> > +static void check_quirk(unsigned int bus, unsigned int dev, unsigned
>> > +int func) {
>> > + unsigned int vendor_id, device_id;
>> > + int i;
>> > +
>> > + vendor_id = pci_conf_read16(bus, dev, func, PCI_VENDOR_ID);
>> > + device_id = pci_conf_read16(bus, dev, func, PCI_DEVICE_ID);
>> > +
>> > + for (i = 0; early_quirk[i].f != NULL; i++)
>> > + if (early_quirk[i].vendor == vendor_id &&
>> > + early_quirk[i].device == device_id)
>> > + early_quirk[i].f(bus, dev, func); }
>> > +
>> > +void __init early_quirks(void)
>> > +{
>> > + unsigned int dev, func;
>> > +
>> > + for (dev = 0; dev < 32; dev++)
>> > + for (func = 0; func < 8; func++)
>> > + check_quirk(0, dev, func);
>>
>> Further I'm opposed to introducing further instances of legacy brute- force
> PCI
>> bus scans.
>>
>> And I don't think you got something along these lines accepted into Linux,
> did
>> you? It ought to be DMI based there, too.
> I don't know why you think using DMI is a better way? For BDF based way, we
> only need to know the device ID. But for DMI base way, I don't know which
> condition should be matched.
The keys I'm currently using (successfully tested on customer's and my
affected machines) are BIOS and board vendor being "Intel". Only on
those I'm then looking for the ICH10 (and then all known variants). See
below for the patch (still containing some debugging bits).
> Actually, the best way to solve it is to enable the ACPI mode in Xen instead
> of in dom0. For enable ACPI, we need to write the value from FADT.ACPI_ENABLE
> to SMI_CMD. After writing the value, the SMI ownership will be disable by
> ACPI hardware and it also will disable some logic which is able to cause SMI.
> For example, the legacy USB circuit will be masked too. Because at this
> point, there have no need to use legacy usb emulation. This is also what
> linux upstream did. But I think it is too complicated to port this logic to
> xen. Anyway, if you have interesting, you can add this logic to xen and there
> have no need for this patch again.
Was this a pretty recent change in Linux? Otherwise, how do you
explain that, with apparently lower probability, I'm observing the very
same hang with native Linux? My assumption is that ACPI mode
enabling is happening just too late for masking this problem.
Jan
--- a/xen/arch/x86/dmi_scan.c
+++ b/xen/arch/x86/dmi_scan.c
@@ -10,6 +10,8 @@
#include <asm/system.h>
#include <xen/dmi.h>
#include <xen/efi.h>
+#include <xen/pci.h>
+#include <xen/pci_regs.h>
#define bt_ioremap(b,l) ((void *)__acpi_map_table(b,l))
#define bt_iounmap(b,l) ((void)0)
@@ -278,6 +280,31 @@ static __init int broken_toshiba_keyboar
return 0;
}
+static int __init ich10_bios_quirk(struct dmi_system_id *d)
+{
+ u32 port, smictl;
+
+ if ( pci_conf_read16(0, 0x1f, 0, PCI_VENDOR_ID) != 0x8086 )
+ return 0;
+
+ switch ( pci_conf_read16(0, 0x1f, 0, PCI_DEVICE_ID) ) {
+ case 0x3a14:
+ case 0x3a16:
+ case 0x3a18:
+ case 0x3a1a:
+printk("ACPI base=%04x\n", port = pci_conf_read16(0, 0x1f, 0, 0x40));//temp
+ port = (port & 0xff80) + 0x30;
+ smictl = inl(port);
+printk("smictl=%08x\n", smictl);//temp
+ /* turn off LEGACY_USB{,2}_EN if enabled */
+ if ( smictl & 0x20008 )
+ outl(smictl & ~0x20008, port);
+printk("smictl:%08x\n", inl(port));//temp
+ break;
+ }
+
+ return 0;
+}
#ifdef CONFIG_ACPI_SLEEP
static __init int reset_videomode_after_s3(struct dmi_blacklist *d)
@@ -342,6 +369,18 @@ static __initdata struct dmi_blacklist d
} },
#endif
+ { ich10_bios_quirk, "Intel board & BIOS",
+ /*
+ * BIOS leaves legacy USB emulation enabled while
+ * SMM can't properly handle it.
+ */
+ {
+ MATCH(DMI_BOARD_VENDOR, "Intel Corp"),
+ MATCH(DMI_BIOS_VENDOR, "Intel Corp"),
+ NO_MATCH, NO_MATCH
+ }
+ },
+
#ifdef CONFIG_ACPI_BOOT
/*
* If your system is blacklisted here, but you find that acpi=force
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home