From patchwork Mon Sep 23 21:28:49 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 2930091 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 0E32DBFF05 for ; Mon, 23 Sep 2013 21:29:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 2CB6B20315 for ; Mon, 23 Sep 2013 21:29:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1CAC3200E1 for ; Mon, 23 Sep 2013 21:29:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753742Ab3IWV3N (ORCPT ); Mon, 23 Sep 2013 17:29:13 -0400 Received: from mail-ie0-f169.google.com ([209.85.223.169]:58955 "EHLO mail-ie0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753357Ab3IWV3M (ORCPT ); Mon, 23 Sep 2013 17:29:12 -0400 Received: by mail-ie0-f169.google.com with SMTP id tp5so7706963ieb.28 for ; Mon, 23 Sep 2013 14:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C2d2Ok8y5GEqYTA7eF6svXErWq+B6ZCQEMbIs48WmyY=; b=RzTCZhFX9C2kd2A0F1picvrvUBb9pGYkX0tzGPpC9//OmCWKanYHvXY2Xu2rnQKOAt JD1GJzRmmItGFmyRk0XH5BfwDLl8WTNiiC8k8WWYMoqYeIDIdYnI4kda5G0FGrOjBwTh x1ljCuA5sSBZVA2SGRzG0oAyZLsMsaU8DjpAiTF+EBvWglDILFz/BRtkHdywOMe4Zr/v FRvHV1EWPpH7zagkEgQyyURxy2TgftKRQpRY6C9FtEtWmXKYKd6g9so9BWvwVAEC+Lzr BjlVgV6JROdnidDvNqOaOtRqrwipXFcCa5X6CQQetWSsjO/I3ojSi6FkyTKhky2ezF9u Q3mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=C2d2Ok8y5GEqYTA7eF6svXErWq+B6ZCQEMbIs48WmyY=; b=NA50gsBdARcchfqlVuP38hTrlINK1HC+6PBFRzBEujGuDlE/iPiMVRtqsNUKPY1DJ/ q81kLuo6YNS+tYSXG1CMMMTslSOcUq6wzWO88n0uYjqEAG+G4Utld70/M1diVXlZxBgC nnyvkOPRNikcmsEOKsh0F5HONoJG1L43DoWZmReEH4N1rdvNsZWjAwpMaBEeMar1QoZJ IFRcHEEXLoEPmVmSeE+LlFhG1LjIHTiKumyc6WYyako1xZvaJrvYGbnHlgLzXUGygAqH 6I4pYKuF84zVI6XEThdkwQWDbw8L+SQqwXDpqKVVlB0cbZvawaZQ4YslUTbSX44JgYcA Bk3Q== X-Gm-Message-State: ALoCoQl6q38/fkRHEBb8e73QcD1Duir0W+vxQOuYCUPqETyoZleDoQgQbg3vSH4qrqryHGK/zkUvL5mMfJgwS6fjHj16IM3VaqWoNM9Z6lN5ttEv0+ugpSUzJxTKZrWm38GHbi0bpKEVByQG54Uyj5h1ReYTmxx0v1VXPDP989mcp92k77mVkIiV/5CuBDtDWm5P4SWvqdmDY06eEOug/B+YnZAX5NzZbA== X-Received: by 10.43.125.4 with SMTP id gq4mr15746613icc.1.1379971751079; Mon, 23 Sep 2013 14:29:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.243.104 with HTTP; Mon, 23 Sep 2013 14:28:49 -0700 (PDT) In-Reply-To: References: From: Bjorn Helgaas Date: Mon, 23 Sep 2013 16:28:49 -0500 Message-ID: Subject: Re: ehci-pci D3cold logspam To: Alan Stern Cc: Andy Lutomirski , USB list , "linux-pci@vger.kernel.org" , "Rafael J. Wysocki" , Linux PM list Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP [+cc Rafael, linux-pm] On Mon, Sep 23, 2013 at 1:36 PM, Alan Stern wrote: > On Mon, 23 Sep 2013, Andy Lutomirski wrote: > >> I've been getting this on several recent kernel revisions. Is it >> interesting? If so, I'm happy to help diagnose it. If not, can the >> message be killed or severely ratelimited? I'm getting so much of >> this that it tends to overflow the log ring. > > It's interesting only if you care about when your EHCI controllers get > resumed and suspended. In this case, it's not clear why the > transitions happen so rapidly. It looks like some sort of polling > is going on at roughly 2-second intervals. > >> [ 287.344991] ehci-pci 0000:00:1d.0: power state changed by ACPI to D0 >> [ 287.445433] ehci-pci 0000:00:1d.0: setting latency timer to 64 >> [ 287.446255] ehci-pci 0000:00:1a.0: power state changed by ACPI to D0 >> [ 287.456094] ehci-pci 0000:00:1d.0: power state changed by ACPI to D3cold >> [ 287.547205] ehci-pci 0000:00:1a.0: setting latency timer to 64 >> [ 287.557890] ehci-pci 0000:00:1a.0: power state changed by ACPI to D3cold >> [ 290.126910] ehci-pci 0000:00:1d.0: power state changed by ACPI to D0 >> [ 290.227958] ehci-pci 0000:00:1d.0: setting latency timer to 64 >> [ 290.228416] ehci-pci 0000:00:1a.0: power state changed by ACPI to D0 >> [ 290.238749] ehci-pci 0000:00:1d.0: power state changed by ACPI to D3cold >> [ 290.328904] ehci-pci 0000:00:1a.0: setting latency timer to 64 >> [ 290.339565] ehci-pci 0000:00:1a.0: power state changed by ACPI to D3cold >> [ 292.214834] ehci-pci 0000:00:1d.0: power state changed by ACPI to D0 >> [ 292.315458] ehci-pci 0000:00:1d.0: setting latency timer to 64 >> [ 292.315908] ehci-pci 0000:00:1a.0: power state changed by ACPI to D0 >> [ 292.326262] ehci-pci 0000:00:1d.0: power state changed by ACPI to D3cold >> [ 292.416487] ehci-pci 0000:00:1a.0: setting latency timer to 64 >> [ 292.431075] ehci-pci 0000:00:1a.0: power state changed by ACPI to D3cold >> [ 295.458048] ehci-pci 0000:00:1d.0: power state changed by ACPI to D0 >> [ 295.558613] ehci-pci 0000:00:1d.0: setting latency timer to 64 > > This question should be addressed to the PCI mailing list (cc'ed), as > those two messages are generated by > drivers/pci/pci-acpi.c:acpi_pci_set_power_state() and > drivers/pci/pci.c:pcibios_set_master() respectively. d010e5769 ("PCI / ACPI: Use dev_dbg() instead of dev_info() in acpi_pci_set_power_state()") might be part of the solution. That was done in response to https://bugzilla.kernel.org/show_bug.cgi?id=60636, which looks basically the same as your complaint. But if we are indeed polling every two seconds, even a dev_dbg() seems like overkill to me. Rafael or Lan can probably provide a better answer here. As for the "setting latency timer" messages, I really doubt those are useful to anybody. If nobody objects, I'll just drop it, e.g.: the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index b821a62..55a947b 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2854,7 +2854,7 @@ void __weak pcibios_set_master(struct pci_dev *dev) lat = pcibios_max_latency; else return; - dev_printk(KERN_DEBUG, &dev->dev, "setting latency timer to %d\n", lat); + pci_write_config_byte(dev, PCI_LATENCY_TIMER, lat); } -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in