> -----Original Message----- > From: Bjorn Helgaas [mailto:bjorn.helgaas@xxxxxx] > Sent: Wednesday, November 19, 2008 19:15 > To: GARCIA DE SORIA LUCENA, JUAN JESUS > Cc: linux-pci@xxxxxxxxxxxxxxx; jbarnes@xxxxxxxxxxxxxxxx; Jiri > Slaby; Gary Hade; JIMENEZ SHAW, FRANCISCO JAVIER > Subject: Re: PCI bus conflict hang: how to avoid the > allocation of an I/O range. > > If I understand correctly, the system works when the 00:10.0 > IO Base and Limit are left as 0xf0/0x00 (positive decoding > disabled because limit < base), as the BIOS programmed them. > But the system hangs if we write 0x10/0x10 to the Base/Limit > to set the positive decoding range to 0x1000-0x1fff. That's correct. > The Base/Limit are written with a single > pci_write_config_dword() in pci_setup_bridge(), so I don't > understand your comment about the hang happening "between the > writes to the I/O base/limit registers of the bridge." The hang happens exactly after 0x0101 gets written to the 16-bit I/O base/limit of the 00:10.0 PCI bridge in a 32-bit write. > I wonder why we use a dword write there: the Base/Limit > together are only 16 bits, so a word write should be > sufficient. And it looks like we're reading the Secondary > Status and writing it back, which would clear out any error > bits that happen to be set. Yes; I tried several masking configurations of that secondary status register, to no avail. > I don't think the "enabling write" of PCI_IO_BASE_UPPER16 > should be doing anything bad. In fact, I doubt it's doing > anything at all because the low nibble of PCI_IO_BASE is > zero, which means the bridge supports only 16-bit I/O > addressing, and the PCI_IO_BASE_UPPER16 Base/Limit registers > are probably read-only zeroes. If we really need to disable > the range while updating PCI_IO_BASE, I would think we'd want > to clear the PCI_COMMAND_IO bit in the command register. I confirm that the value written to PCI_IO_BASE_UPPER16 seems to be utterly ignored, since the hang happens before it's written for the second time to "enable" it. I don't think that actually disabling the bridge is needed. I think the code simply tries to avoid a "race" by making sure that no bridge that allows 32 bit address decoding gets a valid (enabled) range until the second write to PCI_IO_BASE_UPPER16 happens. > 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. Lots of thanks, Juan Jesus. -- 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
