On Tue, Feb 07, 2012 at 09:27:43AM -0800, Sarah Sharp wrote: > I'm trying to track down an oops on my for-usb-linus queue that could > either be related to Alex's original MSI work around patch, or the patch > Oliver posted for working around PCI MMIO not being enabled fast enough. > I don't want to review this MSI improvement patch until I'm sure the > original MSI work around patch is stable. > > Alex, please give me time to debug bug fixes for 3.3 before pushing on > features for 3.4. Alex, your original MSI enabling patch simply does not work. The xHCI PCI driver was marked as const and the xHCI PCI probe function oopsed as soon as it tried to add HCD_MSI_FIRST to driver->flags. Please test all the patches in your patchsets individually to make sure they don't cause bugs, as this will break git-bisect. It's especially troublesome to not test a patch I've said will be needed for stable, since we really try not to break stable. </grumpy maintainer rant> The oops brings up an interesting point. I think the reason the xHCI PCI driver structure is marked as const is because it's shared across all xHCI hosts in the system. Even if you remove the const keyword, you could be modifying the flags while another xHCI host controller is being initialized. I think PCI probe isn't run in parallel, but you could still have the case where the Intel Panther Point xHCI PCI probe runs first, HCD_MSI_FIRST gets added to the hcd driver flags, and then the PCI probe runs for a Fresco Logic add-in card that doesn't handle MSI, and the USB core doesn't attempt to allocate the legacy IRQ because HCD_MSI_FIRST is set. Then the Fresco Logic host controller will be left with no interrupt. Alan, is the hc_driver structure (xhci_pci_hc_driver) shared across all xHCI PCI hosts in the system? Sarah Sharp -- 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
