Re: pci_update_resource() getting called on sparc64

["David S. Miller" <davem@davemloft.net>]

From: Greg KH <greg@kroah.com>
Date: Mon, 8 Aug 2005 09:08:46 -0700

> On Mon, Aug 08, 2005 at 11:32:41AM -0700, Linus Torvalds wrote:
> > 
> > Not likely.
> > 
> > Sounds like fec59a711eef002d4ef9eb8de09dd0a26986eb77, which came in 
> > through Greg. I'm surprised Greg didn't pick up on that one.
> 
> I didn't pick up on that one, as David acked it a while ago :)
> 
> {sigh}  I only pushed that one as Ralf insisted that he needed it for
> some of his hardware and that there wasn't any bad side-affects.  Ralf,
> any objections to removing this for 2.6.13?

But this is so puzzling, because this code path should only trigger
if the device is not in D0 state.  There is no way any of the devices
in my sparc64 box should be in any powered down state at bootup
time.  Unless the kernel would do that, which I hope it does not.

Therefore, I can't figure out how this code path could even trigger.

It happens for every device in my machine, my primary framebuffer
radeonfb, my e1000, the tg3 card in the machine.  In short, every
single PCI device triggers this when it registers.

I think something fishy is going on here, and the sparc64 BUG()
is just a symptom.  Why are devices in D3hot state at bootup?

And lo' and behold, we find the answer in the PCI probing code.
It initializes every PCI device's PCI power state to "unknown":
 
	/* "Unknown power state" */
	dev->current_state = 4;

and thus makes this test ">= D3hot" pass in the pci_set_power_state()
code.

That looks very wrong.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/