On Wednesday 19 November 2008 03:32:08 am GARCIA DE SORIA LUCENA, JUAN JESUS wrote: > > -----Original Message----- > > From: Bjorn Helgaas [mailto:bjorn.helgaas@xxxxxx] > > Sent: Monday, November 17, 2008 20:29 > > 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. > > Theoretically, ACPI should tell us about any non-PCI devices > > that might be in the 0x1000-0x1fff range. This command: > > $ grep . /sys/bus/pnp/devices/*/* > > should tell you about them. > > I've looked at it under the Ubuntu kernel, and there's no declared > resource in /sys/bus/pnp/devices/*/resources in the problematic range. > I've included the combined "cat" of them below. I can provide the DSDT > and the dmesg output too. > > I've disassembled the DSDT and there's no reference to that range > either. > > What's the best way to proceed in order to implement the quirk-based > solution? I already patched the leds_clevo_mail module to recognize my > system via DMI data. Is this a possible approach? I don't have a clear idea of what's going wrong yet, so I'm not comfortable proposing any changes. On bus 00, you have a PCI-ISA bridge as well as a PCI-PCI bridge in subtractive decode mode: 00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode]) The PCI 3.0 spec, sec 2.4, says only one agent on a PCI bus can use subtractive decode. The spec isn't explicit, but pp. 53-54 of the Mindspring book imply that an ISA bridge *can* use subtractive decode. But I suppose the ISA bridge only actually use subtractive decode if it is attached to actual ISA slots. On modern boxes, there are no ISA slots, and the only ISA devices are embedded in the bridge, so the bridge knows their addresses and can positively decode them. 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. 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." 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. 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 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. 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
