Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [PATCH 2.6.15] ia64: use i386 dmi_scan.c | Date | Wed, 18 Jan 2006 03:32:19 +0100 |
| |
On Wednesday 18 January 2006 01:17, Bjorn Helgaas wrote: > On Friday 13 January 2006 17:24, Bjorn Helgaas wrote: > > ... the > > DMI stuff crashes HP sx2000 (and probably sx1000) boxes, probably > > because of some memory attribute problem. So I'll have more > > feedback after I debug that ;-) > > It *is* a memory attribute problem. The current code always calls > ioremap() on efi.smbios. The first problem is that this is a > physical address on x86, but a virtual address on ia64. > > The second problem is that we don't check the supported attributes > for the SMBIOS table. On HP sx1000/sx2000, these tables are in system > memory, which doesn't support uncacheable access, so iorem > ap() does the wrong thing.
At least on x86-64/i386 the ioremap is actually cached unless a MTRR changes it, but it normally doesn't here. If one wants to force uncached access one has to use ioremap_uncached(). You're saying IA64 ioremap forces uncached access? That seems weird.
> + if (efi_enabled) { > + if (efi_mem_attributes(base & EFI_MEMORY_WB)) { > + iomem = 0; > + buf = (u8 *) phys_to_virt(base); > + } else if (efi_mem_attributes(base & EFI_MEMORY_UC)) > + buf = dmi_ioremap(base, len); > + else > + buf = NULL;
I would expect your ioremap to already do such a lookup. That is at least how MTRRs on i386/x86-64 work. If it does not how about you fix ioremap()? Or provide a suitable ia64 dmi_ioremap, but it's likely better to do it generally.
Regarding physical vs virtual efi.smbios -- it sounds nasty to have such a difference in the EFI support for different architectures. Matthew, do you have a suggestion how this can be unified?
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |