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: <200708071551.21264.rjw@sisk.pl>
Date:	Tue, 7 Aug 2007 15:51:20 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	"Joonwoo Park" <joonwpark81@...il.com>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Simon Arlott" <simon@...e.lp0.eu>, "Pavel Machek" <pavel@....cz>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>,
	linux-pm@...ts.linux-foundation.org,
	linux-pci@...ey.karlin.mff.cuni.cz,
	David Brownell <david-b@...bell.net>
Subject: Re: [PATCH] kexec: fix pci device initialization fail after kexec (2.6.23-rc2). (Related to e1000 doesn't resume properly from standby)

On Tuesday, 7 August 2007 06:30, Joonwoo Park wrote:
> 2007/8/7, Rafael J. Wysocki <rjw@...k.pl>:
> > On Monday, 6 August 2007 17:50, Joonwoo Park wrote:
> > > 2007/8/6, Rafael J. Wysocki <rjw@...k.pl>:
> > > > On Monday, 6 August 2007 15:42, Joonwoo Park wrote:
> > > > > Hi.
> > > > > I think that the pci_set_power_state() has bug.
> > > > > The specification says that some delays is required.
> > > >
> > > > And they are in place, AFAICS (from drivers/pci/pci.c):
> > > >
> > > >        /* Mandatory power management transition delays */
> > > >        /* see PCI PM 1.1 5.6.1 table 18 */
> > > >        if (state == PCI_D3hot || dev->current_state == PCI_D3hot)
> > > >                msleep(pci_pm_d3_delay);
> > > >        else if (state == PCI_D2 || dev->current_state == PCI_D2)
> > > >                udelay(200);
> > > >
> > >
> > > The problem is occurred when state is 'PCI_D0', so those codes can't cover it.
> > > But pci pm specification 5.4.1 says that when programmed to D0 the
> > > equivalent of a warm reset, delay for the duration of the D3hot to D0
> > > Uninitialized state
> > > transition (10ms) to pci signal drivers remain disabled is required.
> >
> > Section 5.4.1 of PCI PM 1.1. spec is about D3_hot.  Specifically, it says
> > that if a device in D3_hot is programmed to D0, it performs the equivalent of
> > a warm reset.  IOW, this is supposed to happen if the current state is D3_hot
> > and the targed state is D0, which is covered by the code snippet above.
> 
> IMHO, it is seems to the spec says just *programmed  to D0* not
> *programmed from D3hot to D0*.

But the title of the section is "Software Accessible D3 (D3hot)", isn't it?

And the first paragraph of the section is

"Functions in D3hot must respond to configuration space accesses as long as
power and clock are supplied so that they can be returned to D0 by software."

If this doesn't imply D3hot to D0 transition being discussed in the next
paragraph, then I don't know what it's there for.

> Actually, I got current_state UNKNOWN and state PCI_D0 after kexec's
> start new kernel with dual port 82546EB fiber ethernet card.

IMO, pci_set_power_state() is correct and your problem is related to something
else.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ