On Mon, Aug 12, 2013 at 3:34 PM, Stefan Seyfried <stefan.seyfried@xxxxxxxxxxxxxx> wrote: > Hi Bjorn, > > Am 12.08.2013 19:21, schrieb Bjorn Helgaas: > >> Thanks for the report, Stefan. I opened >> https://bugzilla.kernel.org/show_bug.cgi?id=60736 so we don't forget >> about this. If you could attach complete dmesg logs for both cases >> (working and failing) to that bugzilla, that would be great. An >> acpidump might also be interesting, since the ACPI namespace >> determines what acpiphp does. > > Ok, I added all that information to the bug. Thanks! >> I suspect that we're being too aggressive about determining when we >> should use one or the other of acpiphp and pciehp. We basically >> decide up front which one we expect the platform to use, and we only >> listen to signals from that one. But I wonder if we should just >> prepare for signals from both. > > Actually I booted an older Kernel (3.7.10, openSUSE 12.3 kernel) which > has both drivers configured as modules. > The interesting thing is: I was not able to load acpiphp there, it > errored out with ENODEV. > So maybe something changed, making acpiphp more (too?) relaxed. > > Should I try building the latest kernel with both drivers as modules to > see if this makes a difference? No, don't bother. Neither one can be built as a module any more anyway (6037a803b removed it for acpiphp, and c10cc483b did the same for pciehp). There was never a good way to auto-load the modules, so it really didn't make much sense to have them be modules. Just bug us periodically if nothing seems to be happening on the bug report :) 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
