On Sat, Mar 30, 2013 at 12:38 PM, Emmanuel Grumbach <egrumbach@xxxxxxxxx> wrote: >>> >>> Anyway - I think I will just remove this pci_disable_link_state call >>> and hopefully, it will stay long enough in linux-next so that people >>> will report issues before it get into linux. >>> I don't like leaving that code if it doesn't do anything. >> >> I think we broke at least some cases of pci_disable_link_state() a >> while back. I'd like to fix it rather than just removing calls to it. >> >> Can someone collect a complete dmesg log and "lspci -vv" output? >> > > I will. But I am on vacation right now and my linux box is not > accessible right now... > In any case, what you'll see is that ASPM is enabled (L1 enabled with > or without driver). > We are also seeing some really weird stuff (which I can't reproduce of > course) like HW becoming not accessible, I guess it would be worth > trying to *really* disable L1. I can tweak that in the code of the > driver and tell the NIC that L1 is disabled. > > /* Disable L1-Active */ > iwl_set_bits_prph(trans, APMG_PCIDEV_STT_REG, > APMG_PCIDEV_STT_VAL_L1_ACT_DIS); > > Do you have an idea about *when* did pci_disable_link_state() break? No, not yet. After we figure out exactly what the problem is, we should be able to determine when it broke. If I understand correctly, you have CONFIG_PCIEASPM=y, the iwlwifi driver uses pci_disable_link_state() to disable L1, but the link state stays in L0 all the time. So I think we should look at the dmesg log, "lspci -vv" output before loading iwlwifi, and "lspci -vv" output after loading iwlwifi. 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
