Re: [Bugme-new] [Bug 13243] New: regression from 2.6.29 : can't suspend on a compaq nc6000, suspend_device(): pnp_bus_suspend+0x0/0x6b returns -5

[yakui_zhao <yakui.zhao@intel.com>]

On Thu, 2009-05-07 at 06:16 +0800, Bjorn Helgaas wrote:
> On Wednesday 06 May 2009 03:24:29 pm Witold Szczeponik wrote:
> > Andrew Morton schrieb:
> > > On Mon, 4 May 2009 15:03:54 GMT
> > > bugzilla-daemon@bugzilla.kernel.org wrote:
> > > 
> > >> http://bugzilla.kernel.org/show_bug.cgi?id=13243
> > 
> > Zhao, Len,
> > 
> > I tried to verify the problem on my TP 600E: suspend worked without any 
> > problems.  I will install the latest RC asap, but as the 600E is a 
> > relatively slow machine, this will take time. :-) Once I have a 
> > 2.6.30-rc4 kernel, I will update this message.
> > 
> > However, I do not think that the problem lies within the PNPACPI layer. 
> >   The code that was included in my patch seems to expose the behavior we 
> > are seeing, not causing it.  Looking at the report in bug 13243, the 
> > ACPI layer is not able to transition the device (a COMx port) from 
> > "whatever" to D3.  This is indicated by message "ACPI: Transitioning 
> > device [C169] to D3" (the message is misleadig: it is displayed only 
> > when the transition failed).  My patch returns the error code to the PNP 
> > layer which is trying to suspend the machine.  It is here where the 
> > error is exposed.
> > 
> > Björn, I CC-ed you because this might be caused by something in the PNP 
> > layer.
> 
> Cedric identified 6328a57401dc5f5c as the point where this broke.
> 
> Prior to that commit, pnpacpi_disable_resources() did not set the
> power state of the device to D3.  After that commit, we try to set
> the device to D3 and return an error if that fails
> 
> In this case, the C169 device has _PR0 but no _PSx methods.  I don't
> think it makes sense to try to set such a device to D3, so we probably
> shouldn't return an error.
What you said is right. After applying that commit, the C169 device will
be switched to D3. And when the C169 device is switched to D3, the power
resource(C16D) will be turned off.
   But unfortunately the _OFF object of C16D is bogus. In such case the
_STA method can't reflect the correct status of power resource and OS
will complain that the C169 device can't be switched to D3 state.
   > Method (_OFF, 0, NotSerialized)
   >                         {
                                Store (0x00, Local0)
   >                         }
	
   
   If we add the boot option of "acpi.power_nocheck=1", the status check
will be skipped in course of D0/D3 state transition.

Hi, Cedric
    will you please try the boot option of "acpi.power_nocheck=1" and
see whether the issue still exists?
    Please also attach the output of dmidecode so that we add the box to
dmi check table.

    Thanks.
 
> 
> I don't know if that means acpi_bus_get_flags() should stop looking
> for _PR0, or if we should get rid of the power_manageable flag, or
> if acpi_bus_set_power() should silently succeed if the device doesn't
> support power states, or what.
> 
> Bjorn

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html