From patchwork Fri Apr 19 23:49:17 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Mokrejs X-Patchwork-Id: 238129 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 17E542C0221 for ; Sat, 20 Apr 2013 09:49:31 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965041Ab3DSXtW (ORCPT ); Fri, 19 Apr 2013 19:49:22 -0400 Received: from fold.natur.cuni.cz ([195.113.57.32]:56268 "EHLO fold.natur.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964977Ab3DSXtV (ORCPT ); Fri, 19 Apr 2013 19:49:21 -0400 Received: from [192.168.251.6] (unknown [192.168.251.6]) by fold.natur.cuni.cz (Postfix) with ESMTP id 9BD1A21EE005; Sat, 20 Apr 2013 01:49:17 +0200 (MEST) Message-ID: <5171D7FD.7070609@fold.natur.cuni.cz> Date: Sat, 20 Apr 2013 01:49:17 +0200 From: Martin Mokrejs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 MIME-Version: 1.0 To: Huang Ying , Sarah Sharp CC: Bjorn Helgaas , huang ying , "Rafael J. Wysocki" , Len Brown , Matthew Garrett , ACPI Devel Maling List , "linux-pci@vger.kernel.org" , Yinghai Lu Subject: Re: [PATCH] PCI / ACPI: Always resume devices on ACPI wakeup notifications References: <2282655.IicBMMa6jN@vostro.rjw.lan> <51548C9E.9090703@fold.natur.cuni.cz> <2990024.LMTIBUbM3d@vostro.rjw.lan> <51564804.9000700@fold.natur.cuni.cz> <515AF312.1010507@fold.natur.cuni.cz> <515B17D9.6030805@fold.natur.cuni.cz> <515B45A6.1020404@fold.natur.cuni.cz> <515C1DB8.5020905@fold.natur.cuni.cz> <1365075019.8901.9.camel@yhuang-mobile.sh.intel.com> <515EC645.7020403@fold.natur.cuni.cz> In-Reply-To: <515EC645.7020403@fold.natur.cuni.cz> X-Enigmail-Version: 1.5 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org 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 >>>>>> 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 --- lspci_vvv_initial.txt 2013-04-20 00:16:11.000000000 +0200 +++ lspci_vvv_initial__mouse_attached__detached__attached__1c.4_to_auto__detached__0b:00_to_auto.txt 2013-04-20 00:18:38.000000000 +0200 @@ -484,15 +484,14 @@ 0b:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller (rev 02) (prog-if 30 [XHCI]) Subsystem: Dell Device 04b3 - Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- .../*0b:00*/control (the mouse was plugged in during the echo command so we see not only PME changes but also D3 to D0 change because the mouse is attached): # diff -u -w lspci_vvv_initial__1c.4_and_0b\:00_to_auto__mouse_attached_and_works__detached__reattached_but_dead.txt lspci_vvv_initial__1c.4_and_0b\:00_to_auto__mouse_attached_and_works__detached__rea ttached_but_dead__0b\:00_to_on_rescues.txt --- lspci_vvv_initial__1c.4_and_0b:00_to_auto__mouse_attached_and_works__detached__reattached_but_dead.txt 2013-04-20 01:10:28.000000000 +0200 +++ lspci_vvv_initial__1c.4_and_0b:00_to_auto__mouse_attached_and_works__detached__reattached_but_dead__0b:00_to_on_rescues.txt 2013-04-20 01:12:25.000000000 +0200 @@ -484,14 +484,15 @@ 0b:00.0 USB controller: Texas Instruments TUSB73x0 SuperSpeed USB 3.0 xHCI Host Controller (rev 02) (prog-if 30 [XHCI]) Subsystem: Dell Device 04b3 - Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ + Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR-