public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: Andrew Morton <akpm@osdl.org>
Cc: Val Henson <val_henson@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	netdev@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] [PCI] Check that MWI bit really did get set
Date: Sat, 14 Oct 2006 21:20:01 -0600	[thread overview]
Message-ID: <20061015032000.GP11633@parisc-linux.org> (raw)
In-Reply-To: <20061014134855.b66d7e65.akpm@osdl.org>

On Sat, Oct 14, 2006 at 01:48:55PM -0700, Andrew Morton wrote:
> On Sat, 14 Oct 2006 08:02:49 -0600
> Matthew Wilcox <matthew@wil.cx> wrote:
> 
> > On Fri, Oct 13, 2006 at 09:41:35PM -0700, Andrew Morton wrote:
> > > Bisection shows that this patch
> > > (pci-check-that-mwi-bit-really-did-get-set.patch in Greg's PCI tree) breaks
> > > suspend-to-disk on my Vaio.  It writes the suspend image and gets to the
> > > point where it's supposed to power down, but doesn't.
> > 
> > How odd.  What driver is calling pci_set_mwi() on the suspend path?
> 
> ehci_pci_reinit().  I stuck a dump_stack() in there.  See
> http://userweb.kernel.org/~akpm/s5000342.jpg

Thanks for the picture; that's really helpful.

I see.  We hibernate all the devices then wake them all back up again.
No doubt there's a good reason for this.

Still doesn't make much sense, though.  As far as I can see, the only
consequence of this particular patch is that 1) we do an additional read
from PCI_COMMAND and 2) we can return -EINVAL in one additional case.
But the only effect of returning EINVAL is a printk (for this particular
driver):

        /* PCI Memory-Write-Invalidate cycle support is optional (uncommon) */
        retval = pci_set_mwi(pdev);
        if (!retval)
                ehci_dbg(ehci, "MWI active\n");

        ehci_port_power(ehci, 0);

        return 0;

So even if we return EINVAL ... big deal.

Is it possible reading PCI_COMMAND too quickly after writing it causes
a foul-up?  That would be weird ...

so I suppose there's a few things I can ask you to try:

1. Stop reading the register back altogether.  This should revert the behaviour to the prepatch state:

-       pci_read_config_word(dev, PCI_COMMAND, &cmd);
+//     pci_read_config_word(dev, PCI_COMMAND, &cmd);

2. Put an mdelay(1); before that line

3. Change the last line to just return 0.

-       return (cmd & PCI_COMMAND_INVALIDATE) ? 0 : -EINVAL;
+	return 0;

> > What drivers do you have loaded on the Vaio?
> 
> sony:/home/akpm> lsmod

I don't see any of the other drivers calling pci_set_mwi, so i guess we're
looking at the right suspect.


I feel rather guilty about the amount of time you're spending on this;
any bugs you want me to look at as penance?

  reply	other threads:[~2006-10-15  3:20 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-06 19:05 [PATCH 1/2] [PCI] Check that MWI bit really did get set Matthew Wilcox
2006-10-06 19:05 ` [PATCH 2/2] [TULIP] Check the return value from pci_set_mwi() Matthew Wilcox
2006-10-06 19:15   ` Jeff Garzik
2006-10-06 19:28     ` Matthew Wilcox
2006-10-06 19:59       ` Jeff Garzik
2006-10-07  5:34         ` Grant Grundler
2006-10-07 14:44           ` Jeff Garzik
2006-10-06 19:16 ` [PATCH 1/2] [PCI] Check that MWI bit really did get set Jeff Garzik
2006-10-14  4:41 ` Andrew Morton
2006-10-14  5:21   ` Greg KH
2006-10-14 14:02   ` Matthew Wilcox
2006-10-14 20:48     ` Andrew Morton
2006-10-15  3:20       ` Matthew Wilcox [this message]
2006-10-15  6:53         ` Andrew Morton
2006-10-15 13:54           ` Matthew Wilcox
2006-10-15 17:47             ` Andrew Morton
2006-10-15  7:08         ` [Bulk] " David Brownell
2006-10-15 13:52           ` Matthew Wilcox
2006-10-15 14:21           ` Alan Cox
2006-10-15 13:57             ` Matthew Wilcox
2006-10-15 17:45               ` Andrew Morton
2006-10-15 19:16                 ` David Brownell
2006-10-15 19:34                   ` Andrew Morton
2006-10-15 22:45                     ` David Brownell
2006-10-15 23:18                       ` Andrew Morton
2006-10-16  0:02                         ` Alan Cox
2006-10-15 23:44                           ` Andrew Morton
2006-10-16  0:44                             ` Paul Mackerras
2006-10-16  1:10                               ` Andrew Morton
2006-10-16  2:07                                 ` David Brownell
2006-10-16 10:58                                 ` Alan Cox
2006-10-16 11:02                             ` Alan Cox
2006-10-16  0:16                         ` David Brownell
2006-10-16  0:31                           ` Andrew Morton
2006-10-16 10:59                           ` Alan Cox
2006-10-15 21:52                 ` [Bulk] " Alan Cox
2006-10-16  0:00                 ` Paul Mackerras
2006-10-16  0:15                   ` Andrew Morton
2006-10-16  0:21                   ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061015032000.GP11633@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=akpm@osdl.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=netdev@vger.kernel.org \
    --cc=val_henson@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox