PCI / ACPI: Always resume devices on ACPI wakeup notifications

Hi Sarah,
  does anyone has any comments to this thread? I just retried with 3.8.8
kernel and it is still same issue. I can put to 'auto' upstream 1c.4 port,
detach mouse and the 1c.4 does not suspend (due to a recent patch I think
around 3.8.5).
If I set also its downstream 0b:00 to 'auto', plugin mouse ... mouse works,
after I unplug the mouse the 0b:00 goes 'suspended' and XHCI socket dies.

Here is comparison of the 'active' state and of the 'suspended' to death
(note pcie_aspm=off on my kernel command line):
#

Collected data are at http://195.113.57.32/~mmokrejs/tmp/20130420.tar.bz2 (90kB)

Thanks,
Martin

Martin Mokrejs wrote:
> 
> 
> Huang Ying wrote:
>> Hi, Martin,
>>
>> On Wed, 2013-04-03 at 14:16 +0200, Martin Mokrejs wrote:
>>> Meanwhile, the raw data: http://195.113.57.32/~mmokrejs/tmp/20130402.tar.bz2
>>> (size 468641 bytes)
>>
>> Thanks a lot!  Your information is very complete and clear :)
>>
>>> They were collected by:
>>>
>>> # cat ~/bin/collect_runtime_status.sh 
>>> #!/bin/sh
>>> grep . /sys/bus/pci/devices/*/power/runtime_status > runtime_status_"$1".txt
>>> grep . /sys/bus/pci/devices/*/power/control > control_"$1".txt
>>> cat /proc/interrupts > interrupts_"$1".txt
>>> cat /proc/iomem > iomem_"$1".txt
>>> lspci -vvv > lspci_vvv_"$1".txt
>>> dmesg > dmesg_"$1".txt
>>> #
>>>
>>> Just do 'ls -latr' to see the ordering of the files as they were created.
>>> The longer the filename, the later in the test process. The names should be
>>> relatively self-explaining. Definitely, from the log files you should see
>>> what happened in real and therefore, can figure out what the (maybe weird)
>>> long filename really meant.
>>>
>>> Sometimes I manually recorded lsusb of dmesg_final.txt, mostly after I did some
>>> extra tests but but not want to record every step by the above 6 files.
>>>
>>> In one or two places I added some my own notes into COMMENTS file.
>>>
>>>
>>>
>>>
>>> I will try to guide your below where you can study which of the bugs. Mostly,
>>> for each bug you need just one subdirectory to look into, the other are just
>>> repeated the same bug under different kernel version or another patch.
>>> However, Sarah for the xHCI dead port issue will need to compare by diff
>>> two directories, one with the TI-based controller tests, the other with the
>>> NEC-based tests. Especially there, I would do something like:
>>>
>>> cd *TI-based; for f in dmesg*; do cut -c 15- $f > /tmp/TI/$f; done
>>> cd ../*NEC-based; for f in dmesg*; do cut -c 15- $f > /tmp/NEC/$f; done
>>>
>>> Then it should be easier to poke through file captured at the same test step,
>>> like:
>>>
>>> diff -u -w /tmp/TI/dmesg_initial__mouse_attached__unplugged__reattached_but_port_dead.txt \
>>> /tmp/NEC/dmesg_initial__mouse_attached__detached__reattached.txt
>>>
>>>
>>>
>>> Other than that, just diff pairs of files with each other, like:
>>>
>>> diff -u -w lspci_vvv_initial.txt lspci_vvv_initial__mouse_attached.txt
>>>
>>>
>>> Sorry that I sometimes used only a single underscore instead of double underscores
>>> to separate the test steps from each other in the filename.
>>>
>>>
>>> Martin Mokrejs wrote:
>>>> [ +linux-pci and Yinghai as they suffered already those many emails on individual
>>>>  threads so one overviewing email hopefully won't harm] ;-)
>>>>
>>>> Martin Mokrejs wrote:
>>>>>
>>>>>
>>>>> Bjorn Helgaas wrote:
>>>>>> On Tue, Apr 2, 2013 at 9:02 AM, Martin Mokrejs
>>>>>> <mmokrejs@fold.natur.cuni.cz> wrote:
>>>>>>> Hi Ying,
>>>>>>>
>>>>>>> huang ying wrote:
>>>>>>
>>>>>>>> And please give me the full dmesg for boot and incremental dmesg for
>>>>>>>> operations.
>>>>>>>
>>>>>>>
>>>>>>> The incremental bits here, the full dmesg will send only directly to your email, due to its size.
>>>>>>
>>>>>> Is there a bugzilla for this issue?  Please attach the complete dmesg
>>>>>> there or somewhere similar so we can all benefit.
>>>>>
>>>>> I changed my mind. I am attaching the dmesg here but omitting linux-acpi
>>>>> list. After I hear a proposal from Rafel/Bjorn I will open separate bugs.
>>>>> I thought that the threads I started so far were enough but yes, dmesg
>>>>> files don't pass through list filters so I should move that to bugzilla.
>>>>>
>>>>> so far my view of the the bugs was:
>>>>>
>>>>> 1) acpiphp hotplug broken due to upstream pcieport 1c.7 PME# enabled
>>>>>   (eSATA-based card)
>>>>
>>>> Fixed by Ying Huang port_dbg.patch applied over 3.8.5 (fixes acpiphp hotplug
>>>> of eSATA and Firewire cards, NOT the hotplug of a NEC-based USB3 card -> hence
>>>> the bug 4) below). Now I can continue using laptop-mode-tools.
>>>
>>> 20130402/3.8.5-ying_port-dbg__with_laptop-mode-tools_eSATA_testing
>>> 20130402/3.8.3-vanilla__with_laptop-mode-tools (with some comments in
>>>                                                 COMMENTS file)
>>
>> Thanks for your testing!
>>
>>>>> 2) xHCI dead due to to its suspend - 3.8 series and above
>>>>
>>>> Not fixed by port_dbg.patch applied over 3.8.5. Interestingly, a NEC-based
>>>> XHCI card *in an express card slot* does not suffer this suspend issue.
>>>> Although it is being put into suspend if a device is unplugged.
>>>
>>> 20130402/3.8.5-ying_port-dbg__with_laptop-mode-tools_xHCI_test_TI-based
>>> 20130402/3.8.5-ying_port-dbg__with_laptop-mode-tools_xHCI_test_NEC-based
>>>
>>> Same thing but yet without the port_dbg.patch:
>>> 20130402/3.9-rc5__with_2368081__with-latop-mode-tools_xhci_testing/
>>
>> It appears that TI xHCI dead port issue will present even if the PCIe
>> port will never go suspended.  So I think this bug is not related to
>> PCIe port runtime PM but related to USB xHCI.
>>
>> Do you agree Sarah?
> 
> Although I confirmed with 20130405.tar.bz2 dataset what Sarah repeated from our
> past findings in the email which should be just in your your inbox, one thing is
> puzzling:
> When I have powersaving enabled upon bootup with NO USB devices attached to the TI
> controller, effectively while reaching multiuser mode the 0b:00.0 is in a suspend
> state. But, somehow, the very first mouse plugin works. Only the reject causes
> more 'aggressive' suspend.
> As it seems no upstream 1c.4 is messing up here (in the test Sarah wanted me to do
> we have all control files 'on' except the end 0b:00.0) then really still something
> *else* is causing the dead port *in conjunction* with 'suspended' runtime state.
> Please double check what I wrote initially about the 20130402.tar.bz2 dataset.
> Notably, I would compare lspci outputs from a cold boot state with no devices
> attached and suspended 0b:00.0 (the 20130402.tar.bz2 dataset) with the dead port
> status in lspci (find any in 20130402.tar.bz2 or now in 20130405.tar.bz2).
> 
> Martin
> 
>>
>> [snip]
>>
>> Best Regards,
>> Huang Ying
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

PCI / ACPI: Always resume devices on ACPI wakeup notifications

Commit Message

Comments

Patch