linux-kernel - Re: PME via interrupt or SCI mechanism?

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <201110012229.55473.rjw@sisk.pl>
Date:	Sat, 1 Oct 2011 22:29:55 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Sarah Sharp <sarah.a.sharp@...ux.intel.com>
Cc:	linux-acpi@...r.kernel.org, linux-pci@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Matthew Garrett <mjg59@...f.ucam.org>
Subject: Re: PME via interrupt or SCI mechanism?

On Saturday, October 01, 2011, Sarah Sharp wrote:
> On Fri, Sep 30, 2011 at 10:21:06PM +0200, Rafael J. Wysocki wrote:
> > OK, please test the appended patch.  The difference is that it should only
> > continuously poll devices that don't get notifications.  You'll still see
> > the debug messages from your previous patches, but this one should be a bit
> > less wasteful than the previous one in general.
> 
> This patch seems to work.  The GPE fires and the xHCI host controller
> comes out of D3 after a stream of:
> 
> Sep 30 17:07:32 talon kernel: [  197.745312] ehci_hcd 0000:00:1d.0: pci_acpi_wake_dev
> Sep 30 17:07:32 talon kernel: [  197.745321] ehci_hcd 0000:00:1a.0: pci_acpi_wake_dev
> Sep 30 17:07:32 talon kernel: [  197.745326] snd_hda_intel 0000:00:1b.0: pci_acpi_wake_dev
> Sep 30 17:07:32 talon kernel: [  197.745331] e1000e 0000:00:19.0: pci_acpi_wake_dev
> 
> It does seem to take less time to come out of D3 than the previous patch
> though.
> 
> I occasionally do not see the host controller come out of D3 when I plug
> in a new device, but the interrupt count for GPE 0D doesn't increment
> when that happens, so it's probably just a BIOS or hardware bug.

I think the controller doesn't signal PME in those cases.

> Did mention this was bleeding edge hardware?

No, you didn't, but that doesn't matter a lot.  Bugs of this kind are found in
systems being sold in the market too and we need to work around them anyway. :-(

Thanks for testing the patch, I'll resent it with a changelog shortly.

Rafael
--
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/