| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20110929182327.GA4979@xanatos> Date: Thu, 29 Sep 2011 11:23:27 -0700 From: Sarah Sharp <sarah.a.sharp@...ux.intel.com> To: "Rafael J. Wysocki" <rjw@...k.pl> Cc: linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org, LKML <linux-kernel@...r.kernel.org> Subject: Re: PME via interrupt or SCI mechanism? On Thu, Sep 29, 2011 at 12:21:28AM +0200, Rafael J. Wysocki wrote: > On Wednesday, September 28, 2011, Sarah Sharp wrote: > > On Tue, Sep 27, 2011 at 10:54:47PM +0200, Rafael J. Wysocki wrote: > > > On Tuesday, September 27, 2011, Sarah Sharp wrote: > > So it looks like gpe 0xD is enabled when the host goes into D3, and > > acpi_dev_run_wake is calling acpi_enable_gpe() with GPE 13 (i.e. 0xD), > > correct? > > Yes, that's correct. > > Moreover, evidently, the event is signaled and it causes pci_acpi_wake_dev() > to be called for multiple devices, _except_ for the xhci_hcd. Perhaps > the notifier is not installed for that device for some reason. > > Please add an additional debug printk()s to pci_acpi_add_pm_notifier() > for both pci_dev and dev and for the result returned by add_pm_notifier(). dmesg reports success from pci_acpi_add_pm_notifier for all PCI devices, including the xHCI host (PCI device 0000:00:14.0): [ 0.936882] pci_bus 0000:00: bus scan returning with max=04 [ 0.936884] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.936961] pci 0000:00:1f.0: pci_acpi_add_pm_notifier [ 0.936964] acpi device:02: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.936977] pci 0000:00:19.0: pci_acpi_add_pm_notifier [ 0.936978] acpi device:1f: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.936981] pci 0000:00:1d.0: pci_acpi_add_pm_notifier [ 0.936983] acpi device:20: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.936986] pci 0000:00:1a.0: pci_acpi_add_pm_notifier [ 0.936987] acpi device:2b: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.936990] pci 0000:00:14.0: pci_acpi_add_pm_notifier [ 0.936992] acpi device:34: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.936995] pci 0000:00:1b.0: pci_acpi_add_pm_notifier [ 0.936996] acpi device:3e: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.936999] pci 0000:00:1c.0: pci_acpi_add_pm_notifier [ 0.937001] acpi device:3f: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.937002] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP01._PRT] [ 0.937033] pci 0000:00:1c.7: pci_acpi_add_pm_notifier [ 0.937035] acpi device:4d: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.937036] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.RP08._PRT] [ 0.937056] pci 0000:03:00.0: pci_acpi_add_pm_notifier [ 0.937057] acpi device:4e: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.937060] pci 0000:00:1f.2: pci_acpi_add_pm_notifier [ 0.937062] acpi device:4f: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.937066] pci 0000:00:1f.3: pci_acpi_add_pm_notifier [ 0.937068] acpi device:52: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.937071] pci 0000:00:01.0: pci_acpi_add_pm_notifier [ 0.937072] acpi device:53: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.937074] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEG0._PRT] [ 0.937094] pci 0000:01:00.0: pci_acpi_add_pm_notifier [ 0.937095] acpi device:54: pci_acpi_add_pm_notifier add_pm_notifier returned 0 (success) [ 0.937104] acpi_pci_osc_support This morning, I debugged an issue with the NEC xHCI host controller issue in Keith Packard's Lenovo x220 machine. The NEC host was not giving port status changes when the host controller was suspended, and it turns out Keith has a boot script that runs `echo auto > power/control` for all his PCI devices. When he disabled that script and rebooted, his NEC host started working again. So it's possible that other xHCI host controllers are also affected by this D3 wakeup issue, which makes it less likely to be a hardware bug, and more likely to be a PCI/ACPI/xHCI driver bug. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists