On Wednesday 19 November 2008 11:26:24 am GARCIA DE SORIA LUCENA, JUAN JESUS wrote: > > I would expect that the hang would occur when we try to > > actually access something in the newly-enabled 0x1000-0x1fff > > region. Can you instrument the inb/outb path to log > > accesses? Maybe if we had an I/O port address and a program > > counter, that would be a clue. > > I'll try to do that this weekend. > > In any case I'm not sure it's the kernel the one performing the access. > I suspect there's "something" in the ACPI / embedded controller / some > other semi-autonomous code/device in the mother board performing those > accesses with a frequency high enough to cause an almost-instant hang. Oh, that's a good thought. I bet you're right. I'm not very familiar with that sort of code, but I know it exists. I cc'd Thomas because he did some work with resource interference (see acpi_enforce_resources in drivers/acpi/osl.c). I guess that's more for finding things that are used both by SMI code or ACPI AML and by a native Linux driver, and it doesn't seem like that's the sort of problem here. ACPI is supposed to tell us enough about embedded things like that so the OS can at least keep its mitts off. Maybe if you attached the DSDT to the bugzilla (http://bugzilla.kernel.org/show_bug.cgi?id=11054), somebody smarter than I could figure something out. It's quite possible that ACPI *is* telling us something, and we're ignoring it. BTW, I would assume Windows works fine on this box. You don't have any information about how it configures that bridge, do you? Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
