On Sat, 14 Oct 2006 21:20:01 -0600 Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 14, 2006 at 01:48:55PM -0700, Andrew Morton wrote: > > On Sat, 14 Oct 2006 08:02:49 -0600 > > Matthew Wilcox <[EMAIL PROTECTED]> 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: It seems to have stopped happening. I don't know why. gregkh-pci-pci-prevent-user-config-space-access-during-power-state-transitions.patch still breaks suspend though: http://userweb.kernel.org/~akpm/s5000349.jpg - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html