Re: device_pm_add (was: Re: 2.6.25-git2: BUG: unable to handle kernelpaging request at ffffffffffffffff)

[Alan Stern]

On Wed, 23 Apr 2008, Rafael J. Wysocki wrote:

> > > Are drivers supposed to register children of suspended devices?  That doesn't
> > > make much sense IMO ...
> > 
> > Well, that's why I think the warning itself makes sense - and then we can 
> > decide whether it makes sense for that particular case or not. Clearly it 
> > happens (since it triggered), now we need to figure out _why_ it happened. 
> 
> Well, this particular case looks like a race to me.

I think the reason it happened is clear enough.  Call it a race if you 
want, but the window is so large that it hardly qualifies.

It's a result of the way the MMC core is written.  There's an
upper-level controller device, and below that is a host device, and
below that is the card itself.  The code that adds and removes children
of the host device runs as part of the controller driver.

Hence the problem: The driver adds children below the _host_ as soon as 
the _controller_ is resumed, even though the host is still suspended.  
It's not as big an error as it sounds -- the host was originally a 
class_device and then got converted over to a regular device.  It 
doesn't have a driver of its own.

This is one of the things that needs to be fixed up as part of the 
reworking of the system-sleep API.  I simply haven't had any time to 
work on it (and I'm not likely to in the near future).

You ought to be able to provoke this more or less at will, depending on
the order in which your PCI devices are probed, by inserting or
removing an MMC card during the disk spin-up interval while the system
is waking up.

Alan Stern

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