All of lore.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: 40+ 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  7:08           ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.