Hi, Martin, On Sat, Mar 30, 2013 at 10:03 AM, Martin Mokrejs <mmokrejs@xxxxxxxxxxxxxxxxxx> wrote: > Rafael J. Wysocki wrote: > > On Thursday, March 28, 2013 07:31:58 PM Martin Mokrejs wrote: > >> Hi Bjorn, > >> > >> Bjorn Helgaas wrote: > >>> On Thu, Mar 28, 2013 at 11:26 AM, Martin Mokrejs > >>> <mmokrejs@xxxxxxxxxxxxxxxxxx> wrote: > >>>> > >>>> > >>>> Rafael J. Wysocki wrote: > >>>>> On Thursday, March 28, 2013 10:46:10 AM Bjorn Helgaas wrote: > >>>>>> On Thu, Mar 28, 2013 at 10:41 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > >>>>>>> On Thursday, March 28, 2013 10:21:30 AM Bjorn Helgaas wrote: > >>>>>>>> On Thu, Mar 28, 2013 at 6:57 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote: > >>>>>>>>> Hi Bjorn, > >>>>>>>>> > >>>>>>>>> I wonder what you think about the patch below? > >>>>>>>> > >>>>>>>> Seems fine to me (I'm trusting your and Matthew's judgment here since > >>>>>>>> I don't know much about it). Why don't you resend it with Matthew's > >>>>>>>> ack and the appropriate stable tags, and I'll put it in. > >>>>>>> > >>>>>>> I will, thanks! > >>>>>>> > >>>>>>>> If you have > >>>>>>>> a URL for a bugzilla or mailing list report of the original problem, > >>>>>>>> that would be good, too. It'd be nice if users and distros could > >>>>>>>> match problem reports with this solution, but I can't tell what the > >>>>>>>> user-visible issue was. I assume that Sarah tested this (or somebody > >>>>>>>> else reproduced the problem and tested the fix)? > >>>>>>> > >>>>>>> Sarah reported it to me privately and I'm afraid I don't have any pointers > >>>>>>> to publicly available mailing list archives etc. > >>>>>> > >>>>>> Do you at least have a description of how a user could determine > >>>>>> whether he is seeing the problem fixed by this patch? > >>>>> > >>>>> Yeah. For example, when the problem is visible on a USB controller and that > >>>>> controller is runtime-suspended, then plugging a new USB device into one > >>>>> of the controller's ports won't wake the controller up without the patch. > >>>> > >>>> Hi, > >>>> I am wondering for a week or two why nobody answered any of my bug reports, > >>>> not even Sarah who asked for more details. I am think the fix is about my report > >>>> under thread "Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled" > >>>> and I really wonder why I wasn't Cc:ed and listed as a reporter provided it is > >>>> about my report. But I should better wait what Sarah says. ;-) > >>> > >>> I haven't forgotten about your hotplug issues, but I've been on > >>> vacation for a week and have been working on the similar issue > >>> reported by Chris Clayton > >>> (https://bugzilla.kernel.org/show_bug.cgi?id=54981) because it seemed > >>> a bit more tractable. But I'll get back to yours eventually :) > >>> Unfortunately nobody else seems to be jumping in to help, and I can > >>> only do so much by myself. > >>> > >>> I haven't been following your XHCI issue at all, but one thing you > >> > >> But please do so now. If we are talking about an existing patch it should be > >> possible to say whether what I observed is likely to be fixed by the patch. > >> I will happily discuss then why I loose interrupts in a same way for my > >> rtl8169 network card and why this PME# stuff happens for me only with 3.8 > >> and not 3.7 (unlike what Sarah claims). I am not arguing that something > >> else makes 3.7 be able to wakeup the device and overcome the same bug > >> while "it" is gone from 3.8. I think this should be an easy task for you, > >> pci devs. ;-) > > > > OK, let's try to establish facts. > > > > Does the patch below causes the PCI PM issues you're seeing to go away? > > Yes, the PME# enabled to disabled is gone, because only PME# disabled is allowed. > I don't think I really tested a scenario like before. Big thanks to Huang Ying > (https://patchwork.kernel.org/patch/2359611/): > > # grep . /sys/bus/pci/devices/*/power/control > /sys/bus/pci/devices/0000:00:00.0/power/control:on > /sys/bus/pci/devices/0000:00:02.0/power/control:on > /sys/bus/pci/devices/0000:00:16.0/power/control:on > /sys/bus/pci/devices/0000:00:1a.0/power/control:on > /sys/bus/pci/devices/0000:00:1b.0/power/control:on > /sys/bus/pci/devices/0000:00:1c.0/power/control:on > /sys/bus/pci/devices/0000:00:1c.1/power/control:on > /sys/bus/pci/devices/0000:00:1c.3/power/control:on > /sys/bus/pci/devices/0000:00:1c.4/power/control:on > /sys/bus/pci/devices/0000:00:1c.7/power/control:on > /sys/bus/pci/devices/0000:00:1d.0/power/control:on > /sys/bus/pci/devices/0000:00:1f.0/power/control:on > /sys/bus/pci/devices/0000:00:1f.2/power/control:on > /sys/bus/pci/devices/0000:00:1f.3/power/control:on > /sys/bus/pci/devices/0000:05:00.0/power/control:on > /sys/bus/pci/devices/0000:09:00.0/power/control:on > /sys/bus/pci/devices/0000:0b:00.0/power/control:on > /sys/bus/pci/devices/0000:11:00.0/power/control:on > # grep . /sys/bus/pci/devices/*/power/runtime_status > /sys/bus/pci/devices/0000:00:00.0/power/runtime_status:active > /sys/bus/pci/devices/0000:00:02.0/power/runtime_status:active > /sys/bus/pci/devices/0000:00:16.0/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1a.0/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1b.0/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1c.0/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1c.1/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1c.3/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1c.4/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1c.7/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1d.0/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1f.0/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1f.2/power/runtime_status:active > /sys/bus/pci/devices/0000:00:1f.3/power/runtime_status:active > /sys/bus/pci/devices/0000:05:00.0/power/runtime_status:active > /sys/bus/pci/devices/0000:09:00.0/power/runtime_status:active > /sys/bus/pci/devices/0000:0b:00.0/power/runtime_status:active > /sys/bus/pci/devices/0000:11:00.0/power/runtime_status:active > # > > > > > If it doesn't make all of them go away, does it make *some* of them go away? > > Yes, repeated inserts and removals of devices into xHCI slot work fine, no need > to use "lsusb -vv" to wakeup devices. > > Aside from some minor USB errors (won't mess them here) what is important is the fact > that the eSATA card hotplug works well or perfectly. I just sent to you and other pci devs > much more detailed report under the "Re: 3.9-rc1: pciehp and eSATA card SiI 3132, no XHCI" > thread although this particular testing was done on 3.8.3. > > I think I can stop replying to this thread which is about the patch from Sarah. > My dead XHCI port issue is a power management issue, incidentally also fixed by the > very same patch from Huang Ying. Cool! ;-) Sorry, which patch do you mean? Or to be more clear, could you test the patch attached? For the XHCI dead port issue? Please test this patch with laptop-mode-tool installed and enabled. And before/after test, please get PCI devices runtime status with: grep . /sys/bus/pci/devices/*/power/runtime_status And please give me the full dmesg for boot and incremental dmesg for operations. Best Regards, Huang Ying
Attachment:
port_dbg.patch
Description: Binary data
